5 ms·

A Readable Specification of TLS 1.3

204 points by obtino 7y ago

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.
WaitWaitWha 7y ago
this is a good reference.
anaphor 7y ago
To be clear, it doesn't look like this is written any different from the actual RFC, just formatted and organized more nicely. For actually understanding the RFCs, I've found it useful to crack open wireshark and then look at an actual TLS connection, and then cross reference the RFC to figure out what's going on. It makes everything more concrete in my opinion.
- tialaramex 7y ago
  "The Illustrated TLS 1.3 Connection" https://tls13.ulfheim.net/ https://tls13.ulfheim.net/ does this in web page form which saves you the effort to go make a connection and try to puzzle it out as an introduction, but your process is fine too -- especially when debugging a concrete problem.
  - mcpherrinm 7y ago
    If you want to augment that website, the captures used to generate it are available, so you can reference them in Wireshark as wekk https://github.com/syncsynchalt/illustrated-tls13/tree/master/captures https://github.com/syncsynchalt/illustrated-tls13/tree/maste...
- baby 7y ago
  Author here. It includes errata, hides paragraphs that are not relevant with TLS 1.3, has nicer diagrams, and has videos going throug (a few) sections.
southerntofu 7y ago
Seriously, when will people stop using some cyberfascist firewall like Cloudflare? Usually it's only companies doing shit like that but here on HN i see a number of personal blogs hidden behind Recaptcha. Do you realize that makes your websites actually UNUSABLE by many people ? Don't have Javascript? Go fuck yourself. Using tor? Go fuck yourself. Scrapping the HTML to produce some nice indieweb interaction on your own website? Go fuck yourself. Don't mind the language. But the fact that two companies allied to destroy the Internet (while claiming to be neutral service providers) is highly worrying.
- lol768 7y ago
  What's the alternative if you want to be able to handle DDoS attacks? Something like OVH's VAC?
  - tgragnato 7y ago
    Isn’t the main feature for blogs on Cloudflare the free global CDN cache?
- reeeeee 7y ago
  Why is CloudFlare a cyberfascist firewall? If it is because you refuse to use JS? well too bad for you. CloudFlare takes a strong position on freedom, and I admire them for it: https://www.wired.com/story/free-speech-issue-cloudflare/ https://www.wired.com/story/free-speech-issue-cloudflare/
  - yosamino 7y ago
    Harbouring, enabling and protecting criminals is not "a strong position on freedom" - try to report a scamming site to them and see how they deal with it. Spoiler: They will not, and because it's behind their firewall, you'll be unable to find out who else to send an abuse complaint to.
crispyambulance 7y ago
I'll never understand why rfc's, arguably the underpinnings of internet technology, are styled to appear as TYPEWRITTEN pages in HTML. Seriously. Literal pages of typewritten text, on the web. I mean, they take significant effort to devise these standards and write them up, presumably with modern tools, AND THEN force weird typewriter CSS upon them? It looks awful. I can't understand it.
- bonyt 7y ago
  I assume this is because they’re published as plain text files. The HTML is styled to look the same as the plain text versions, including diagrams made assuming a fixed-width font. https://tools.ietf.org/rfc/rfc793.txt https://tools.ietf.org/rfc/rfc793.txt Plain ASCII text is a very compatible format, and probably will be for a very long time. For example, if you were to pipe this to a TCP socket on modern printer on port 9100 unchanged, it’ll likely print out roughly correct.
  - crispyambulance 7y ago
    OK, I see, but they provide three different formats: ASCII, PDF, and HTML. If there's a zombie apocalypse and we end up raiding the computer history museum for 80 column line-printers, sure, it makes sense to select the ASCII version to make print outs so that we could rebuild the internet. But for the HTML version? Come on! Freshen it up a bit.
- ComodoHacker 7y ago
  This low-tech format ensures the specs remain readable and unambiguous. Imagine you've lost most of web technology after a nuclear apocalypse or something and have to recreate it from specs. You have no software guaranteed to render HTML correctly and completely. (We don't have it even now BTW.) It's like bootstrapping a compiler toolchain on an entirely new architecture. You have to start with assembly, and it looks awful.

