5 ms·

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 a

by brians 7y ago

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-privacy.html https://weblog.evenmere.org/posts/2014-05-16-tls-is-not-for-... , the privacy folks have needs misaligned with the prevalent technology.

colmmacc 7y ago
Even for the bits you send, although TLS1.3 includes support for record padding, it's not mandatory. In practice, both Content-Length finger-printing attacks and traffic analysis attacks work against TLS1.3.
nmjohn 7y ago
> doesn’t encrypt the destination IP address How would that work?
- brians 7y ago
  The simplest system I know to mask destination IP is an anonymizing mixnet. Tor is a good approximation: delegate your privacy to a system design. A CDN, or what Google’s doing with signed exchanges, is a bad approximation: delegate your privacy to an entity. For certain very specific goals, Psiphon is an intermediate solution. 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.
  - londons_explore 7y ago
    The test I like to use is "If I go into my bedroom and browse porn online, I expect nobody to know what I'm up to". 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...
    - jrockway 7y ago
      I don't think those were ever the goals of TLS, they are just some random things you want or think people want. 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.
      - Dylan16807 7y ago
        It does the first one. The second one doesn't do so well against packet size analysis.
        jrockway 7y ago
        Yeah, but that's a pretty obscure attack. All bank customers have the same length account number. All the videos on YouTube have the same length identifier and usually last about 10 minutes and 1 second. Some information is leaked through packet size and timing. But a lot isn't. 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.
3xblah 7y ago
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 7y ago
  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.

by brians 7y ago

colmmacc 7y ago

Even for the bits you send, although TLS1.3 includes support for record padding, it's not mandatory. In practice, both Content-Length finger-printing attacks and traffic analysis attacks work against TLS1.3.

nmjohn 7y ago

> doesn’t encrypt the destination IP address How would that work?

brians 7y ago
The simplest system I know to mask destination IP is an anonymizing mixnet. Tor is a good approximation: delegate your privacy to a system design. A CDN, or what Google’s doing with signed exchanges, is a bad approximation: delegate your privacy to an entity. For certain very specific goals, Psiphon is an intermediate solution. 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.
- londons_explore 7y ago
  The test I like to use is "If I go into my bedroom and browse porn online, I expect nobody to know what I'm up to". 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...
  - jrockway 7y ago
    I don't think those were ever the goals of TLS, they are just some random things you want or think people want. 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.
    - Dylan16807 7y ago
      It does the first one. The second one doesn't do so well against packet size analysis.
      - jrockway 7y ago
        Yeah, but that's a pretty obscure attack. All bank customers have the same length account number. All the videos on YouTube have the same length identifier and usually last about 10 minutes and 1 second. Some information is leaked through packet size and timing. But a lot isn't. 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.

3xblah 7y ago

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 7y ago
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.