I am repeatedly encountering connection problems. so what you recommend me to fix it?
On Saturday, May 9, 2020 at 12:02:25 AM UTC+1 [email protected] wrote: > > > On Wednesday, February 3, 2016 at 4:42:59 PM UTC-5, David Benjamin wrote: >> >> *Primary eng (and PM) emails* >> [email protected], [email protected] >> >> *Summary* >> TLS has a version negotiation mechanism to securely introduce new >> versions without breaking compatibility. Yet some buggy servers (usually >> called “version-intolerant”) implemented this wrong, so browsers were >> forced to add insecure fallbacks to work around this. On failed >> connections, we retry, advertising lower and lower maximum versions. >> >> The SSL 3.0 fallback leg was removed last year due to POODLE (followed by >> removing SSL 3.0 entirely). Then in Chrome 45, we removed another leg >> <https://groups.google.com/a/chromium.org/d/msg/security-dev/F6ZjP6FnyRE/bK7TKtvnHYsJ> >> as >> a trial run to removing the whole thing. We would like to finish the job >> and remove it completely. >> >> *This does not remove support for TLS 1.0 or TLS 1.1.* Although servers >> are urged to upgrade to TLS 1.2 (all ciphers in prior versions have known >> problems), Chrome will continue to support TLS 1.0 and TLS 1.1 at this >> time. Only buggy servers which do not correctly implement TLS will be >> affected. >> >> *Motivation* >> The fallback bypasses TLS's downgrade protection. Attackers can force *all >> sites* (not just the buggy ones) to negotiate weaker versions, despite >> both client and server supporting newer, more secure protocol versions. >> This causes problems when attacks are found against old protocol versions, >> such as POODLE. FALLBACK_SCSV (RFC 7507 >> <https://tools.ietf.org/html/rfc7507>) fixes this, but it requires both >> client and server support. >> >> TLS fallbacks also mask implementation bugs. We’ve seen many examples of >> vendors shipping new server software with bugs that could have been noticed >> were it not for the fallback. >> >> *Compatibility risk* >> Any remaining 1.2-intolerant sites will break. After Chrome 45 removed >> all but the TLS 1.1 fallback, these must be 1.2-intolerant but not >> 1.1-intolerant. We are not aware of any such servers. (One would hope these >> bugs have been resolved as this is the third version bump since SSL >> 3.0.) Mozilla has already removed the fallback as of Firefox 37 >> <https://www.mozilla.org/en-US/firefox/37.0/releasenotes/>, so any >> 1.2-intolerant sites would not load in Firefox. >> >> There is an additional risk that some unrelated server bug was masked by >> the fallback and doesn’t manifest in other browsers. Notably, we are aware >> of an issue <https://crbug.com/433406> affecting Chrome connections to a >> small fraction of Windows-based servers, though it appears much less >> prevalent than previously believed. (Metrics below.) >> >> *Alternative implementation suggestion for administrators* >> Affected sites will fail to load with a dedicated network error code, >> ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. (This page already exists from >> previous iterations of this.) We’ll link the error page to a Help Center >> article with appropriate instructions for administrators: >> >> Server administrators should ensure their software is up-to-date and, if >> still unresolved, reach out to their software vendor. Affected software >> vendors should fix bugs in their server implementations and follow the >> protocol specification. The Windows issue above was addressed in >> KB3042058 <https://support.microsoft.com/en-us/kb/3042058>. Note that >> KB3042058 describes important prerequisites that must be installed prior to >> installing KB3042058. >> >> For enterprise administrators, where our metrics are underrepresented, >> the SSLVersionFallbackMin administrative policy will be temporarily >> available to give more time to fix servers. >> >> *Usage information from UMA* >> Net.ConnectionUsedSSLVersionFallback2 measures HTTPS requests which >> required the fallback. Over the past week, 0.0017% of HTTPS requests >> required the fallback. >> >> A few releases ago, in Chrome 46, the number was 0.015%. The difference >> was previously believed to be the Windows bug, but it seems to have been a >> different issue which is no longer a concern. (We experimentally worked >> around the bug, and numbers went down. Then we deprecated DHE >> <https://groups.google.com/a/chromium.org/d/msg/security-dev/dYyhKHPnrI0/pNxx8vTKBAAJ> >> for >> unrelated reasons, and then removed the experiment, but numbers stayed >> down. We've since observed a DHE-specific issue, also affected by the >> workaround, which we believe was the source.) >> >> *OWP launch tracking bug* >> https://crbug.com/583787 >> >> *Entry on the feature dashboard* >> https://www.chromestatus.com/feature/5685183936200704 >> >> *Requesting approval to remove too?* >> Yes. >> >> As an extra precaution, the removal will be gated on field trial, so if >> anything unexpected occurs, we can easily roll back. We’ll also continue to >> monitor metrics leading up to Chrome 50 reaching stable. >> > -- 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/e5abad05-f1c9-473b-baca-c05a23c9a008n%40chromium.org.
