Subject: [saag] fyi: [blink-dev] Intent to Deprecate: TLS 1.0 and TLS 1.1

From: =JeffH <[email-masked]>
Date: Thu, 18 Oct 2018 10:23:35 -0700

Subject: [blink-dev] Intent to Deprecate: TLS 1.0 and TLS 1.1
From: David Benjamin <[email-masked]>
To: blink-dev <[email-masked]>, net-dev <[email-masked]>, security-dev <[email-masked]>
Date: Tue, 16 Oct 2018 16:14:53 -0500
List-Id: <blink-dev.chromium.org>

(This was announced as a blog post
<https://security.googleblog.com/2018/10/modernizing-transport-security.html>
yesterday.)

Primary eng (and PM) emails

[email-masked]

[email-masked]

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
<https://tools.ietf.org/html/rfc5246>, 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 <https://www.mitls.org/pages/attacks/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
   <https://www.mitls.org/pages/attacks/SLOTH> attack.)
   -

   TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken
   <http://www.isg.rhul.ac.uk/tls/> and has since been removed. TLS’s CBC
   mode construction is flawed and was vulnerable to a series of attacks, most
   recently Lucky13 <http://www.isg.rhul.ac.uk/tls/Lucky13.html>. TLS 1.2
   introduces AEAD
<https://en.wikipedia.org/wiki/Authenticated_encryption>-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
   <https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack>
   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
<https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls>
and the TLS working group has adopted a document
<https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-00> 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
<https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/>

Firefox: Supported, positive to removal
<https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/>

Safari: Supported, positive to removal
<https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/>

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 <https://tools.ietf.org/html/rfc8446>.
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
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>

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

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.

-- 
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 [email-masked].
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.