Intent to Deprecate and Remove: TLS 1.3 downgrade hardening bypass (take two)

[David Benjamin]

This is a redo of https://groups.google.com/a/chromium.org/d/msg/blink-dev/zBYneRf242s/OXCLsqoeAgAJ which was postponed due to the flag not working right. The changes since then:

• The flag works and the admin policy exists, starting Chrome 79

• Updated instructions have been posted in enterprise release notes

• UMA numbers have gone further down

• Firefox’s implementation is in progress and Safari’s shipped in macOS 10.15

• Milestones have been updated

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 81, which will reach the stable channel in March 2020.

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.

In Chrome 78’s enterprise release notes, posted October 2019, we included instructions for administrators to check if their proxy was affected and upgrade if so. The release notes also notified administrators this will ship in Chrome 81, so they can prepare. We also included a list of known affected products in Chrome 73’s release notes, posted March 2019. 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: in progress

Safari: shipped in 10.15 (observed by testing macOS 10.15.1)

Alternative implementation suggestion for administrators

If running an affected proxy, update it. See Chrome 78’s enterprise release notes, posted October 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 control this change, TLS13HardeningForLocalAnchorsEnabled, is available starting Chrome 79. Administrators who need more time to resolve this problem may use it until Chrome 86, due to be released in October 2020. Administrators may also use it to test their proxies before we ship this.

Usage information from UseCounter

Metrics from Chrome report that under 0.01% 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

[Philip Jägenstedt]

Hi David,

This seems like a very well thought out rollout which gives ample time for anyone affected to revert and address the issue.

The only thing that seems concerning and surprising here is the "under 0.01% of connections" broken, since that seems like a bigger number than I would have guessed from the description. Is 0.01% just the granularity of reporting, or is it definitely >0.005%?

If usage isn't entirely negligible, will there be a way for affected end users to revert the change in chrome://flags or similar, or is this strictly controlled by enterprise policy?

--
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/CAF8qwaAvbOzkZvy2Rw2%2Bnfh%2BwscZDKM13c176C9AaW93MVfBDA%40mail.gmail.com.

[David Benjamin]

Er, pretend I just said 0.01% without the "under". It's currently at 0.008%, but there was a bit of a drop from 0.01% right after Thanksgiving. I wasn't sure whether to account for holiday usage patterns, so I figured I'd be fuzzy which... in hindsight was just unhelpful. :-)

There is a chrome://flags entry, though I don't expect non-enterprise scenarios to be affected. It requires a TLS MITM proxy with a local trust anchor on your machine. Outside of enterprise, this sort of silliness is just antivirus. We're not aware of any affected AVs, and, bucketing by AVs in UMA, it doesn't appear to be correlated with any AV product. If there is one, AVs tend to autoupdate so hopefully that can be fixed quickly.

[Philip Jägenstedt]

Alright, the existence of a chrome://flags entry seems like a good fallback. My assumption is that not have a proxy like this also use enterprise policy, and that some users on such networks will need to figure out for themselves what to do. Is that not likely to be the case?

Nevertheless, LGTM1, as there is no specific usage number where this would seem obviously safe, and actually trying to ship this and keeping on top of the feedback is what it will take to minimize any negative fallout.

[David Benjamin]

On Tue, Dec 10, 2019 at 8:51 AM Philip Jägenstedt <foo...@chromium.org> wrote:

Alright, the existence of a chrome://flags entry seems like a good fallback. My assumption is that not have a proxy like this also use enterprise policy, and that some users on such networks will need to figure out for themselves what to do. Is that not likely to be the case?

I'm not sure if you're asking whether it could affect people in, say, random networks like coffee shop wifi, or whether there are people in managed environments that don't use enterprise policy, so I'll answer both:

For the former, it would not affect random networks. It requires the machine be configured with an extra trust anchor (root CA). Otherwise, it's a network attack and is stopped by certificate verification, as it should be. Apart from AVs (which add the trust anchor at install-time), you'd typically need some kind of managed environment to configure the trust anchor across all the relevant machines.

For the latter, I don't know how enterprise policy usage tends to look like around managed environments. That's really a general Chrome question. :-) Historically the enterprise team has asked for enterprise policies and seemed happy enough with them. It is the right tool for this sort of thing after all.

[Philip Jägenstedt]

On Tue, Dec 10, 2019 at 3:29 PM David Benjamin <davi...@chromium.org> wrote:

On Tue, Dec 10, 2019 at 8:51 AM Philip Jägenstedt <foo...@chromium.org> wrote:

Alright, the existence of a chrome://flags entry seems like a good fallback. My assumption is that not have a proxy like this also use enterprise policy, and that some users on such networks will need to figure out for themselves what to do. Is that not likely to be the case?

I'm not sure if you're asking whether it could affect people in, say, random networks like coffee shop wifi, or whether there are people in managed environments that don't use enterprise policy, so I'll answer both:

For the former, it would not affect random networks. It requires the machine be configured with an extra trust anchor (root CA). Otherwise, it's a network attack and is stopped by certificate verification, as it should be. Apart from AVs (which add the trust anchor at install-time), you'd typically need some kind of managed environment to configure the trust anchor across all the relevant machines.

Glad to hear this case doesn't exist :)

For the latter, I don't know how enterprise policy usage tends to look like around managed environments. That's really a general Chrome question. :-) Historically the enterprise team has asked for enterprise policies and seemed happy enough with them. It is the right tool for this sort of thing after all.

Right, an enterprise policy is definitely needed, just wondering if there's any recourse for people who aren't under enterprise policy for some reason, and it sounds like there is.

Still LGTM1 :)

[Daniel Bratell]

LGTM2

/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/CAARdPYc97Qt_G0QE11oNCuMy5sPfU0-AD%2BTXKXHtJP0VuZnp%3DA%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e3bc426e-75ee-c061-bd13-c9ea9bbc40c6%40gmail.com.