A Readable Specification of TLS 1.3
davidwong.fr
A Readable Specification of TLS 1.3
1–10 of 27 posts
Re: A Readable Specification of TLS 1.3
#2If 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-....
Re: A Readable Specification of TLS 1.3
#3this is a good reference.
Re: A Readable Specification of TLS 1.3
#4To 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.
Re: A Readable Specification of TLS 1.3
#5If 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-... .
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
Re: A Readable Specification of TLS 1.3
#6To 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.
"The Illustrated TLS 1.3 Connection" 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.
Re: A Readable Specification of TLS 1.3
#7To 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.
"The Illustrated TLS 1.3 Connection" 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.
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/maste...
Re: A Readable Specification of TLS 1.3
#8If 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-... .
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, w…
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!
Re: A Readable Specification of TLS 1.3
#9Earlier quoted context omitted.
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, w…
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…
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.
Re: A Readable Specification of TLS 1.3
#10If 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-... .
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, w…
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.)