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, <david...@chromium.org> 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 <sl...@sladewatkins.com> > 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 <david...@chromium.org> >> 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 < >>> 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 >>> <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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAdhTpXuZMdAq3ezCHoZQDgFjLvouRWtz2zgFYjc3JoQj5BPyA%40mail.gmail.com.
