Intent to remove: TLS 1.0 version downgrade

[David Benjamin]

[To get a potential confusion of the way first, we are not disabling TLS 1.0.]

Primary eng email

davi...@chromium.org

Summary

TLS has a version negotiation mechanism to securely introduce new versions without breaking compatibility. Yet each time a new one has been deployed, we have found servers that do not behave correctly and browsers have had to add insecure fallbacks to mitigate these broken servers. On every failed connection, we progressively retry, advertising lower and lower versions.

The SSL 3.0 fallback was removed last year due to POODLE. Guided by data from new fallback metrics, we will now be removing the TLS 1.0 fallback as well, raising the minimum fallback version to TLS 1.1.

This will not break TLS 1.0 servers, only those which implement version negotiation incorrectly. This Intent does not propose removing the TLS 1.1 fallback, but we hope to remove that too in the near future.

Motivation

With the fallback enabled, attackers can force version downgrades. FALLBACK_SCSV (RFC 7507) fixes this, but it requires server support. TLS fallbacks also mask implementation bugs and complicate error-handling and diagnosing failures.

Usage information

Over the past 14 days, the TLS 1.0 fallback was needed on 0.00% of HTTPS requests on the beta channel, after rounding.

Compatibility risk

Though the metrics are not on stable, rounding to 0.00% is pretty good. As 45 hits beta and 44 stable, we will monitor metrics and bug reports. If anything unexpected happens, we can revert. Firefox has also successfully removed the fallback (apart from a whitelist I believe).
Servers which require the TLS 1.0 fallback will stop working. As with the SSL 3.0 fallback, we will temporarily still perform the full fallback chain. If the 1.0 fallback is used, the resulting connection will be discarded and a dedicated error message surfaced, to more easily identify these servers.
For affected enterprise deployments, the SSLVersionFallbackMin administrative policy will be able to restore the 1.0 fallback. However, this is a temporary mitigation and will be disabled some time after Chrome 47.

OWP launch tracking bug
https://crbug.com/498998

David

[Hanno Böck]

I'm all for it, because essentially these downgrades are a security
risk.

Just asking: Why not remove the TLS 1.1 downgrade? What are the numbers
there?

I would be very surprised if that downgrade mattered at all. From what
I'm aware the vast majority of TLS implementations implemented TLS 1.1
and 1.2 at the same time. Is there anything out there that needs
insecure fallbacks when connecting with TLS 1.2 that will allow a
connection with TLS 1.1? I'd be very surprised (and would like to hear
what kind of product that is).

--
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[David Benjamin]

[adding net-dev back in so as not to fork the threads]

On Wed, Jun 10, 2015 at 6:29 PM Hanno Böck <ha...@hboeck.de> wrote:

I'm all for it, because essentially these downgrades are a security
risk.

Just asking: Why not remove the TLS 1.1 downgrade? What are the numbers
there?

I was wondering how long it'd take to someone to ask me that. :-)

That's hovering closer to the 0.05-0.08% range on beta, which is a bit on the high end, and we may see different numbers when it gets to stable. (We have older fallback metrics on stable, but they overcount it.)

I did add metrics that try to identify a number of known fallback triggers that occur after the ClientHello, since the fallback has ended up working around bugs other than plain intolerance:
https://chromium.googlesource.com/chromium/src/+/master/net/ssl/ssl_failure_state.h

It seems actually the bulk of the TLS 1.1 fallback is IIS's buggy AES-GCM implementation, back from the original MS14-066 fix. They later respun the fix without the bug, but it seems some servers only took the first version.

I'm going to wait to see what the numbers on stable look like and then decide what to do from there. I can think of a few different options for dealing with that one, so I'm optimistic. In the meantime, getting rid of the TLS 1.0 fallback leg is a nice first step.
 

I would be very surprised if that downgrade mattered at all. From what
I'm aware the vast majority of TLS implementations implemented TLS 1.1
and 1.2 at the same time. Is there anything out there that needs
insecure fallbacks when connecting with TLS 1.2 that will allow a
connection with TLS 1.1? I'd be very surprised (and would like to hear
what kind of product that is).

