Re: Intent to unship: TLS 1.0 and TLS 1.1

[yuhongbao_386]

> [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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: TLS 1.0 and TLS 1.1

[Graham Perrin]

On 05/12/2019 22:34, Martin Thomson wrote:
On Fri, Dec 6, 2019 at 5:08 AM > 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.

Re: the screenshot at


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 
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 
?


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: TLS 1.0 and TLS 1.1

[Martin Thomson]

On Fri, Dec 6, 2019 at 5:08 AM  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.


> 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 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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: TLS 1.0 and TLS 1.1

[grahamperrin]

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 

 I do like how things are shaping up in Firefox 71.0 with 
security.tls.version.min set (or preset) to 3.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: TLS 1.0 and TLS 1.1

[Martin Thomson]

On Sun, Oct 6, 2019 at 6:35 PM  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
(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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: TLS 1.0 and TLS 1.1

[rpedrica]

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:
> >
> > 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.

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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: TLS 1.0 and TLS 1.1

[Henri Sivonen]

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
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: TLS 1.0 and TLS 1.1

[Martin Thomson]

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.
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?
>

Pretty low in any reasonable time frame.  The use of new NSS releases in
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: TLS 1.0 and TLS 1.1

[Henri Sivonen]

On Thu, Sep 12, 2019 at 7:03 AM Martin Thomson  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?

> 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.

What expectations are there for being able to remove the code from NSS?

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: TLS 1.0 and TLS 1.1

[Martin Thomson]

(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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform