undefined | Better HN

0 pointsreanimus2mo ago0 comments

The problem is there are many middleboxes that monitor port 443 and will drop any traffic that they can't decode as TLS (which in this case means TLS 1.2 or below). The choice was between masking traffic as an earlier version of TLS or forcing the replacement of all of those middleboxes. It's a no-brainer.

0 comments

pseudohadamard2mo ago

Then don't put it on 443 and pretend (badly) that it's TLS 1.2. Given that QUIC also uses 443 (and 80) without too many problems and that doesn't look anything remotely like TLS, presumably non-TLS 1.2 traffic to 443 is OK.

The problem isn't really the port used, it's the uncanny-valley approach they took in creating something that looks like a creepy zombie version of TLS 1.2, which keep-suspicious-things-out appliances quite rightly get suspicious over.

jcgl2mo ago

But QUIC doesn’t use 443/TCP; it uses 443/UDP. So it’s unsurprising that middleboxes that care about 443/TCP would ignore it. That doesn’t support your claim that “non-TLS 1.2 traffic to 443 is OK.”

pseudohadamard2mo ago

The point I was trying to make, probably badly, was that there was no need to make TLS 1.3 pretend to be TLS 1.2 going to TCP/443. They could have picked some new port, called it TLS 2.0 (which is what it actually is), and run with that. If QUIC can pick its own port and, by the looks of it, not run into massive problems, there's no reason why TLS 2.0 can't do so too.

j / k navigate · click thread line to collapse

0 comments

pseudohadamard2mo ago

jcgl2mo ago

pseudohadamard2mo ago

j / k navigate · click thread line to collapse