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.
The particular version number (3.3 representing version 1.2) is due to TLS 1.0 being a minor revision of the SSL 3.0 protocol. Therefore TLS 1.0 is numeric version 3.1, TLS 1.1 is version 3.2, and so on.
Talk about versioning schemes bastardized to hell. If people do that to my specs I hope I'm not around to see it.
Summary: constantly make up new protocol "versions". If everything did this, then middleboxes "that do not allow protocol versions that they do not recognize" will never be functional in the first place.
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.
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.
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...
You can read detailed examples on Cloudflare's blog, they've been very eager to experiment with TLS 1.3: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...
Most big companies have contractual requirements to have an IPS/IDP to protect their customers. TLS1.3 means putting the decryption at the edge, which not everyone has done, then re-encrypting with something their IDP can decrypt.
Kinda reminded me of 'the box' from the Silicon Valley TV-show. I guess corporate managers will prefer something tangible over actual good practices.
Firefox users end up having to install it by hand, or else every website comes up as "you are being attacked by a MITM!!!!", which is technically true.
Click on the padlock in Firefox and hit the right arrow next to the domain and it will even say "Verified by: [your corp]"
Being able to use the improved protocol now is very nice.
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.
For an example see Appendix C of the AES standard, FIPS-197: 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
Nothing. It will happen just the same, so TLS 1.4 will have a “actually, this is the extension to use to determine the version”-extension
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.
After ServerHello is sent, the server knows a client now has everything it needs to establish all the keys, so it encrypts all subsequent data.
The pretence that this is just a TLS 1.2 session resumption continues though. So there's a wrapper shown in the document. This wrapper claims to be TLS 1.2 encrypted application data. In fact it's TLS 1.3 encrypted handshake data. For clarity in the document they show both the whole encrypted wrapper, its decrypted data, and then the separate components inside that decrypted data.
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.
C->S: handshake, no client cert
C->S: GET /
C<-S: here you go
C->S: POST /launch?target=Moscow
C->S: everything from *this* byte on is covered by
C->s: client cert
C<-S: okay, launched