The privacy of the TLS 1.3 protocol [pdf]
eprint.iacr.org
eprint.iacr.org
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-... , the privacy folks have needs misaligned with the prevalent technology.
How would that work?
Alternatively, “it doesn’t work.” As Colm says elsewhere, the placement of TLS in the stack isn’t compatible with privacy goals. There’s a big project to nudge the current privacy-ignoring design of the Internet into a privacy-respecting design, while continuously maintaining compatibility and providing performance incentives to bring the mega corps along.
The engineers pushing that are supremely skilled and passionately motivated. If anyone can do it, they can. I am not optimistic, mostly because I expect the mass of less-skilled but equally-passionate consumers of that technology to latch on to intermediate solutions—like the recent Firefox-CF DoH experiment—and lock them in.
Today, pornhub.com knows I visited and what I clicked on. My ISP knows I went to pornhub. Even people on my local network know I went to PornHub. Through packet size analysis, all those parties even know what I typed in the search box at PornHub (each possible keystroke results in a different number of bytes of autocomplete Ajax).
TLS failed to achieve any of the privacy the user expected. The infosec community has missed the big picfure...
What TLS does is:
1) Prevent your local network or ISP from tricking you into visiting a fake pornhub. If you type that in and it loads over TLS, you know you're at the real one.
2) Prevent your local network or ISP from reading any of the data you exchange with pornhub.
This, of course, provides quite a bit of value. It's not everything you want, but it is a big win for many users.
I am also guessing that 1 capture doesn't give you a very good signal to noise ratio. Sure, if you capture someone's keyboard-interactive ssh exchange 100 times a day for 6 months, you have a lot of data. For your porn searches or whatever, I doubt the sample size is enough to leak a ton of information. And it's certainly better than just letting the person capturing packets read them and see what's in there.
I'm certain nation states work on developing these attacks. Also a commercial company just has to build it once, then they can sell it to ISPs who make money selling your data.
> All bank customers have the same length account number.
This isn't the only problem with packet size data, there have been compression attacks that can recover plaintext using packet sizes, like CRIME and BREACH.
> All the videos on YouTube have the same length identifier and usually last about 10 minutes and 1 second
Here's a research paper from 2017 where someone in a MITM position could detect exactly what netflix video you were watching by looking at packet sizes: https://mjkranch.com/docs/pubs/CODASPY17_Kranch_Reed_Identif...
Of course TLS still provides a critical level of security and privacy, but there is room for improvement.
This is absolutely not an "obscure" attack: it has been used, successfully, to build a tool to guess what city you are looking at with Google Maps. There, tiles are downloaded to render a map (similar to the segments used to render a video on YouTube). While each tile may have a fixed dimension, again, due to image compression, each tile has a different file size. Since tiles are downloaded in clusters, you can pretty readily fingerprint different regions of the map a user is looking at (and if it weren't for local caching, it would work almost instantly 100% of the time, live).
With type-ahead searching, as each character you type returns a different list, given the file size response sequence you should be able to determine exactly what search query someone made with almost total accuracy almost all of the time when they type it, with the only reason it ever not working well being due to caches and delayed queries (if you type fast enough on many type-ahead query boxes it will avoid sending queries for the prefixes, to reduce load for something that by the time the result is fetched won't even render).
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 9But 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.
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.
I don't understand how you can seriously use TLS and privacy in the same headline whilst actively ignoring the mess that is SNI...
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.
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.
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.
Of course, an adversary can then figure out who you are connecting to based on the IP.