
The privacy of the TLS 1.3 protocol [pdf] - lainon
https://eprint.iacr.org/2019/749.pdf
======
brians
Oof. This is an important contribution about the handshake and resumption
protocols, but the abstract is badly misquotable. I worry this will lead to
problems as it’s reported elsewhere.

TLS 1.3 doesn’t encrypt the SNI, doesn’t encrypt the destination IP address,
and doesn’t mask the size or ordering of packets. In practice, TLS 1.3
protects secrecy of the bits you send—but not privacy of to whom or how much.

As I wrote five years ago when TLS 1.3 was getting started,
[https://weblog.evenmere.org/posts/2014-05-16-tls-is-not-
for-...](https://weblog.evenmere.org/posts/2014-05-16-tls-is-not-for-
privacy.html) , the privacy folks have needs misaligned with the prevalent
technology.

~~~
3xblah
When I saw the title of the paper I expected it would be about what the parent
comment describes. Instead, they deliberately omit the case of SNI and state
that this issue "deserves its own paper".

I think any serious consideration of the issue cannot proceed on the
assumption that the SNI extension is a "must-have". It is optional. Users can
prefer websites that do not use SNI. There are still plenty of TLS-protected
websites not using CDNs and SNI.

CDNs often do not check the Host header against the SNI name.

For example, request a page from www.globalsign.com from host
marketcircle.com.

    
    
       echo -e "GET /en/ HTTP/1.1\r\nHost: www.globalsign.com\r\nConnection: close\r\n\r\n"|openssl s_client -no_tls1 -no_tls1_1 -no_ssl2 -no_ssl3 -ign_eof -no_ticket -host marketcircle.com -port 443 -tlsextdebug -servername marketcircle.com -verify 9

~~~
brians
This is a tricky question to turn off. It’s rarely clear how to construct an
attack with it, and it does allow a kind of privacy by telling your ISP & DNS
providers one name, while asking for another.

------
colmmacc
This paper is misleading IMO. The abstract says - "On the positive side, we
prove that TLS 1.3 protects the privacy of its users at least against passive
adversaries, contrary to TLS 1.2, and against more powerful ones."

But if you read the summary, it also says "both TLS 1.2 and TLS 1.3 session
resumption present serious privacy flaws despite not using concrete
authentication elements, such as certificates ... While [PSK-DHE] provides a
measure of backward security, it does nothing to improve privacy."

TLS1.3 is awesome, but it's still a layer 4 transport scheme, and there are
plenty of ways that a passive adversary can derive privacy sensitive
information. I mean it's /trivial/ for a passive adversary to tell that you're
visiting an embarrassing website ... to pick just one obvious example.

~~~
nickserv
Right, and it's in the name, after all: Transport Layer _Security_. Security
is not quite the same as privacy.

TLS was never meant as a way of guaranteeing privacy in a broad sense as far
as I know, and this is the first time I'm seeing it described as such.

Now, one may argue that security is a needed component of privacy, but it's
certainly not enough by itself.

------
BuildTheRobots
> Another feature we omit is the Server Name Indication (SNI) extension, which
> allows a single server to run TLS handshakes on behalf of multiple domains,
> using multiple public keys.

I don't understand how you can seriously use TLS and privacy in the same
headline whilst actively ignoring the mess that is SNI...

~~~
dagenix
If you connect to a website behind a CDN hosting many websites, a passive
observer can tell that you connected to the CDN, but has no idea which website
you requested (let's pretend that they can't use a length fingerprinting
attack). However, unless the CDN supports domain fronting, which most don't,
you have to use SNI to tell the CDN which website you want so you can get the
right cert. As SNI is unencrypted, a passive observer now knows what website
you are talking to. Privacy defeated.

If you connect to a website not behind a CDN, you probably don't have to use
SNI, but, the website is revealed by doing a simple reverse DNS query. Privacy
defeated.

Unencrypted SNI doesn't hurt privacy when compared to the status quo.
Encrypted SNI will boost privacy. But until then, TLS is basically the best
you can do for privacy, outside of using some more exotic service.

~~~
3xblah
"If you connect to a website not behind a CDN, you probably don't have to use
SNI, but, the website is revealed by doing a simple reverse DNS query."

As an example, I tried a reverse DNS query for the IP address of
matrixssl.org. All I got was a subdomain at gandi.net.

Reverse DNS was originally intended for troubleshooting. It is _not required_
for websites (cf. email) and not everyone bothers to set it up. That is one
group of websites where we have to do more work to get the names that are
using the remote IP address and figure out which one the user asked for.

In fact, DNS is _not required_ for a functional website. IP address of course
works fine. That is another group of websites where we have to do additional
work to figure out what is at the remote IP address. We do not know what the
user sent in her HTTP headers.

By comparison, SNI makes the process of invading user privacy easy and
reliable, less work. The user is _required_ to send a name, and to send that
name in the clear.

~~~
gruez
>As an example, I tried a reverse DNS query for the IP address of
matrixssl.org. All I got was a subdomain at gandi.net.

While the gp is wrong in saying that it's as simple as a reverse DNS lookup,
his general idea is correct. It's trivial to crawl the internet to find all
the ip -> domain mappings for all public domains. It's even easier if the
attacker is an ISP because they can log DNS queries/responses.

~~~
3xblah
If the parent comment is suggesting it is no easier with SNI, then I disagree.
Not all domains are "public" and not all users send their DNS queries to ISPs
or third party DNS providers. There are alternative sources for IP to domain
mappings for TLS-enabled websites besides reverse DNS, crawling the entire
internet is not necessary, but sniffing SNI is _easier and more reliable_ than
relying on DNS.

------
jajaioxjeyo
sad