Even discounting the buggy GCM thing, it seems that 1.2 ClientHello intolerance exists. I'm as puzzled as you as to how that came about. (Could also just be a transient failure I suppose.) And I recall that SSLLabs or whoever found TLS 1.3 intolerant servers, so apparently it doesn't even end there. You'd think after going through this three or four times, servers would have figured it out by now!

David

[Yuhong Bao]

Here is a fun read:

https://bugzilla.mozilla.org/show_bug.cgi?id=1143035

(note the TLS version intolerance values and the quote from the release notes!)

[djb...@gmail.com]

Looks like it just broke our clients' Oracle Enterprise Manager Grid Control website. Now no one can access/control their Oracle installations. Bad idea?

On Wednesday, June 10, 2015 at 5:20:10 PM UTC-4, David Benjamin wrote:
> [To get a potential confusion of the way first, we are not disabling TLS 1.0.]
>
> Primary eng email
> davi...@chromium.org
>
>
>
> Summary
> TLS has a version negotiation mechanism to securely introduce new versions without breaking compatibility. Yet each time a new one has been deployed, we have found servers that do not behave correctly and browsers have had to add insecure fallbacks to mitigate these broken servers. On every failed connection, we progressively retry, advertising lower and lower versions.
>
> The SSL 3.0 fallback was removed last year due to POODLE. Guided by data from new fallback metrics, we will now be removing the TLS 1.0 fallback as well, raising the minimum fallback version to TLS 1.1.
>
> This will not break TLS 1.0 servers, only those which implement version negotiation incorrectly. This Intent does not propose removing the TLS 1.1 fallback, but we hope to remove that too in the near future.
>
> Motivation
> With the fallback enabled, attackers can force version downgrades. FALLBACK_SCSV (RFC 7507) fixes this, but it requires server support. TLS fallbacks also mask implementation bugs and complicate error-handling and diagnosing failures.
>
> Usage information
> Over the past 14 days, the TLS 1.0 fallback was needed on 0.00% of HTTPS requests on the beta channel, after rounding.
>
>

> Compatibility riskThough the metrics are not on stable, rounding to 0.00% is pretty good. As 45 hits beta and 44 stable, we will monitor metrics and bug reports. If anything unexpected happens, we can revert.

[David Benjamin]

As a temporary workaround, you may set the SSLFallbackVersionMin administrative policy to tls1. That will work around it temporarily until a proper fix is deployed. (Note this is temporary. It will stop working in a future version of Chrome.)

https://www.chromium.org/administrators/policy-list-3#SSLVersionFallbackMin

