zlacker

>>codero+(OP)
Note that this happens even when using a BlueCoat proxy in non-MITM mode. BlueCoat tries to "analyze" TLS connections, and rejects anything it doesn't understand. This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0.

In this case, it doesn't sound like they're reverting it because of overall breakage, but rather because it breaks the tool that would otherwise be used to control TLS 1.3 trials and other configuration. Firefox had a similar issue, where they temporarily used more conservative settings for their updater than for the browser itself, to ensure that people could always obtain updates that might improve the situation.

>>JoshTr+w
The fix should not have been reversion. The fix should have been a simple workaround that if the connection fails totally and no downgrade handshake attempt was made, make a new connection using 1.2 to start with, which would succeed and the connection opened. This would be equivalent to a downgrade handshake from 1.3 to 1.2 but without requiring all products support 1.3.

>>peterw+eN
The problem with this fix is that then as long as you have the fallback, the user gains none of the security properties of TLS 1.3 (since the attacker can always force a downgrade by sending junk to the client during the handshake) and has the additional cost of a second TLS negotiation.

While there was previously this "TLS fallback" implemented in Chrome to work around buggy endpoints, this was primarily due to buggy endpoints* which was a much larger issue and difficult to fix, while these middlebox issues affect a much smaller portion of users and we're hopeful that the middlebox vendors that have issues can fix their software in a more timely manner.

* TLS 1.3 moves the version negotiation into an extension, which means that old buggy servers will only ever know about TLS 1.2 and below for negotiation purposes and won't break in a new matter with TLS 1.3.