Intent to Deprecate and Remove: TLS 1.3 downgrade hardening bypass

[David Benjamin]

(There is a bit of a weird double-negative thing going on as we’re really “adding” downgrade hardening to more connections, but the deprecate/remove template is probably more appropriate.)

Primary eng emails

davi...@chromium.org

sva...@chromium.org

Summary

TLS 1.3 includes a backwards-compatible hardening measure to strengthen the protocol’s protections against downgrade to TLS 1.2 and below. The existing measures in TLS 1.2 are slightly fragile, which exacerbated some attacks over the years. However, when we shipped TLS 1.3 last year, we had to partially disable this measure due to incompatibilities with some non-compliant TLS-terminating proxies.

Chrome currently implements the hardening measure for certificates which chain up to known roots, but allows a bypass for certificates chaining up to unknown roots. We intend to remove this bypass and apply the hardening to all connections in Chrome 78, which will reach the stable channel in October 2019.

Motivation

Downgrade protection mitigates the security impact of the various legacy options we retain for compatibility. This means user’s connections are more secure and, when security vulnerabilities are discovered, it is less of a scramble to respond to them. (That, in turn, means fewer broken sites for users down the road.)

Additionally, this measure is a MUST-level requirement in TLS 1.3, so we align with the TLS specification and other TLS implementations like OpenSSL.

Interoperability and Compatibility Risk

Users behind a non-compliant TLS-terminating proxy may experience connection failures when connecting to TLS-1.3-capable servers. This results in a network error with error code ERR_TLS13_DOWNGRADE_DETECTED.

Note that enforcement for known roots has already shipped, so only users behind TLS-terminating proxies will be affected by this change. Such proxies are primarily used in enterprise environments. Antivirus products sometimes use them too, though we are unaware of any affected antivirus products. Note also that we are not requiring servers or proxies implement TLS 1.3, only that they correctly implement the 11-year-old TLS 1.2 protocol.

In Chrome 73’s enterprise release notes, posted March 2019, we included instructions for administrators to check if their proxy was affected and upgrade if so. Additionally, rollout will be controlled by field trials, so we can roll it back if necessary.

Edge: n/a; no TLS 1.3 support yet

Firefox: hardening is currently disabled, no official signals w.r.t. enabling

Safari: hardening is currently disabled, no official signals w.r.t. enabling

Alternative implementation suggestion for administrators

If running an affected proxy, update it. See Chrome 73’s enterprise release notes, posted March 2019 for instructions to test the proxy.

We recommend administrators treat these out-of-date proxies as a security risk, rather than merely a compatibility risk. The TLS handshake requires each endpoint generate and send a random value. These proxies, instead of generating their own value, copy the value from the origin server. Random values in security protocols are there for a reason, so this flaw additionally invalidates all security analysis for TLS when used by this proxy.

An administrative policy to temporarily revert this change, BypassTLS13DowngradeHardeningForLocalAnchors, will be added. Administrators who need more time to resolve this problem may use it until Chrome 82, due to be released in April 2020.

Usage information from UseCounter

Metrics from Chrome report that 0.02% of connections to a known-TLS-1.3-capable server would be broken by this change.

Entry on the feature dashboard

https://www.chromestatus.com/feature/5128354539765760

Requesting approval to remove too?

Yes

[Christopher Wood]

In case it's helpful, the macOS Catalina and iOS 13 betas both enforce TLS 1.3 downgrade prevention for the system, which includes Safari. We’ve not seen any significant increase in failure rates as a result.

[David Benjamin]

Update: it turns out we had a bug in how the flags were routed through, which means the testing instructions in Chrome 73 enterprise release notes did not actually work. The metrics are good, but we'll delay this by a couple of cycles to be prudent, so we can publish updated testing instructions. Our new plans are thus:

- We'll fix the flag for Chrome 78 and publish updated instructions in the release notes, asking administrators to test again.

- In Chrome 80, we'll disable the local trust anchor bypass, with admin policy override, etc. The date for removing the policy will be pushed forward to Chrome 84 to match.

I've updated the feature dashboard entry to target 80. I'll send out a new intent email then.

[Daniel Bratell]

So this needs to eventually happen but 0.02% of connections is not zero so there will be a compatibility hit.

What more do you know about those connections?

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaDSyDi%2B9S7RBreNxUUupdK9%3D19Jntg14uXmhkxPtKc-YA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Adam Langley]

On Thu, Aug 29, 2019 at 8:26 AM Daniel Bratell <bra...@opera.com> wrote:

So this needs to eventually happen but 0.02% of connections is not zero so there will be a compatibility hit.

What more do you know about those connections?

This issue is caused by bad MITM proxies so it's based on client network, not server incompatibility. There are more details in our note to the TLS WG list but the problematic case will likely look like a version of Chromium for which all HTTPS connections fail in a specific, corporate client network; hopefully followed by a quick update of the buggy MITM proxy in question.

Cheers

AGL

[bratell]

Ah, I hope it will work out. Maybe it could be enabled for test purposes in canary to flush out those networks. Is it even possible to signal to the user what is going on?

Anyway, davidben withdrew this intent pending more data, so from the api owner perspective this is no longer on our todo list.

/Daniel

[David Benjamin]

Data-wise, I don't think there is much left to wait for. The metrics are comparable to past successful deprecations. The concern is simply that the instructions we previously gave administrators didn't work. Especially given enterprise users are often underrepresented in metrics, it seemed prudent to correct that first. But ultimately we can only measure what we can measure, and at some point it's time to plug the security risk.

Enabling in release channels ahead of time is certainly plausible and would make sense. It's worth noting that would happen anyway via the release channels, the same as any other change.

As far as user-visibility goes, the scenario is certainly detectable and currently gives a specific ERR_TLS13_DOWNGRADE_DETECTED error code, with the caveat that, being a security measure, it is of course not distinguishable from an attempted downgrade attack. The error message is currently fairly generic, though it does direct users to "try [c]hecking the proxy and the firewall". Including more details is certainly technically possible, but that's a UX question and not something we've historically done.