Google servers have long supported TLS 1.2, so there is probably some (very) outdated antivirus or proxy on your computer or network that has been configured to decrypt your encrypted browsing activity. You'll want to either disable that or get it updated.
If this doesn't ring a bell, we can try to help you identify the antivirus/proxy: file a bug at https://crbug.com/new and attach a NetLog per these instructions. https://www.chromium.org/for-testers/providing-network-details On Wed, Oct 27, 2021 at 4:54 AM Claire Miravalles < clairemiravalle...@gmail.com> wrote: > > 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 >> >> davi...@chromium.org >> >> awha...@chromium.org >> >> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBxUzPa4wqC20CO53JSFkAWj%2BkKYXtONLQL19Fq7Oxwwg%40mail.gmail.com.
