[ocdtrekkie]

QUIC is purpose-built to circumvent middleboxes. Enterprise networking benefits greatly from providing security and accountability via such middleboxes. The effort required to properly secure a network trying to circumvent your network security is costly and more complex.

[bawolff]

Some say "security and accountability" others say launch a MITM attack to spy on employees.

[ocdtrekkie]

Depends on the company, obviously. I don't care if employees do whatever on work computers, I care about protecting my network and my users.

In practice, all of this attempt to bypass middleboxes does not help my users browse securely. It makes it harder to block ads, it makes it harder to detect phishing sites and other threats, and that's about it.

[aseipp]

I mean, that's a trend that's been ongoing in both the HTTP and TLS world for a while now, independent of QUIC. Similar complaints arose with the announcement of HTTP/2 being TLS only, if I recall, and TLS 1.3 would probably already be widely deployed right now if not for some complications with deployed middleboxes causing connection failures in the wild (which I don't entirely blame on them; after all, bugs happen...)

[tialaramex]

If you simply obey the standard, everything works perfectly well. For example, the only standard way to build HTTPS middleboxes is to fasten a standards compliant client and server together, when a corporate user tries to visit google.com the server presents them with its Certificate for google.com from your corporate CA, and the client connects to the real google.com, now the flow is naturally plaintext inside your middlebox and you can do whatever you want.

If you did that, when TLS 1.3 comes along, your middlebox client connects to google.com, the client says it only knows TLS 1.2, google.com are OK with that, everything works fine. When the corporate user runs Chrome, they connect to the middlebox server, it says it only knows TLS 1.2, that's fine with Chrome, everything works fine. The middlebox continues to work exactly as before, unchanged.

So what happened in the real world? Well of course it's cheaper to just sidestep the standards. Sure, doing so means you fatally compromise security, but who cares? So you don't actually have a separate client and server wired together, you wire pieces of the two connections together so that you can scrimp on hardware overhead and reduce your BOM while still charging full price for the product.

The nice shiny Chrome says "Hi, google.com I'm just continuing that earlier connection with a TLS 1.2 conversation we had, you remember, also I know about Fly Casual This is Really TLS 1.3 and here are some random numbers I am mentioning"

The middlebox pretends to be hip to teen slang, sure, pass this along and we'll pretend we know what "Fly Casual This Is Really TLS 1.3" means, maybe we can ask another parent later and it sends that to the real google.com

Google.com says "Hi there, I remember your previous connection wink wink and I know Fly Casual This Is Really TLS 1.3 too" and then everything goes dark, because it's encrypted.

The middlebox figures, well, I guess this was a previous connection. I must definitely have decided previously whether connecting to Google was OK, so no need to worry about the fact it mysteriously went dark before I could make a decision and it takes itself out of the loop.

Or worse, the middlebox now tries to join in on both conversations, even though it passed along these "Fly Casual This Is Really TLS 1.3" messages yet it doesn't actually know TLS 1.3, so nothing works.