Comment by tialaramex

1 year ago

This is a reaction is what you need to know, they weren't "forward looking".

TLS 1.0, TLS 1.1, TLS 1.2 and TLS 1.3 all had problems where we've got an extension point in the prior standard, we just push this button and... now everything is on fire. Ugh.

So GREASE is for next time. When these same idiots ship their similarly incompetent garbage, the GREASE makes it not work. So the conversation goes like this:

Lazy Implementor: "Why doesn't my TLS 1.3 work?" Anybody: "Did you read the standard?" Lazy: "What do I look like? I've got a 16 digit IQ, of course I don't read standards" Anybody: "That's your credit card number, not an IQ, and you should read the standard" Lazy: "I think I know what an IQ is, and why should I read a stupid standard?" Anybody: "Suit yourself if you don't want working TLS"

For TLS 1.3 here is what we had to resort to because these morons are "too clever" to read standards documents and do what we told them to do in TLS 1.2 so we had to invent a hack.

When your TLS 1.3 client calls a server it says effectively "I'm a TLS 1.2 client, here continuing our earlier conversation # BigRandomNumber. Do you remember that? Oh, by the way, I also know how to [Fly Casually This Is TLS 1.3; here are some magic numbers]"

A TLS 1.2 server has never seen BigRandomNumber before, and so it says sorry, we need to start from the beginning, and does so, speaking TLS 1.2 as if you'd connected. So that's compatible.

A TLS 1.3 server recognises this wheeze and replies in kind, "Hello TLS 1.2 client, I'm the server some.computer.example, we can continue our conversation, by the way I too know [Fly Casually This Is TLS 1.3; and here are my magic numbers]". And immediately after this, everything is encrypted, because they were both actually talking TLS 1.3 and they've got key agreement via exchanging magic numbers.

Idiot middle boxes, which would have freaked out if anybody admitted they were actually using TLS 1.3, despite clear instructions not to freak out when the future happens, think this is just a continuing conversation, they must have been power cycled since it started, or maybe a device came from another site, it doesn't matter, it says it's an ongoing conversation so it's fine...

[Edited to fix various small things]

Perhaps in 40 years, we’ll still start encrypted sessions with TLS 1.2…

Hey, in 2024 we are still booting our 64bit PCs in 16bit real mode, just like the early 1980s! In the early 2000s, it was still crazy!

And we are still dealing with legacy PCI interrupt handling…

  • To be clear, that's not a TLS 1.2 encrypted session. It's a TLS 1.3 encrypted session but it's spelled in such a way that if you are looking for a TLS 1.2 encrypted session this matches your expectation.

    This carries on into the actual encrypted data packets. They look like TLS 1.2 messages with application data inside, but TLS 1.3 messages are actually just all spelled in such a way that all of them (regardless of whether they're application data or not) look like TLS 1.2 application data. So idiot middleboxes think it must just be application data, can't have any other meaniing.

    • In similar philosophy, in a middlebox that wanted to decrypt the flows, I simply put TLS1.3 inside HTTPS CONNECT inside TLS1.2 stream.

      Horrible, but it was easier than updating the middlebox...