
The Illustrated TLS 1.3 Connection: Every Byte Explained - syncsynchalt
https://tls13.ulfheim.net/
======
mcguire
" _Because middleboxes have been created and widely deployed that do not allow
protocol versions that they do not recognize, the TLS 1.3 session must be
disguised as a TLS 1.2 session._ "

And, from the bottom of my network-protocol-guy's heart, I hate them and
everyone who's ever even seen one with the fiery passion of a million very
angry suns.

~~~
nerdponx
Was explicit version whitelisting ever a legitimate security recommendation?
Naively, it seems like a sane defensive measure against unanticipated
behavior.

~~~
tialaramex
The version numbers are for negotiation purposes.

One reasonable thing to do when the remote peer says "I want to speak TLS 8.6"
is to say "Oh, I'm afraid we only allow TLS 1.2 here" and insist on talking
TLS 1.2 anyway.

But that's not what these boxes did. They go "TLS 8.6! Set Defence Condition
One. Attack In Progress! Prepare For Immediate Nuclear Strike!" and they tear
down the whole network connection.

They did this with every previous version of TLS. The accepted lesson at this
point is that if these idiots CAN break something they will, we don't care
whether it's because they're too stupid not to break it or because they're
actively assholes breaking things so nobody can have nice things, it doesn't
matter.

This is basically the network equivalent of that guy who just shoots anybody
he doesn't recognise on his front step. We don't call that "a sane defensive
measure" we call it murder, even if he thinks he was just on guard for
"unanticipated behaviour" he's going to jail.

~~~
snazz
The reason for this is to prevent downgrade attacks where an attacker can
perform a man-in-the-middle by forcing your client to use an insecure protocol
version. It makes sense, even if it occasionally breaks websites.

~~~
mcguire
Preventing downgrade attacks could be done by blacklisting known-bad versions,
no?

Assuming all future versions are bad leads to situations like this, where TLS
1.3 (and presumably all future versions) have to tunnel through a pseudo-TLS
1.2 connection.

~~~
tialaramex
Again, assuming all future versions are bad is _fine_ if that's what you want
to do.

Responding to a peer that says "I know TLS 1.3" with "Too bad, we're talking
TLS 1.2" was and is entirely in obedience with the specifications. As far as I
know _every_ major middlebox on the market today now does this in their latest
versions, most of them advertised this as "TLS 1.3 now supported"‡

But for "security" vendors silently being secure doesn't sell products, they
would rather have an alarm "TLS Protocol Attack prevented!" and block the
connection. Doesn't make you any safer, but that was never their priority.
It's also easier for them to do than correctly implementing the protocol.

‡ In much the same way that "HD Ready" televisions "supported" High Definition
television. In that you couldn't watch HD TV on those televisions, but hey, it
was "supported"... those televisions existed in the same universe where HD TV
existed. Likewise, modern Cisco or Palo Alto Networks middleboxes "support"
TLS 1.3 by saying they want to talk TLS 1.2 instead...

------
quotemstr
I wish we were more willing to break bad middleboxes. It'd cause more short-
term pain than TLS1.3's compatibility hacks, but it'll get us a better
internet in the long term. We can't let random bad intermediate nodes ossify
protocol development.

~~~
pilif
They did that for TLS 1.2. It took the better part of a decade before it
became usable and could be enabled by browsers as a version to try.

Being able to use the improved protocol _now_ is very nice.

~~~
spacenick88
That's why this time it should be tied to the power of the biggest IT firms.
If Apple, Google, Facebook and Microsoft were willing to let their servers
break the middle boxes even the most fucked up, stupid, slow IT department
would have to kill their broken middle boxes.

I'd argue it would take less than 48h hours to kill all middle boxes worldwide
and probably all broken browser versions too. Just imagine what it would mean
for a Big Corp not to be able to access Google, Bing, Facebook and iCloud from
their networks. It's either move or go bankrupt within days.

In a way that's kind of the nuclear option, but hell nukes do work.

------
mcguire
And in honor of the records + messages structure of the protocol, I link David
Tennenhouse's beloved 1989 paper, "Layered Multiplexing Considered Harmful".

