Can't tell whether ploxiln knew this and was just using it as an example anyway, but the TLS version indicator is dead anyway, the TLS 1.3 specification (passed last call but yet to be published) says to always treat this as though you're TLS 1.2 and marks it "legacy_version" but then you hide the real version number inside a new extension which they aim to prevent from rusting in place.
This was done because the version code ploxiln describes is so thoroughly rusted shut in middleboxes that TLS 1.3 would be undeployable in practice without such a changes.
Also, "fallback retries" aren't a thing. The reason is downgrade protection. If I have a new protocol (TLS 1.3) with better security, but I'm happy to retry with an older protocol (say TLS 1.2) if that doesn't work, obviously bad guys on the path will just ensure my TLS 1.3 connections all fail so that they can attack the weaker TLS 1.2
TLS 1.3 guards against an attacker who tries to downgrade a TLS 1.3 connection, if both sides know TLS 1.3 and yet somehow the packets when they arrive from the client say TLS 1.2 on them, the Hello "random" value sent from the server will have the message "DOWNGRD" scribbled across part of it, and the client sees this and aborts because somebody is tampering with the connection. If the middlebox tries overwriting the bytes with "DOWNGRD" written in them then the random data doesn't match up and the connection fails.
What I don't get is why Google really bothers with middleboxes, if a business deploys them and then gets shut off from Google services the admins won't take long to find and disable that middlebox. And if they don't they go bankrupt, whatever happens the Internet wins.
Raymond Chen wrote some articles about how this impacted Windows 95. It doesn't matter that program X completely ignored the documentation in Windows 3.x and so it "makes sense" technically that in Win95 that program crashes, the user experience is that Windows 95 broke Program X, and they just bought Windows 95, so they will demand a refund and moan to all their friends.
There is a limited tolerance for Chrome versions that don't work, because the lesson customers get is "Don't run Chrome" not "My middlebox is garbage". The tolerance is increased for security problems, so Google is more willing to lose say 0.1% of users because they enabled TLS 1.3 (the remaining 99.9% of users get improved security) than to lose 0.1% of users because they added a cool 3D logo and it crashes on a specific model of video card or version of Windows due to a driver bug. But losing 10% of your users is a disaster, and that was the ballpark for TLS 1.3 in earlier drafts (before it was taught to sidestep more middleboxes).
And how about putting an informative tooltip on google's pages?
They could use Javascript to query a test server, which responds with the correct headers. If the answer doesn't get trough, print a message.
Hopefully someone will notice and bring it up with the IT or ISP, especially if the message says to do so, and that Google/internet could stop working in the future.
Actually,get more popular sites to do it, like Facebook, Twitter, Apple and Microsoft (heck, they could do it as a part of the operating system): if a lot of websites say it, users will tend to think that something is wrong on their end.
This was surely already brought up as a solution, so I wonder what the catch was, if any?
Since this would be browser-independent, the browser wouldn't get blamed, and if it's only a mild inconvenience, it shouldn't bother people that much (they have been using the web despite more invasive cookie notices). I would expect it to allow a critical number of non conformant devices to be quickly disabled as a result.
I was more thinking about querying something like testtls.google.com, that would analyze the results server-side (this might require an extra round-trip), and return them to be displayed.
Presumably these middleboxes have some critical density.
If google deploys 1.3 and 50% of corporate users can no longer reach google's services, that would be seen as google's mistake. Moreover, that would hurt google quite a lot.
The issue is that these boxes are already deployed, and it wasn't noticed just how shitty they were until we tried to deploy 1.3 . The system has essentially rusted shut.
I wish Google, Apple and Microsoft just worked as an alliance here. They are all working on TLS and if together they deployed TLS 1.3 no middlebox on earth would stand a chance.
Sometimes I wonder the same. Maybe they think it's hard to change something in an enterprise? Or they are afraid of losing the enterprise customer (because Microsoft works here!). Or just don't want to use their influence to evolve the protocol?
As you say, "fallback retries" are bad. But that is what browsers did, some years ago, when tls1.2 was less common ... and they added the TLS_FALLBACK_SCSV "not-a-cipher-suite" to try to detect attacker-caused downgrades in a dumb-server-compatible way ...
This was done because the version code ploxiln describes is so thoroughly rusted shut in middleboxes that TLS 1.3 would be undeployable in practice without such a changes.
Also, "fallback retries" aren't a thing. The reason is downgrade protection. If I have a new protocol (TLS 1.3) with better security, but I'm happy to retry with an older protocol (say TLS 1.2) if that doesn't work, obviously bad guys on the path will just ensure my TLS 1.3 connections all fail so that they can attack the weaker TLS 1.2
TLS 1.3 guards against an attacker who tries to downgrade a TLS 1.3 connection, if both sides know TLS 1.3 and yet somehow the packets when they arrive from the client say TLS 1.2 on them, the Hello "random" value sent from the server will have the message "DOWNGRD" scribbled across part of it, and the client sees this and aborts because somebody is tampering with the connection. If the middlebox tries overwriting the bytes with "DOWNGRD" written in them then the random data doesn't match up and the connection fails.