Intent to Deprecate: TLS 1.0 and TLS 1.1

[David Benjamin]

(This was announced as a blog post yesterday.)

Primary eng (and PM) emails

davi...@chromium.org

awha...@chromium.org

Summary

Deprecate TLS 1.0 and 1.1 in Chrome, targeting removal in Chrome 81 (early 2020). During the deprecation period, sites using those protocols will show a warning in DevTools. After which, they will fail to connect if they have not upgraded to TLS 1.2 by then.

Motivation

TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. TLS 1.2, published ten years ago, addresses several weaknesses in TLS 1.0 and 1.1:

• TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message. TLS 1.2 switches this to SHA-2. (See the SLOTH attack.)

• TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature (note this is not the signature in the certificate). TLS 1.2 makes this negotiable and adds SHA-2 as an option. (Also see the SLOTH attack.)

• TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS’s CBC mode construction is flawed and was vulnerable to a series of attacks, most recently Lucky13. TLS 1.2 introduces AEAD-based ciphers which avoid this and are more efficient.

• TLS 1.0’s CBC ciphers additionally construct their initialization vectors incorrectly, making them vulnerable to the BEAST attack. TLS 1.1 fixed this.

Supporting TLS 1.2 is a prerequisite to avoiding the above problems. Additionally, the industry has been moving towards this deprecation. TLS 1.0 is no longer PCI-DSS compliant and the TLS working group has adopted a document to deprecate TLS 1.0 and 1.1.

Interoperability and Compatibility Risk

Once removed, sites that only support TLS 1.0 or 1.1 will fail to connect. The current usage is a little high (0.5%, see below), but we are providing an extended deprecation period. The target removal date is Chrome 81, due early 2020. Additionally, other browsers are also deprecating these protocols:

Edge: Supported, positive to removal

Firefox: Supported, positive to removal

Safari: Supported, positive to removal

Enterprise deployments can preview the TLS 1.0 and 1.1 removal today by setting the SSLVersionMin policy to “tls1.2”. For enterprise deployments that need more time, this same policy can be used to re-enable TLS 1.0 or TLS 1.1 until January 2021.

Alternative implementation suggestion for web developers

Sites should enable TLS 1.2 or later. We also encourage all sites to revisit their TLS configuration. Our current criteria for modern TLS is the following:

• TLS 1.2 or later.

• An ECDHE- and AEAD-based cipher suite. AEAD-based cipher suites are those using AES-GCM or ChaCha20-Poly1305. ECDHE_RSA_WITH_AES_128_GCM_SHA256 is the recommended option for most sites.

• The server signature should use SHA-2. Note this is not the signature in the certificate, made by the CA. Rather, it is the signature made by the server itself, using its private key.
  
  

The older options—CBC-mode cipher suites, RSA-encryption key exchange, and SHA-1 server signatures—all have known cryptographic flaws. Each has been removed in the newly-published TLS 1.3. We retain them at prior versions for compatibility with legacy servers, but we will be evaluating them over time for eventual deprecation.

Note that supporting TLS 1.2 and the above options is completely backwards-compatible. They do not require a new certificate, and sites which need to talk to legacy clients may support both modern and obsolete settings at the same time. However, some attacks are enabled by merely supporting older versions, so servers should not enable legacy options where unnecessary.

Usage information from UseCounter

0.5% of HTTPS connections made from Chrome negotiate TLS 1.0 or TLS 1.1.

Entry on the feature dashboard

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

Requesting approval to remove too?

The target removal is M81, in early 2020. As that’s over a year away, I’ll leave that for another Intent. But we’ll include this in the DevTools warning.

[Rick Byers]

Although we normally don't do "hopeful deprecations", this one seems special to me. There's clearly a coordinated industry movement here on good security grounds, with a long time period and necessary opt-outs.

My intuition is that y'all know how to successfully drive shifts in the TLS ecosystem, effectively balancing compat constraints, and I'm unlikely to be able to add much value by questioning your judgement! But, if you'll bear with me a bit, I would find it really helpful for the blink deprecation process generally to dive in a little into what makes this case special. Maybe we can add it as a case study to our compat principles to help explain when a "hopeful deprecation" with long removal timeframe is actually appropriate and likely to be setup for success (instead of the more common case of being just wishful thinking).

