Hi. I would like to know that all of my google services on browser in my pc has some problems regarding this. I can't open google forms, spreadsheets and even my drive has a warning signs of NET:ERR_SSL_OBSOLUTE_VERSION . How will it be fix? Can you help me? On Wednesday, October 17, 2018 at 5:15:10 AM UTC+8 David Benjamin wrote:
> (This was announced as a blog post > <https://security.googleblog.com/2018/10/modernizing-transport-security.html> > yesterday.) > > Primary eng (and PM) emails > > [email protected] > > [email protected] > > 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 protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5116c9ed-6272-46db-add4-593367b79bddn%40chromium.org.
