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