Are you able to quantify the extent and severity of breakage beyond that scary 0.5% of connections number? Eg. do we have metrics that ignore all sub-resource (or have we done a crawl of the top N sites) to help estimate what fraction of page views would be totally broken? Do we know anything about the distribution of origins - eg. how that number would go down if the top ~100 impacted sites were fixed? Other than the co-ordinated industry movement, do you have any other reason to believe that the vast majority of impacted servers (including, I suppose, IoT devices) will actually get updated for this by the deadline? Maybe there's something to be said about how it's much easier to update a non-trivial fraction of the world's HTTPS servers than it would be to update a non-trivial fraction of the worlds websites (where our "no hopeful deprecations" principle is normally applied)?

Thank you!

  Rick

P.S. In case anyone reading this is wondering: no this isn't process theater - this is actually the very I've heard of this concrete plan (as opposed to some thing I've been engaged with internal to Google for awhile), and I consider that a very positive thing.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaCiPd5nCE7Z75oUszJFXDDwn2w72wx8m%3DTzHMFX%3DbWOQA%40mail.gmail.com.

[PhistucK]

While the mentioned browsers indeed matter, I think the variety of mobile browsers is also significant. Did anyone ask Samsung Internet, QQ, 360 and vendors that default to their built in browser whether they are planning to join this coordinated effort? I think Samsung does not update its browser as regularly as Chrome, for example.

Built in browsers of older mobile operating system versions will obviously not change, so it cannot be a fully coordinated effort and will make the users wonder ("why is this old device able to browse to this website but mine is not?"), but, nothing anyone can do here.

☆PhistucK

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/CAFUtAY-50XikL0eddBv4pftBs_8gCi94KnfE5U%2Bd-wrkiwuzOA%40mail.gmail.com.

[Adam Langley]

On Tue, Oct 16, 2018 at 6:06 PM Rick Byers <rby...@chromium.org> wrote:

My intuition is that y'all know how to successfully drive shifts in the TLS ecosystem, effectively balancing compat constraints, and I'm unlikely to be able to add much value by questioning your judgement! But, if you'll bear with me a bit, I would find it really helpful for the blink deprecation process generally to dive in a little into what makes this case special. Maybe we can add it as a case study to our compat principles to help explain when a "hopeful deprecation" with long removal timeframe is actually appropriate and likely to be setup for success (instead of the more common case of being just wishful thinking).

We have been able to eliminate a number of old, unfortunate aspects of TLS over time: SSLv3, RC4, version fallbacks etc. I can only guess why things might be more tractable in TLS than for more normal web features:

TLS version support is a property of the web server, not of the web site. Thus there's fewer things that have to change. Also, the software on each web server is going to be one of not-that-many possible TLS implementations so it's generally a question of just updating it. That's in marked contrast to web features, which might be touched by bits of Javascript scattered across web pages where there's no automated way to clean them up.

We also operate on very long timescales. TLS 1.2 was released ten years ago. Based on a recent paper, it took five years for TLS 1.2 to start to catch on and it's been ramping up to nearly 100% ever since. On the server side things are even slower: we still support Windows XP there.

Are you able to quantify the extent and severity of breakage beyond that scary 0.5% of connections number? Eg. do we have metrics that ignore all sub-resource (or have we done a crawl of the top N sites) to help estimate what fraction of page views would be totally broken? Do we know anything about the distribution of origins - eg. how that number would go down if the top ~100 impacted sites were fixed?

We don't have more detailed analysis at the moment. When things get closer to the time, we'll start to look into that in case any specific devrel outreach can help us get closer to our goal.

 

Other than the co-ordinated industry movement, do you have any other reason to believe that the vast majority of impacted servers (including, I suppose, IoT devices) will actually get updated for this by the deadline?

It's never easy, and perhaps the internet is getting harder and harder to steer over time, but we've done it before starting from this position.

Cheers

AGL 

[Adam Langley]

On Tue, Oct 16, 2018 at 11:12 PM PhistucK <phis...@gmail.com> wrote:

While the mentioned browsers indeed matter, I think the variety of mobile browsers is also significant. Did anyone ask Samsung Internet, QQ, 360 and vendors that default to their built in browser whether they are planning to join this coordinated effort? I think Samsung does not update its browser as regularly as Chrome, for example.

Such organisations are welcome to join but they're not active (as far as I know) in the TLS space. Presumably many of them would get this change over time as it enters into Chromium and Android.

Cheers

AGL

[Peter Saint-Andre]

On 10/16/18 7:05 PM, Rick Byers wrote:
> Although we normally don't do "hopeful deprecations", this one seems
> special to me. There's clearly a coordinated industry movement here on
> good security grounds, with a long time period and necessary opt-outs.
>
> My intuition is that y'all know how to successfully drive shifts in the
> TLS ecosystem, effectively balancing compat constraints, and I'm
> unlikely to be able to add much value by questioning your judgement!
> But, if you'll bear with me a bit, I would find it really helpful for
> the blink deprecation process generally to dive in a little into what
> makes this case special. Maybe we can add it as a case study to our
> compat principles

> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit> to

> help explain when a "hopeful deprecation" with long removal timeframe is
> actually appropriate and likely to be setup for success (instead of the
> more common case of being just wishful thinking).
>
> Are you able to quantify the extent and severity of breakage beyond that
> scary 0.5% of connections number? Eg. do we have metrics that ignore all
> sub-resource (or have we done a crawl of the top N sites) to help
> estimate what fraction of page views would be totally broken? Do we know
> anything about the distribution of origins - eg. how that number would
> go down if the top ~100 impacted sites were fixed?

They have 14+ months to get their act together, and given existing
trends it won't even be 0.5% by then. We're just helping them along. :)

> Other than the
> co-ordinated industry movement, do you have any other reason to believe
> that the vast majority of impacted servers (including, I suppose, IoT
> devices) will actually get updated for this by the deadline?

How many people use browsers to connect to IoT devices? That's a
different sort of use case, and I think we can safely leave IoT worries
to someone else...

Peter

[Daniel Bratell]

On Wed, 17 Oct 2018 22:51:59 +0200, Adam Langley <a...@chromium.org> wrote:

On Tue, Oct 16, 2018 at 6:06 PM Rick Byers <rby...@chromium.org> wrote:

My intuition is that y'all know how to successfully drive shifts in the TLS ecosystem, effectively balancing compat constraints, and I'm unlikely to be able to add much value by questioning your judgement! But, if you'll bear with me a bit, I would find it really helpful for the blink deprecation process generally to dive in a little into what makes this case special. Maybe we can add it as a case study to our compat principles to help explain when a "hopeful deprecation" with long removal timeframe is actually appropriate and likely to be setup for success (instead of the more common case of being just wishful thinking).

We have been able to eliminate a number of old, unfortunate aspects of TLS over time: SSLv3, RC4, version fallbacks etc. I can only guess why things might be more tractable in TLS than for more normal web features:

TLS version support is a property of the web server, not of the web site. Thus there's fewer things that have to change. Also, the software on each web server is going to be one of not-that-many possible TLS implementations so it's generally a question of just updating it. That's in marked contrast to web features, which might be touched by bits of Javascript scattered across web pages where there's no automated way to clean them up.

We also operate on very long timescales. TLS 1.2 was released ten years ago. Based on a recent paper, it took five years for TLS 1.2 to start to catch on and it's been ramping up to nearly 100% ever since. On the server side things are even slower: we still support Windows XP there.

Are you able to quantify the extent and severity of breakage beyond that scary 0.5% of connections number? Eg. do we have metrics that ignore all sub-resource (or have we done a crawl of the top N sites) to help estimate what fraction of page views would be totally broken? Do we know anything about the distribution of origins - eg. how that number would go down if the top ~100 impacted sites were fixed?

We don't have more detailed analysis at the moment. When things get closer to the time, we'll start to look into that in case any specific devrel outreach can help us get closer to our goal.

Do you know why those 0.5% of connections use TLS 1.0 or TLS 1.1? Could there be any other reason than that the server doesn't support TLS 1.2? (i.e. things like browser configurations, forced downgrades to enable attacks, or something else)

If it's purely that the server doesn't support TLS 1.2, that would indicate servers that haven't had a proper upgrade in 5-10 years and then it's not obvious that they will be retired or updated in the next 12 months.

I understand the reasons behind this and I support it, but I'm less optimistic about avoiding breakage.

/Daniel

--

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

[Adam Langley]

On Thu, Oct 18, 2018 at 3:00 AM Daniel Bratell <bra...@opera.com> wrote:

Do you know why those 0.5% of connections use TLS 1.0 or TLS 1.1? Could there be any other reason than that the server doesn't support TLS 1.2?

