info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Intent to unship: TLS 1.0 and TLS 1.1
1,260 views
Skip to first unread message
Martin Thomson
Sep 12, 2019, 12:03:57 AM9/12/19
to dev-platform
(We’ve had a couple of blog postings about this [1][2], but this list
hasn’t received an explicit intent notice. Now that we’re starting to make
changes, it seems like a good time to correct that oversight.)
TLS 1.0 and 1.1 are old. They are also broken in myriad subtle ways. [3]
explains in more detail.
Disabling TLS 1.0 and 1.1 is part of an agreement we have negotiated with
other browsers. We have agreed with Apple, Google, and Microsoft to
disable this version in March 2020. Safari Tech Preview has already made
this change [4].
We have been measuring the impact of this change at [5], which shows steady
progress from sites. Telemetry shows that TLS 1.0 usage is much higher
than we would ordinarily tolerate for this sort of deprecation [6], but we
are confident in the commitment that other browsers have made. The trend in
both measurements supports the view that the number of sites that will be
affected is reducing steadily [7].
The first step on this path landed in Firefox 68. That was to show a
warning in developer tools.
The step we’re about to take disables TLS 1.0 and 1.1 in Nightly. The plan
is to do that in the Firefox 71 cycle. Bug 1579270 tracks this change.
After that we plan to start progressively disabling TLS 1.0 and 1.1 in Beta
as that Firefox 71 and subsequent versions are deployed. This will likely
start by making the change for a very small percentage of people using
Beta, then increasing as we gather feedback. The idea is to have all of
Beta switched over ahead of March.
Finally, we will disable TLS 1.0 and 1.1 for all people using the Release
channel of Firefox in March 2020. Exact plans for how and when this will
happen are not yet settled.
Bug 1579285 is tracking updates to the SSL_ERROR_UNSUPPORTED_VERSION error
page that we expect will get more use. That page currently offers to reset
preferences. We are considering offer the option to re-enable old TLS
versions. However, we would remove that capability in a build that will go
to Release in or shortly after March.
Independent of this, WebRTC uses DTLS, which has a similar story. DTLS 1.0
is effectively TLS 1.1. However, WebRTC has higher DTLS 1.0 usage rates
[8]. The WebRTC team are considering disabling support for DTLS 1.0 at the
same time, but might defer that decision.
This is a potentially disruptive change, but we believe that this is good
for the security and stability of the web.
---
[1]
https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/
[2] https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
[3] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-05
[4]
https://webkit.org/blog/9526/release-notes-for-safari-technology-preview-91/
[5] The second graph at
http://tlscanary-plot-8e95d89854d73f4d.elb.us-west-2.amazonaws.com/ ;
ignore the jump prior to May, that’s the result of a methodology change to
switch the list of sites that are scanned.
[6] https://sql.telemetry.mozilla.org/queries/64283#164115 shows values for
Release, which puts TLS 1.0 between 0.46% and 0.68% depending on the time
of week. TLS 1.1 is virtually non-existent at 0.02%, we could have removed
that already if it weren’t for the fact that this isn’t how TLS version
negotiation works.
[7] ibid. In October last year, TLS 1.0 was in the range of 0.65% to 1%.
[8] https://mzl.la/2ZIHK55
hasn’t received an explicit intent notice. Now that we’re starting to make
changes, it seems like a good time to correct that oversight.)
TLS 1.0 and 1.1 are old. They are also broken in myriad subtle ways. [3]
explains in more detail.
Disabling TLS 1.0 and 1.1 is part of an agreement we have negotiated with
other browsers. We have agreed with Apple, Google, and Microsoft to
disable this version in March 2020. Safari Tech Preview has already made
this change [4].
We have been measuring the impact of this change at [5], which shows steady
progress from sites. Telemetry shows that TLS 1.0 usage is much higher
than we would ordinarily tolerate for this sort of deprecation [6], but we
are confident in the commitment that other browsers have made. The trend in
both measurements supports the view that the number of sites that will be
affected is reducing steadily [7].
The first step on this path landed in Firefox 68. That was to show a
warning in developer tools.
The step we’re about to take disables TLS 1.0 and 1.1 in Nightly. The plan
is to do that in the Firefox 71 cycle. Bug 1579270 tracks this change.
After that we plan to start progressively disabling TLS 1.0 and 1.1 in Beta
as that Firefox 71 and subsequent versions are deployed. This will likely
start by making the change for a very small percentage of people using
Beta, then increasing as we gather feedback. The idea is to have all of
Beta switched over ahead of March.
Finally, we will disable TLS 1.0 and 1.1 for all people using the Release
channel of Firefox in March 2020. Exact plans for how and when this will
happen are not yet settled.
Bug 1579285 is tracking updates to the SSL_ERROR_UNSUPPORTED_VERSION error
page that we expect will get more use. That page currently offers to reset
preferences. We are considering offer the option to re-enable old TLS
versions. However, we would remove that capability in a build that will go
to Release in or shortly after March.
Independent of this, WebRTC uses DTLS, which has a similar story. DTLS 1.0
is effectively TLS 1.1. However, WebRTC has higher DTLS 1.0 usage rates
[8]. The WebRTC team are considering disabling support for DTLS 1.0 at the
same time, but might defer that decision.
This is a potentially disruptive change, but we believe that this is good
for the security and stability of the web.
---
[1]
https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/
[2] https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
[3] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-05
[4]
https://webkit.org/blog/9526/release-notes-for-safari-technology-preview-91/
[5] The second graph at
http://tlscanary-plot-8e95d89854d73f4d.elb.us-west-2.amazonaws.com/ ;
ignore the jump prior to May, that’s the result of a methodology change to
switch the list of sites that are scanned.
[6] https://sql.telemetry.mozilla.org/queries/64283#164115 shows values for
Release, which puts TLS 1.0 between 0.46% and 0.68% depending on the time
of week. TLS 1.1 is virtually non-existent at 0.02%, we could have removed
that already if it weren’t for the fact that this isn’t how TLS version
negotiation works.
[7] ibid. In October last year, TLS 1.0 was in the range of 0.65% to 1%.
[8] https://mzl.la/2ZIHK55
Henri Sivonen
Sep 12, 2019, 3:50:20 AM9/12/19
to dev-platform
On Thu, Sep 12, 2019 at 7:03 AM Martin Thomson <m...@mozilla.com> wrote:
> Telemetry shows that TLS 1.0 usage is much higher
> than we would ordinarily tolerate for this sort of deprecation
Do we know what the situation looks like for connections to RFC 1918 addresses?
> Telemetry shows that TLS 1.0 usage is much higher
> than we would ordinarily tolerate for this sort of deprecation
> Finally, we will disable TLS 1.0 and 1.1 for all people using the Release
> channel of Firefox in March 2020. Exact plans for how and when this will
> happen are not yet settled.
--
Henri Sivonen
hsiv...@mozilla.com
Martin Thomson
Sep 12, 2019, 8:09:37 PM9/12/19
to Henri Sivonen, dev-platform
On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen <hsiv...@mozilla.com> wrote:
> Do we know what the situation looks like for connections to RFC 1918
> addresses?
>
That's a hard one to even speculate about, and that's all we really have
> Do we know what the situation looks like for connections to RFC 1918
> addresses?
>
there. Our telemetry doesn't really allow us to gain insight into that.
The big question being enterprise uses, where there is some chance of
having names on servers in private address space. Most use of 1918 outside
of enterprise is likely still unsecured entirely.
> What expectations are there for being able to remove the code from NSS?
>
old versions of RHEL and their very long support cycles means that Red Hat
are reluctant to have code removed. We still have SSLv3 code hanging
around and will likely have that for a few more years.
That said, there is a lot of shared code between SSLv3, TLS 1.0, TLS 1.1,
and TLS 1.2. There isn't a whole lot to gain from trying to take any one
of those versions out of the code, because there isn't that much to remove.
Henri Sivonen
Sep 13, 2019, 6:36:56 AM9/13/19
to Martin Thomson, dev-platform
On Fri, Sep 13, 2019 at 3:09 AM Martin Thomson <m...@mozilla.com> wrote:
>
> On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen <hsiv...@mozilla.com> wrote:
>>
>> Do we know what the situation looks like for connections to RFC 1918 addresses?
>
> That's a hard one to even speculate about, and that's all we really have there. Our telemetry doesn't really allow us to gain insight into that.
I see.
>
> On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen <hsiv...@mozilla.com> wrote:
>>
>> Do we know what the situation looks like for connections to RFC 1918 addresses?
>
> That's a hard one to even speculate about, and that's all we really have there. Our telemetry doesn't really allow us to gain insight into that.
> The big question being enterprise uses, where there is some chance of having names on servers in private address space. Most use of 1918 outside of enterprise is likely still unsecured entirely.
unsecured in the sense of using self-signed certificates but that
still use TLS, so that TLS matters for practical compatibility. I
don't know of real examples of devices that both use TLS exclusively
and don't support TLS 1.2. (My printer redirects http to https with
self-signed cert but supports TLS 1.2.)
--
Henri Sivonen
hsiv...@mozilla.com
rped...@gmail.com
Oct 6, 2019, 3:31:16 AM10/6/19
to
On Friday, 13 September 2019 12:36:56 UTC+2, Henri Sivonen wrote:
> On Fri, Sep 13, 2019 at 3:09 AM Martin Thomson wrote:
Granted some of these may be edge cases, but it would be nice to have some exclusion system or exclusions for rfc1918 spaces for cases like self-signed certs and similar issues, even if it's an advanced Preferences selection and not on the error page itself.
> On Fri, Sep 13, 2019 at 3:09 AM Martin Thomson wrote:
> >
> > On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen wrote:
> >>
> >> Do we know what the situation looks like for connections to RFC 1918 addresses?
> >
> > That's a hard one to even speculate about, and that's all we really have there. Our telemetry doesn't really allow us to gain insight into that.
>
> I see.
>
> > The big question being enterprise uses, where there is some chance of having names on servers in private address space. Most use of 1918 outside of enterprise is likely still unsecured entirely.
>
> I was thinking of home printer, NAS and router config UIs that are
> unsecured in the sense of using self-signed certificates but that
> still use TLS, so that TLS matters for practical compatibility. I
> don't know of real examples of devices that both use TLS exclusively
> and don't support TLS 1.2. (My printer redirects http to https with
> self-signed cert but supports TLS 1.2.)
>
> --
> Henri Sivonen
>
I would agree that these changes and changes that have already occurred over the last year or so, have broken access to admin consoles of older networking kit. I had to pull a WinXP machine out of storage recently to manage an HP 2610 switch.
> > On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen wrote:
> >>
> >> Do we know what the situation looks like for connections to RFC 1918 addresses?
> >
> > That's a hard one to even speculate about, and that's all we really have there. Our telemetry doesn't really allow us to gain insight into that.
>
> I see.
>
> > The big question being enterprise uses, where there is some chance of having names on servers in private address space. Most use of 1918 outside of enterprise is likely still unsecured entirely.
>
> I was thinking of home printer, NAS and router config UIs that are
> unsecured in the sense of using self-signed certificates but that
> still use TLS, so that TLS matters for practical compatibility. I
> don't know of real examples of devices that both use TLS exclusively
> and don't support TLS 1.2. (My printer redirects http to https with
> self-signed cert but supports TLS 1.2.)
>
> --
> Henri Sivonen
>
Granted some of these may be edge cases, but it would be nice to have some exclusion system or exclusions for rfc1918 spaces for cases like self-signed certs and similar issues, even if it's an advanced Preferences selection and not on the error page itself.
Martin Thomson
Oct 10, 2019, 12:32:33 AM10/10/19
to rped...@gmail.com, dev-platform
On Sun, Oct 6, 2019 at 6:35 PM <rped...@gmail.com> wrote:
> I would agree that these changes and changes that have already occurred
> over the last year or so, have broken access to admin consoles of older
> networking kit. I had to pull a WinXP machine out of storage recently to
> manage an HP 2610 switch.
>
For the foreseeable future, we will retain the pref
> I would agree that these changes and changes that have already occurred
> over the last year or so, have broken access to admin consoles of older
> networking kit. I had to pull a WinXP machine out of storage recently to
> manage an HP 2610 switch.
>
(security.tls.version.min, accessible through about:config) that will allow
individual overrides for this default configuration. I expect that we will
eventually remove this capability and you will have to go searching for
insecure software so that you can do insecure things. I appreciate the
pain this causes, but the fact is that the Internet is a sufficiently
hostile environment that all devices connected to it really do need an
up-to-date version of important software, especially networking software.
Ultimately, there isn't a good distinction between devices that are on the
(big "I") Internet and devices that are on (private) networks. For
instance, we don't want to have airport or coffee shop WiFi being able to
access the sorts of exceptions we create for your home network.
If this is sufficiently widespread, we might look into what it would take
to build in some way to override on a per-host basis or carve out
exceptions for private numbering spaces, but we need to be very careful
about opening avenues for attack.
graham...@gmail.com
Dec 5, 2019, 12:19:19 PM12/5/19
to
On Thursday, 12 September 2019 05:03:57 UTC+1, Martin Thomson wrote:
…
> [2] https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
…
From the linked post:
>> … Safari, Firefox, Edge and Chrome are removing support for TLS 1.0 and 1.1 in March of 2020. …
Is that (timeline) still a _shared_ intent – for all four browsers?
Re: the screenshot at <https://user-images.githubusercontent.com/192271/70135931-e7e00800-1682-11ea-84f7-de2c397fa5eb.png> I do like how things are shaping up in Firefox 71.0 with security.tls.version.min set (or preset) to 3.
…
> [2] https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
…
From the linked post:
>> … Safari, Firefox, Edge and Chrome are removing support for TLS 1.0 and 1.1 in March of 2020. …
Is that (timeline) still a _shared_ intent – for all four browsers?
Re: the screenshot at <https://user-images.githubusercontent.com/192271/70135931-e7e00800-1682-11ea-84f7-de2c397fa5eb.png> I do like how things are shaping up in Firefox 71.0 with security.tls.version.min set (or preset) to 3.
Graham Perrin
Dec 6, 2019, 10:12:52 AM12/6/19
to Martin Thomson, dev-platform
On 05/12/2019 22:34, Martin Thomson wrote:
> next year or for the exceptions to be more narrowly targeted.
> Re-enabling TLS 1.0 will still be possible via about:config for some
> time after that, so people with a real need can always turn it back on
> if they need to (including through enterprise policy if corporate
> services are stuck). That's still inadvisable; ultimately, we'd like
> to ensure that TLS 1.2 or higher is always used.
Thanks.
Incidentally, why do I not see Martin's response (above) under
<https://groups.google.com/d/msg/mozilla.dev.platform/8EFRYDR3N1c/dFbOCAqaBAAJ>?
> On Fri, Dec 6, 2019 at 5:08 AM <graham...@gmail.com
> <mailto:graham...@gmail.com>> wrote:
>
> >> … Safari, Firefox, Edge and Chrome are removing support for TLS
> 1.0 and 1.1 in March of 2020. …
>
> Is that (timeline) still a _shared_ intent – for all four browsers?
>
>
> I recently confirmed this, yes.
> <mailto:graham...@gmail.com>> wrote:
>
> >> … Safari, Firefox, Edge and Chrome are removing support for TLS
> 1.0 and 1.1 in March of 2020. …
>
> Is that (timeline) still a _shared_ intent – for all four browsers?
>
>
>
> Re: the screenshot at
> <https://user-images.githubusercontent.com/192271/70135931-e7e00800-1682-11ea-84f7-de2c397fa5eb.png>
> I do like how things are shaping up in Firefox 71.0 with
> security.tls.version.min set (or preset) to 3.
>
>
> The intent is to have that dialog to disappear some time after March
> Re: the screenshot at
> <https://user-images.githubusercontent.com/192271/70135931-e7e00800-1682-11ea-84f7-de2c397fa5eb.png>
> I do like how things are shaping up in Firefox 71.0 with
> security.tls.version.min set (or preset) to 3.
>
>
> next year or for the exceptions to be more narrowly targeted.
> Re-enabling TLS 1.0 will still be possible via about:config for some
> time after that, so people with a real need can always turn it back on
> if they need to (including through enterprise policy if corporate
> services are stuck). That's still inadvisable; ultimately, we'd like
> to ensure that TLS 1.2 or higher is always used.
Thanks.
Incidentally, why do I not see Martin's response (above) under
<https://groups.google.com/d/msg/mozilla.dev.platform/8EFRYDR3N1c/dFbOCAqaBAAJ>?
Martin Thomson
Dec 6, 2019, 10:12:52 AM12/6/19
to graham...@gmail.com, dev-platform
On Fri, Dec 6, 2019 at 5:08 AM <graham...@gmail.com> wrote:
> >> … Safari, Firefox, Edge and Chrome are removing support for TLS 1.0 and
> 1.1 in March of 2020. …
>
> Is that (timeline) still a _shared_ intent – for all four browsers?
>
> >> … Safari, Firefox, Edge and Chrome are removing support for TLS 1.0 and
> 1.1 in March of 2020. …
>
> Is that (timeline) still a _shared_ intent – for all four browsers?
>
I recently confirmed this, yes.
> Re: the screenshot at <
> https://user-images.githubusercontent.com/192271/70135931-e7e00800-1682-11ea-84f7-de2c397fa5eb.png>
> I do like how things are shaping up in Firefox 71.0 with
> security.tls.version.min set (or preset) to 3.
>
> https://user-images.githubusercontent.com/192271/70135931-e7e00800-1682-11ea-84f7-de2c397fa5eb.png>
> I do like how things are shaping up in Firefox 71.0 with
> security.tls.version.min set (or preset) to 3.
>
yuhong...@hotmail.com
Jun 25, 2020, 10:09:50 PM6/25/20
to
> [6] https://sql.telemetry.mozilla.org/queries/64283#164115 shows values for
> Release, which puts TLS 1.0 between 0.46% and 0.68% depending on the time
> of week. TLS 1.1 is virtually non-existent at 0.02%, we could have removed
> that already if it weren’t for the fact that this isn’t how TLS version
> negotiation works.
I just notice that this threshold seems to be low.
> Release, which puts TLS 1.0 between 0.46% and 0.68% depending on the time
> of week. TLS 1.1 is virtually non-existent at 0.02%, we could have removed
> that already if it weren’t for the fact that this isn’t how TLS version
> negotiation works.
0 new messages