Hi all,
The other possibility could be OS related. I've had this issue with
Chromium on old versions macOS specifically, though I've seen it happen on
Windows too.
Claire - what version of your operating system are you running?
Cheers,
-slade
On Wed, Oct 27, 2021 at 10:50 AM David Benjamin <[email protected]>
wrote:
> 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 <
> [email protected]> 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
>>>
>>> [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/CAF8qwaBxUzPa4wqC20CO53JSFkAWj%2BkKYXtONLQL19Fq7Oxwwg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBxUzPa4wqC20CO53JSFkAWj%2BkKYXtONLQL19Fq7Oxwwg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CA%2Bpv%3DHOz25Ei-zXr4HrW53LiQbqcWw5xO9nrD-x-Dw-%2Bj4p4oA%40mail.gmail.com.