After that, please reach out to Oracle. This bug may have been resolved in a newer version, or in another configuration. (Does this use Weblogic? I've found reference on the internet to Weblogic having two SSL implementations, a Certicom and a JSSE one. Allegedly the Certicom one is buggy but the JSSE one might not be?)

David

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/531514bd-c920-4d43-839e-42bc4f3461a1%40chromium.org.

[Hanno Böck]

On Tue, 8 Sep 2015 05:25:22 -0700 (PDT)
djb...@gmail.com wrote:

> Looks like it just broke our clients' Oracle Enterprise Manager Grid
> Control website. Now no one can access/control their Oracle
> installations. Bad idea?

Yes, very bad idea.

I mean it's a very bad idea that Oracle ships products with
obviously broken TLS stacks for an issue that has been widely known for
years. You should ask them for a fix.

It certainly is a very good idea that browsers stop accepting this
bullshit by deactivating workarounds that cause security issues
themselve.

[goelli]

A10 Loadbalancers seem to have the same problem on the management interface...

[iso...@gmail.com]

I get the need for security but you clearly have no enterprise experience, no idea of how large companies work, and no ability to understand the difference between "real-world attack" and "hypothetical attack."

[David Benjamin]

For enterprises, we provide an administrative policy, SSLVersionFallbackMin, which may be set to temporarily work around this.

But do reach out to Oracle to get this fixed. The server is not implementing TLS correctly. My understanding---although I'm still waiting for someone to confirm it---is that upgrading WebLogic to 10.3.3 or later and switching to the JSSE backend (which is default if you upgrade to 12.1.x) fixes their bug.

David

[David Benjamin]

On Wed, Sep 9, 2015 at 3:15 PM goelli <anmel...@goelli.de> wrote:

A10 Loadbalancers seem to have the same problem on the management interface...

 

If you need to temporarily work around this, you can set the SSLVersionFallbackMin administrative policy in your organization. Or if only a few people need to access the management interface, the command-line flag --ssl-version-fallback-min=tls1 also works.

This workaround will stop working in the future, but you'll then have time to contact A10 and see about fixing their bug. It's possible they've already resolved it in a newer version of their software and you only need to take updates.

David

[kh.q...@gmail.com]

I had run into the problem with TLS version intolerance when using Weblogic 10.3.5. After switching to JSSE SSL through Weblogic console, AND upgrading the JDK to 1.6 update 101 (non-public update through paid support contract), the problem appears to be resolved. Without latest Java 1.6 update, the switch to JSSE surfaced a different error instead: ssl_error_weak_server_ephemeral_dh_key

For those with the option to go with a newer release of Weblogic that works with Java 8, that's probably the better option. But if you're stuck with Weblogic 10.3.5 and Java 6, this may work for you as well.

[David Benjamin]

On Tue, Sep 22, 2015 at 1:46 PM <kh.q...@gmail.com> wrote:

I had run into the problem with TLS version intolerance when using Weblogic 10.3.5.  After switching to JSSE SSL through Weblogic console, AND upgrading the JDK to 1.6 update 101 (non-public update through paid support contract), the problem appears to be resolved. 

Great! Thanks for confirming.

 

Without latest Java 1.6 update, the switch to JSSE surfaced a different error instead: ssl_error_weak_server_ephemeral_dh_key

Oh. Yeah, that's a different issue that also started to be enforced in Chrome 45. A pity that older JDKs have problems there... do you know what cipher suite the various JDKs offer? The best option is to enable ECDHE_RSA and disable DHE_RSA ciphers. If you can't do that, you can also disable DHE_RSA ciphers and rely on plain RSA ones. (I'm assuming Java isn't going to let you change the group.)

 

For those with the option to go with a newer release of Weblogic that works with Java 8, that's probably the better option.  But if you're stuck with Weblogic 10.3.5 and Java 6, this may work for you as well.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/a30a4b33-7d74-4bc1-93e6-fcf6c71c6c0c%40chromium.org.

[citize...@gmail.com]

For Oracle Enterprise Manager 11.1, with WebLogic 3.2 and Java6 (yes there are plenty still out there) on 9/28 OWS provided this doc with patching info.

Unable to Access Enterprise Manager 11g Grid Control from Console (SSL server probably obsolete.) (Doc ID 2053331.1)

On Wednesday, June 10, 2015 at 4:20:10 PM UTC-5, David Benjamin wrote:
> [To get a potential confusion of the way first, we are not disabling TLS 1.0.]
>
> Primary eng email
> davi...@chromium.org
>
>
>
> Summary
> TLS has a version negotiation mechanism to securely introduce new versions without breaking compatibility. Yet each time a new one has been deployed, we have found servers that do not behave correctly and browsers have had to add insecure fallbacks to mitigate these broken servers. On every failed connection, we progressively retry, advertising lower and lower versions.
>
> The SSL 3.0 fallback was removed last year due to POODLE. Guided by data from new fallback metrics, we will now be removing the TLS 1.0 fallback as well, raising the minimum fallback version to TLS 1.1.
>
> This will not break TLS 1.0 servers, only those which implement version negotiation incorrectly. This Intent does not propose removing the TLS 1.1 fallback, but we hope to remove that too in the near future.
>
> Motivation
> With the fallback enabled, attackers can force version downgrades. FALLBACK_SCSV (RFC 7507) fixes this, but it requires server support. TLS fallbacks also mask implementation bugs and complicate error-handling and diagnosing failures.
>
> Usage information
> Over the past 14 days, the TLS 1.0 fallback was needed on 0.00% of HTTPS requests on the beta channel, after rounding.
>
>

> Compatibility riskThough the metrics are not on stable, rounding to 0.00% is pretty good. As 45 hits beta and 44 stable, we will monitor metrics and bug reports. If anything unexpected happens, we can revert.