(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
