5 ms·

If this is something you are interested in, but you are looking for a slightly higher-level intro to TLS, albeit TLS 1.2, I highly recommend reading through htt

by wbond 7y ago

If this is something you are interested in, but you are looking for a slightly higher-level intro to TLS, albeit TLS 1.2, I highly recommend reading through http://blog.fourthbit.com/2014/12/23/traffic-analysis-of-an-ssl-slash-tls-session http://blog.fourthbit.com/2014/12/23/traffic-analysis-of-an-....

tialaramex 7y ago
Although TLS 1.3 deliberately looks like TLS 1.2 (eerily like it in "compatibility mode" because that's designed to cause stupid middleboxes to not even realise it's a new protocol) the fundamentals have changed, so this isn't very useful. Most importantly TLS 1.3 _always_ starts by the two parties setting up a secure encrypted connection, and only then is any effort expended on trying to figure out who anybody is, whereas in earlier versions these elements happen somewhat simultaneously. A TLS 1.0 guide was pretty helpful in understanding TLS 1.2, but a TLS 1.2 guide is probably just misleading for TLS 1.3
- wbond 7y ago
  My personal learning style generally involves learning in layers, and I would imagine a high-level overview of TLS 1.2 would be good since it provides some frame of reference before jumping into TLS 1.3, which from what I understand is an evolution of TLS 1.2 to provide better security. I seem to recall quite a bit of discussion during the development in regards to making TLS 1.3 look similar to TLS 1.2 for the sake of dealing with middleboxes. If someone knows of a high-level document about 1.3 that goes through the handshake process and differences with 1.2, that would be a great reference to have!
  - blattimwind 7y ago
    The cryptographic protocols of 1.3 could be said to be largely unrelated to 1.2. If you wanted to learn in layers then Noise is a lot closer to 1.3 than 1.2.
    - wbond 7y ago
      I'm not particularly interested in the cryptography specifically, but rather the network protocol, in order to be able to obtain information about the connection.
  - brians 7y ago
    You can imagine it, but the person you’re replying to is closer. 1.3 is a ground-up redesign, packaged to not bother middleboxes that look for TLS 1.2. The handshake process and difference is complete.
- userbinator 7y ago
  Most importantly TLS 1.3 _always_ starts by the two parties setting up a secure encrypted connection, and only then is any effort expended on trying to figure out who anybody is I wonder what the motivation behind that was --- I'm no cryptographer, but setting up what is effectively an anonymous (EC)DH session first seems to provide no extra protection from an active MITM because it's unauthenticated. The only other protocol I've seen do this is obfuscated BitTorrent, using a deliberately short keylength and RC4, where the goal was not protection from MITM but to resist traffic analysis and blocking by making essentially all of the traffic look completely random. Meanwhile, TLS 1.3 still retains the plaintext record headers and framing from previous versions. (One thing that I've always wondered about and never gotten a good answer is the fact that as far back as SSL 2.0, and presumably 1.0, there seemed to be no attempt to make the whole protocol encrypted, but instead the messages were very identifiable. Why not? One would think that a protocol designed to conceal data should itself be hard to distinguish from random noise.)
  - cesarb 7y ago
    > I wonder what the motivation behind that was Middleboxes. While the Internet is supposed to be end-to-end, there's no shortage of intermediate systems that pretend to understand the upper-layer protocols being carried, and that act on that what they think they see. Every single change to the visible parts of a protocol, no matter how small, risks breaking when one of these observers are present. TLS has been hit particularly hard by that; TLS 1.3 was delayed for many months while the protocol designers tried to figure out how to change the protocol without it being rejected by these interlopers. In the end, the solution was to make all TLS 1.3 connections pretend to be TLS 1.2 session resumption connections, and hide the real protocol negotiation within the encrypted session. > setting up what is effectively an anonymous (EC)DH session first seems to provide no extra protection from an active MITM because it's unauthenticated It's actually authenticated with the server certificate (and client certificate if one is being used); the authentication covers the whole protocol negotiation. Since with active MITM the intermediate box has to be one of the ends of each half of the connection (otherwise the authentication will fail since the ECDH keys won't match), the protocol negotiation protects against misunderstandings: if the MITM box does not understand TLS 1.3 (or any future version), it will negotiate TLS 1.2, instead of getting confused by all the changes to the protocol in TLS 1.3. > as far back as SSL 2.0, and presumably 1.0, there seemed to be no attempt to make the whole protocol encrypted The goal back then was to protect the data, not the metadata. Only recently have the bad experiences with protocol ossification caused by broken middleboxes led protocol designers to also protect as much as possible of the metadata.