It's possible that users have configured Chrome not to offer TLS 1.2, but it's much more likely that the server doesn't support TLS 1.2 as we don't do TLS version fallbacks any longer.

Cheers

AGL 

[Rick Byers]

On Wed, Oct 17, 2018 at 6:07 PM Peter Saint-Andre <stp...@mozilla.com> wrote:

On 10/16/18 7:05 PM, Rick Byers wrote:
> Although we normally don't do "hopeful deprecations", this one seems
> special to me. There's clearly a coordinated industry movement here on
> good security grounds, with a long time period and necessary opt-outs.
>
> My intuition is that y'all know how to successfully drive shifts in the
> TLS ecosystem, effectively balancing compat constraints, and I'm
> unlikely to be able to add much value by questioning your judgement!
> But, if you'll bear with me a bit, I would find it really helpful for
> the blink deprecation process generally to dive in a little into what
> makes this case special. Maybe we can add it as a case study to our
> compat principles
> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit> to
> help explain when a "hopeful deprecation" with long removal timeframe is
> actually appropriate and likely to be setup for success (instead of the
> more common case of being just wishful thinking).
>
> Are you able to quantify the extent and severity of breakage beyond that
> scary 0.5% of connections number? Eg. do we have metrics that ignore all
> sub-resource (or have we done a crawl of the top N sites) to help
> estimate what fraction of page views would be totally broken? Do we know
> anything about the distribution of origins - eg. how that number would
> go down if the top ~100 impacted sites were fixed?

They have 14+ months to get their act together, and given existing
trends it won't even be 0.5% by then. We're just helping them along. :)

Sure, I understand. I'm just trying to put this in context with APIs we've tried to deprecate but failed (so far) to remove - AppCache, WebSql, ShadowDOM v0, etc.

> Other than the
> co-ordinated industry movement, do you have any other reason to believe
> that the vast majority of impacted servers (including, I suppose, IoT
> devices) will actually get updated for this by the deadline?

How many people use browsers to connect to IoT devices? That's a
different sort of use case, and I think we can safely leave IoT worries
to someone else...

I don't think we can simply ignore this. If we get a significant number of users complaining that they can no longer control devices they own from Chrome and have to use another (not-yet-updated) browser to do so, then we're going to be forced to worry about it. But that's fine - our metrics and user feedback channels will tell us. Hopefully you're right and IoT isn't an issue. I was just thinking of David's talk about all the weird different sort of broken devices he's had to deal with compat issues in making TLS changes, so I'm sure that collectively weird devices we'd like to ignore are something he's generally worried about here :-)

 

Peter

[Rick Byers]

Thanks Adam, I think that's a good summary of the ways we've seen "hopeful deprecations" (with active co-ordinate industry pressure) work at the protocol layer, even though they tend to fail at the HTML/CSS/JS API layer. 

LGTM to deprecate

Cheers

AGL 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLwf%3D6vw3vvYXJ3aBW8q%2Bt6cPa6OYD1g_NJLAGNyGX7bDQ%40mail.gmail.com.

[Harald Alvestrand]

How many people use browsers to connect to IoT devices?

Everyone who owns an IoT device that needs configuring, basically. That's the only protocol most IoT devices speak.

