4 ms·

The privacy of the TLS 1.3 protocol [pdf]

50 points by lainon 7y ago

colmmacc 7y ago
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 7y ago
  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.
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...
BuildTheRobots 7y ago
> 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...
- nfoz 7y ago
  Could you elaborate? What's the problem with SNI? (I haven't dived deep into these protocols)
  - mschuster91 7y ago
    SNI exposes the target domain to everyone with sniffing capabilities - including everyone on your private/corp network as well as all involved ISPs.
    - gruez 7y ago
      That's an non issue because the target domain is in certificate that the server sends back. This happens with or without SNI.
      - toast0 7y ago
        In TLS 1.3, the certificate is now sent encrypted with an ephemeral key. A given IP can serve differwnt certificates depending on SNI, so if SNI can become unsniffable, determining the certificate based on observing traffic to the server as well as generating traffic would be much harder for shared IPs anyway.
- dagenix 7y ago
  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.
jajaioxjeyo 7y ago
sad

50 points by lainon 7y ago

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

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

BuildTheRobots 7y ago

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

nfoz 7y ago
Could you elaborate? What's the problem with SNI? (I haven't dived deep into these protocols)
- mschuster91 7y ago
  SNI exposes the target domain to everyone with sniffing capabilities - including everyone on your private/corp network as well as all involved ISPs.
  - gruez 7y ago
    That's an non issue because the target domain is in certificate that the server sends back. This happens with or without SNI.
    - toast0 7y ago
      In TLS 1.3, the certificate is now sent encrypted with an ephemeral key. A given IP can serve differwnt certificates depending on SNI, so if SNI can become unsniffable, determining the certificate based on observing traffic to the server as well as generating traffic would be much harder for shared IPs anyway.
dagenix 7y ago
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.

jajaioxjeyo 7y ago

sad