- brians 7y ago
  That doesn’t sound quite right to me. server_name is sent in ClientHello (see https://tools.ietf.org/html/rfc8446#section-4.4.2.2 https://tools.ietf.org/html/rfc8446#section-4.4.2.2 )
  - tialaramex 7y ago
    Fair. I considered explaining that exception, but decided it was simpler not to. Of course someone is going to call me on it. Arguably server_name isn't part of making sure who is who - the protocol doesn't care what you put in there, it's just that you can reasonably expect that if you say you wanted to talk to Charlie then you shouldn't be surprised if you get Charlie instead of Bob. Eventually in eSNI the server_name will only be a bluff, since it's in plaintext and we'd rather not tell eavesdroppers who we're talking to, it will just have some generic masking name e.g. it might say some.cloudflare-server.example and then an encrypted record would reveal which actual Cloudflare server you wanted only to Cloudflare who are answering the connection.

by wbond 7y ago

tialaramex 7y ago

Although TLS 1.3 deliberately looks like TLS 1.2 (eerily like it in "compatibility mode" because that's designed to cause stupid middleboxes to not even realise it's a new protocol) the fundamentals have changed, so this isn't very useful. Most importantly TLS 1.3 _always_ starts by the two parties setting up a secure encrypted connection, and only then is any effort expended on trying to figure out who anybody is, whereas in earlier versions these elements happen somewhat simultaneously. A TLS 1.0 guide was pretty helpful in understanding TLS 1.2, but a TLS 1.2 guide is probably just misleading for TLS 1.3

wbond 7y ago
My personal learning style generally involves learning in layers, and I would imagine a high-level overview of TLS 1.2 would be good since it provides some frame of reference before jumping into TLS 1.3, which from what I understand is an evolution of TLS 1.2 to provide better security. I seem to recall quite a bit of discussion during the development in regards to making TLS 1.3 look similar to TLS 1.2 for the sake of dealing with middleboxes. If someone knows of a high-level document about 1.3 that goes through the handshake process and differences with 1.2, that would be a great reference to have!
- blattimwind 7y ago
  The cryptographic protocols of 1.3 could be said to be largely unrelated to 1.2. If you wanted to learn in layers then Noise is a lot closer to 1.3 than 1.2.
  - wbond 7y ago
    I'm not particularly interested in the cryptography specifically, but rather the network protocol, in order to be able to obtain information about the connection.
- brians 7y ago
  You can imagine it, but the person you’re replying to is closer. 1.3 is a ground-up redesign, packaged to not bother middleboxes that look for TLS 1.2. The handshake process and difference is complete.
userbinator 7y ago
Most importantly TLS 1.3 _always_ starts by the two parties setting up a secure encrypted connection, and only then is any effort expended on trying to figure out who anybody is I wonder what the motivation behind that was --- I'm no cryptographer, but setting up what is effectively an anonymous (EC)DH session first seems to provide no extra protection from an active MITM because it's unauthenticated. The only other protocol I've seen do this is obfuscated BitTorrent, using a deliberately short keylength and RC4, where the goal was not protection from MITM but to resist traffic analysis and blocking by making essentially all of the traffic look completely random. Meanwhile, TLS 1.3 still retains the plaintext record headers and framing from previous versions. (One thing that I've always wondered about and never gotten a good answer is the fact that as far back as SSL 2.0, and presumably 1.0, there seemed to be no attempt to make the whole protocol encrypted, but instead the messages were very identifiable. Why not? One would think that a protocol designed to conceal data should itself be hard to distinguish from random noise.)
- cesarb 7y ago
  > I wonder what the motivation behind that was Middleboxes. While the Internet is supposed to be end-to-end, there's no shortage of intermediate systems that pretend to understand the upper-layer protocols being carried, and that act on that what they think they see. Every single change to the visible parts of a protocol, no matter how small, risks breaking when one of these observers are present. TLS has been hit particularly hard by that; TLS 1.3 was delayed for many months while the protocol designers tried to figure out how to change the protocol without it being rejected by these interlopers. In the end, the solution was to make all TLS 1.3 connections pretend to be TLS 1.2 session resumption connections, and hide the real protocol negotiation within the encrypted session. > setting up what is effectively an anonymous (EC)DH session first seems to provide no extra protection from an active MITM because it's unauthenticated It's actually authenticated with the server certificate (and client certificate if one is being used); the authentication covers the whole protocol negotiation. Since with active MITM the intermediate box has to be one of the ends of each half of the connection (otherwise the authentication will fail since the ECDH keys won't match), the protocol negotiation protects against misunderstandings: if the MITM box does not understand TLS 1.3 (or any future version), it will negotiate TLS 1.2, instead of getting confused by all the changes to the protocol in TLS 1.3. > as far back as SSL 2.0, and presumably 1.0, there seemed to be no attempt to make the whole protocol encrypted The goal back then was to protect the data, not the metadata. Only recently have the bad experiences with protocol ossification caused by broken middleboxes led protocol designers to also protect as much as possible of the metadata.
brians 7y ago
That doesn’t sound quite right to me. server_name is sent in ClientHello (see https://tools.ietf.org/html/rfc8446#section-4.4.2.2 https://tools.ietf.org/html/rfc8446#section-4.4.2.2 )
- tialaramex 7y ago
  Fair. I considered explaining that exception, but decided it was simpler not to. Of course someone is going to call me on it. Arguably server_name isn't part of making sure who is who - the protocol doesn't care what you put in there, it's just that you can reasonably expect that if you say you wanted to talk to Charlie then you shouldn't be surprised if you get Charlie instead of Bob. Eventually in eSNI the server_name will only be a bluff, since it's in plaintext and we'd rather not tell eavesdroppers who we're talking to, it will just have some generic masking name e.g. it might say some.cloudflare-server.example and then an encrypted record would reveal which actual Cloudflare server you wanted only to Cloudflare who are answering the connection.