(Exception: There's a bunch that use Bluetooth LE to connect to a configuration app on your phone. Some of those might speak HTTP as well; some might not.)

Not at all arguing against the deprecation (I think it's needed, and timely), but HTTP->IoT is indeed a thing.

--
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/2cfd37bb-1459-33b1-7f8f-fc4da038768c%40mozilla.com.

[Yoav Weiss]

Would be great to try to gather data regarding those servers during the deprecation period. Seems like Python 2.7.9 and older does not support TLS 1.2. Ideally, there shouldn't be many servers which expose Python to the web directly, but maybe that's not the case.

 

Peter

--

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/CAFUtAY8nXECdwEQqCrPjRN%2Bs4ib2sfuJ8ucN7w8oRm9YZ4BLDA%40mail.gmail.com.

[Yoav Weiss]

On Sun, Oct 28, 2018 at 4:12 PM Alex Gaynor <alex....@gmail.com> wrote:

Hi Yoav,

That's not completely right. Python <2.7.9 will use whatever versions of TLS OpenSSL defaults to, the issue (well, _an_ issue, Python<2.7.9's TLS has a few) is that you can't explicitly request TLS1.2. Note that official python.org binaries for Python<2.7.9 for Windows linked against a very old version of OpenSSL. Such Pythons are also unable to do SNI (as a client!), amongst many other issues (detailed here: https://developer.rackspace.com/blog/the-not-so-sorry-state-of-ssl-in-python/). In short, I seriously doubt Python <2.7.9 is a significant source of servers with poor TLS.

That's great to know. Thanks for correcting! :)

(Would still be great to gather more data on the source of usage)

 

Alex

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

--

All that is necessary for evil to succeed is for good people to do nothing.

[Alex Gaynor]

Hi Yoav,

That's not completely right. Python <2.7.9 will use whatever versions of TLS OpenSSL defaults to, the issue (well, _an_ issue, Python<2.7.9's TLS has a few) is that you can't explicitly request TLS1.2. Note that official python.org binaries for Python<2.7.9 for Windows linked against a very old version of OpenSSL. Such Pythons are also unable to do SNI (as a client!), amongst many other issues (detailed here: https://developer.rackspace.com/blog/the-not-so-sorry-state-of-ssl-in-python/). In short, I seriously doubt Python <2.7.9 is a significant source of servers with poor TLS.

Alex

On Sun, Oct 28, 2018 at 10:44 AM Yoav Weiss <yo...@yoav.ws> wrote:

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

[David Benjamin]

Google servers have long supported TLS 1.2, so there is probably some (very) outdated antivirus or proxy on your computer or network that has been configured to decrypt your encrypted browsing activity. You'll want to either disable that or get it updated.

If this doesn't ring a bell, we can try to help you identify the antivirus/proxy: file a bug at https://crbug.com/new and attach a NetLog per these instructions.

https://www.chromium.org/for-testers/providing-network-details

On Wed, Oct 27, 2021 at 4:54 AM Claire Miravalles <clairemir...@gmail.com> wrote:

Hi. I would like to know that all of my google services on browser in my pc has some problems regarding this. I can't open google forms, spreadsheets and even my drive has a warning signs of NET:ERR_SSL_OBSOLUTE_VERSION . How will it be fix? Can you help me?

[David Benjamin]

No, the TLS version negotiated should not be OS-dependent. Chrome does not use the OS's TLS stack. If you're seeing an issue that's specific to an older version, could you file a bug so we can take a look? Perhaps you have an antivirus or other local proxy that has been configured to terminate TLS (i.e. decrypt and inspect all your browsing activity), and that proxy uses the OS's TLS stack.

On Wed, Oct 27, 2021 at 11:49 AM Slade Watkins <sl...@sladewatkins.com> wrote:

Hi all,

The other possibility could be OS related. I've had this issue with Chromium on old versions macOS specifically, though I've seen it happen on Windows too.

Claire - what version of your operating system are you running?

Cheers,

             -slade

--
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/CAF8qwaBxUzPa4wqC20CO53JSFkAWj%2BkKYXtONLQL19Fq7Oxwwg%40mail.gmail.com.

[Claire Miravalles]

Hi. I would like to know that all of my google services on browser in my pc has some problems regarding this. I can't open google forms, spreadsheets and even my drive has a warning signs of NET:ERR_SSL_OBSOLUTE_VERSION . How will it be fix? Can you help me?

On Wednesday, October 17, 2018 at 5:15:10 AM UTC+8 David Benjamin wrote:

[Slade Watkins]

Hi all,

The other possibility could be OS related. I've had this issue with Chromium on old versions macOS specifically, though I've seen it happen on Windows too.

Claire - what version of your operating system are you running?

Cheers,

             -slade

On Wed, Oct 27, 2021 at 10:50 AM David Benjamin <davi...@chromium.org> wrote:

[Claire Miravalles]

Hi. Thank you for your reply. This error happened in the night of October 22nd. While I  was checking my google forms and gmail. I am using Avast as my antivirus software and my OS is windows 10.

I just checked my antivirus software and found out that one of their services has expired. I tried to uninstall the service (not Avast entirely) and the issue is not showing up anymore.

Thank you for your suggestions and help. This issue is now resolved.

[John Lohr]

I find it odd that Google is making the push to eliminate TLS 1.0 and 1.1, yet if you have a website created in Google Sites, there is no way (at least I couldn't find one) to disable TLS 1.0/1.1 protocols.