204 points by obtino 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.

WaitWaitWha 7y ago

this is a good reference.

anaphor 7y ago

To be clear, it doesn't look like this is written any different from the actual RFC, just formatted and organized more nicely. For actually understanding the RFCs, I've found it useful to crack open wireshark and then look at an actual TLS connection, and then cross reference the RFC to figure out what's going on. It makes everything more concrete in my opinion.

tialaramex 7y ago
"The Illustrated TLS 1.3 Connection" https://tls13.ulfheim.net/ https://tls13.ulfheim.net/ does this in web page form which saves you the effort to go make a connection and try to puzzle it out as an introduction, but your process is fine too -- especially when debugging a concrete problem.
- mcpherrinm 7y ago
  If you want to augment that website, the captures used to generate it are available, so you can reference them in Wireshark as wekk https://github.com/syncsynchalt/illustrated-tls13/tree/master/captures https://github.com/syncsynchalt/illustrated-tls13/tree/maste...
baby 7y ago
Author here. It includes errata, hides paragraphs that are not relevant with TLS 1.3, has nicer diagrams, and has videos going throug (a few) sections.

southerntofu 7y ago

Seriously, when will people stop using some cyberfascist firewall like Cloudflare? Usually it's only companies doing shit like that but here on HN i see a number of personal blogs hidden behind Recaptcha. Do you realize that makes your websites actually UNUSABLE by many people ? Don't have Javascript? Go fuck yourself. Using tor? Go fuck yourself. Scrapping the HTML to produce some nice indieweb interaction on your own website? Go fuck yourself. Don't mind the language. But the fact that two companies allied to destroy the Internet (while claiming to be neutral service providers) is highly worrying.

lol768 7y ago
What's the alternative if you want to be able to handle DDoS attacks? Something like OVH's VAC?
- tgragnato 7y ago
  Isn’t the main feature for blogs on Cloudflare the free global CDN cache?
reeeeee 7y ago
Why is CloudFlare a cyberfascist firewall? If it is because you refuse to use JS? well too bad for you. CloudFlare takes a strong position on freedom, and I admire them for it: https://www.wired.com/story/free-speech-issue-cloudflare/ https://www.wired.com/story/free-speech-issue-cloudflare/
- yosamino 7y ago
  Harbouring, enabling and protecting criminals is not "a strong position on freedom" - try to report a scamming site to them and see how they deal with it. Spoiler: They will not, and because it's behind their firewall, you'll be unable to find out who else to send an abuse complaint to.

crispyambulance 7y ago

I'll never understand why rfc's, arguably the underpinnings of internet technology, are styled to appear as TYPEWRITTEN pages in HTML. Seriously. Literal pages of typewritten text, on the web. I mean, they take significant effort to devise these standards and write them up, presumably with modern tools, AND THEN force weird typewriter CSS upon them? It looks awful. I can't understand it.

bonyt 7y ago
I assume this is because they’re published as plain text files. The HTML is styled to look the same as the plain text versions, including diagrams made assuming a fixed-width font. https://tools.ietf.org/rfc/rfc793.txt https://tools.ietf.org/rfc/rfc793.txt Plain ASCII text is a very compatible format, and probably will be for a very long time. For example, if you were to pipe this to a TCP socket on modern printer on port 9100 unchanged, it’ll likely print out roughly correct.
- crispyambulance 7y ago
  OK, I see, but they provide three different formats: ASCII, PDF, and HTML. If there's a zombie apocalypse and we end up raiding the computer history museum for 80 column line-printers, sure, it makes sense to select the ASCII version to make print outs so that we could rebuild the internet. But for the HTML version? Come on! Freshen it up a bit.
ComodoHacker 7y ago
This low-tech format ensures the specs remain readable and unambiguous. Imagine you've lost most of web technology after a nuclear apocalypse or something and have to recreate it from specs. You have no software guaranteed to render HTML correctly and completely. (We don't have it even now BTW.) It's like bootstrapping a compiler toolchain on an entirely new architecture. You have to start with assembly, and it looks awful.