
A Readable Specification of TLS 1.3 - obtino
https://davidwong.fr/tls13/
======
anaphor
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
"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
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...](https://github.com/syncsynchalt/illustrated-
tls13/tree/master/captures)

------
wbond
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-...](http://blog.fourthbit.com/2014/12/23/traffic-analysis-of-an-ssl-slash-
tls-session).

~~~
tialaramex
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

~~~
userbinator
_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
> 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.

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

------
WaitWaitWha
this is a good reference.

