I find it odd that Google is making the push to eliminate TLS 1.0 and 1.1, 
yet if you have a website created in Google Sites, there is no way (at 
least I couldn't find one) to disable TLS 1.0/1.1 protocols.

On Wednesday, October 27, 2021 at 8:52:06 PM UTC-4 [email protected] 
wrote:

> Hi. Thank you for your reply. This error happened in the night of October 
> 22nd. While I  was checking my google forms and gmail. I am using Avast as 
> my antivirus software and my OS is windows 10.
>
> I just checked my antivirus software and found out that one of their 
> services has expired. I tried to uninstall the service (not Avast entirely) 
> and the issue is not showing up anymore.
>
> Thank you for your suggestions and help. This issue is now resolved.
>
> On Wed, 27 Oct 2021, 11:53 pm David Benjamin, <[email protected]> 
> wrote:
>
>> No, the TLS version negotiated should not be OS-dependent. Chrome does 
>> not use the OS's TLS stack. If you're seeing an issue that's specific to an 
>> older version, could you file a bug so we can take a look? Perhaps you have 
>> an antivirus or other local proxy that has been configured to terminate TLS 
>> (i.e. decrypt and inspect all your browsing activity), and that proxy uses 
>> the OS's TLS stack.
>>
>> On Wed, Oct 27, 2021 at 11:49 AM Slade Watkins <[email protected]> 
>> wrote:
>>
>>> 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/b2dce97c-ba88-49f3-9576-1e7f3bfbd79an%40chromium.org.

Reply via email to