[https://www.cl.cam.ac.uk/teaching/0708/DigiCommI/tennenhouse...](https://www.cl.cam.ac.uk/teaching/0708/DigiCommI/tennenhouse1989layered.pdf)

------
_pmf_
It's so sad that examples like these are not part of every spec (in fact, the
very first thing in any spec). I understand the dangers of programming by
example rather than by spec, but a lack of canonical, verified examples has
been a problem with every protocol I've had to implement.

~~~
syncsynchalt
Good news: for cryptographic protocols and methods they are! Many of the
cryptographic primitives that I implemented for my test TLS 1.3 implementation
([https://github.com/syncsynchalt/tincan-
tls](https://github.com/syncsynchalt/tincan-tls)) come with test vectors in
the spec itself, and the rest always had test vectors supplied in a separate
doc.

For an example see Appendix C of the AES standard, FIPS-197:
[https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf)

In the case of TLS 1.3 I was able to use this IETF draft:
[https://tools.ietf.org/html/draft-ietf-tls-
tls13-vectors-07](https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-07)

------
rnotaro
Other thread from 26 days ago with the author:
[https://news.ycombinator.com/item?id=18200749](https://news.ycombinator.com/item?id=18200749)

~~~
odensc
That one's TLS 1.2, it's cool to see the differences though.

------
profmonocle
Once these middlebox vendors catch up to TLS 1.3, what's to stop them from
breaking the supported versions extension the same way they broke the client
version field? Anyone know if Chrome is using/planning to use GREASE with this
extension? (Couldn't find anything about it on Google.)

~~~
laggyluke
Hopefully efforts like this will make further ossification harder:

[https://www.ietf.org/mail-
archive/web/tls/current/msg26385.h...](https://www.ietf.org/mail-
archive/web/tls/current/msg26385.html)

------
ecesena
Can anyone confirm if the server certificate in the server hello message is
encrypted or not?

I've heard many time it's encrypted, but I can't find it explicitly written in
the RFC. And it seems unencrypted in this example.

~~~
rwbhn
According to the post the server cert is not sent in the server hello, but
later in the handshake, after encryption has been established.

~~~
rwbhn
Section 4.4 of the rfc[1] makes it clear the cert is sent encrypted. [1]
[https://tools.ietf.org/html/rfc8446#section-4.4](https://tools.ietf.org/html/rfc8446#section-4.4)

------
benkillin
What changes in the exchange if mutual tls authentication is being performed
(aka client cert authentication)?

~~~
tialaramex
It's actually more similar in TLS 1.3 than earlier versions. In earlier
versions a client uses a very different method to prove its identity then the
server does.

In TLS 1.3 they're completely symmetrical. First they show their certificate
and then they sign the entire transcript of the session handshake using their
private key and send that signature. The peer can use the public key from the
certificate and their own copy of the transcript to verify the signature.

If your peer doesn't offer an acceptable cert you abort. If they show you a
signature that doesn't verify you abort. This could be because they're an
imposter who doesn't have the private key, or it could be that a MitM has
changed the handshake, which will mean the transcripts don't match. Either way
you haven't got a secure connection.

The TLS 1.3 server gets to be more specific about the cert it wants from a
client. Where before it just says "Here's a list of CA roots I trust" now it
can specify other filters such as here are some OIDs I want to see in the
Certificate Policy.

~~~
brians
That’s a great write up. Another important change is that renegotiation to add
client cents is no longer supported. Old HTTPS could work like this:

    
    
      C->S: handshake, no client cert
      C->S: GET /
      C<-S: here you go
      C->S: POST /launch?target=Moscow
      C<-S: server-initiated-renegotiation
      C->S: everything from *this* byte on is covered by
      C->s: client cert
      C<-S: okay, launched
    

That is, the entangling of HTTP & TLS made some assumptions about the
authentication parts being there for controlling read access, not about
authenticating writes. Whoops. Nearly nobody using client cents wanted that
behavior. Now there are much simpler mechanisms with many fewer bizarre side
effects proposed at [https://tools.ietf.org/id/draft-ietf-httpbis-
http2-secondary...](https://tools.ietf.org/id/draft-ietf-httpbis-
http2-secondary-certs-01.html)

------
edwinyzh
Is there any similar illustrated explanations for other network protocols? I
mostly interested in IMAP4 and HTTP.

