| Issue 583787 | Remove insecure TLS version fallback | ||||||||||||||||||||||||||||||||||||||||||||
| Starred by 16 users | Project Member Reported by davidben@chromium.org, Feb 3 2016 | Back to list | |||||||||||||||||||||||||||||||||||||||||||
Sign in to add a comment
|
(See http://www.chromium.org/blink#launch-process for an overview) See also issue #536200 for non-launch-tracking bug. Change description: TLS has a version negotiation mechanism to securely introduce new versions without breaking compatibility. Yet some buggy servers implement 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. Unlike TLS’s actual version negotiation, the fallback is insecure. Network attackers can downgrades to weaker versions, despite both client and server supporting newer, more secure 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 part as a trial run to removing the whole thing. We would like to finish the job and remove it completely. Note that this does NOT remove support for older versions of TLS. Although we urge servers 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. Changes to API surface: Servers which implement TLS correctly will be unaffected. Buggy servers which require the TLS version fallback will fail to load with ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION Links: Public standards discussion: N/A. This is non-standard legacy behavior that browsers had to implement in the past for compatibility with a small population of buggy servers. This population is believed to be all but gone now (largely because the bulk of it had to be ditched when POODLE was discovered). In the standards world, the TLSWG (rightfully) rather frowns upon this behavior. (It's unclear what OWP-Standards-* label to pick. I set OWP-Standards-No because the fallback is not standard, but that might send the wrong signal. I am removing a thing that lacks standards so that our behavior is closer to standards. And more secure, for that matter.) Support in other browsers: Internet Explorer: Firefox: Removed in Firefox 37. Safari: *Make sure to fill in any labels with a -?, including all OSes this change affects. Feel free to leave other labels at the defaults.
Project Member
Comment 1
by
bugdroid1@chromium.org,
Feb 24 2016
,
Apr 27 2016
I believe this is causing https://bugs.chromium.org/p/chromium/issues/detail?id=606629. In addition to the error there, I occasionally get an ERR_SSL_PROTOCAL_ERROR, which points me to https://developers.google.com/web/updates/2016/03/chrome-50-deprecations#remove-insecure-tls-version-fallback, which points me here. Screenshots attached. It's happening on every site, so it's not just buggy servers. I'm on an s3, CyanogenMod 13 (marshmallow). I cleared cache and rebooted. I'll be happy to do more tests if this isn't replicated on other devices.
,
Apr 27 2016
Ugh. It is very unlikely that, if you're just now starting to see ERR_SSL_PROTOCOL_ERROR on Android, this is related. That was a mistake in the UI +edwardjung, can you please fix this and merge to all branches? This is going to be extremely confusing for everyone. Only ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION should have had that URL. I'll follow-up with your error on the other bug.
,
Apr 27 2016
Filed issue #607052 to track the broken UI.
,
Apr 28 2016
Oh, my bad. I must have mis read the thread where we discussed this. I'll work on a fix right away.
,
Jun 9 2016
+awhalley, how does the launch process work? Were we supposed to close this at some point?
,
Jun 10 2016
|
||||||||||||||||||||||||||||||||||||||||||||
| ► Sign in to add a comment | |||||||||||||||||||||||||||||||||||||||||||||
