New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 583787 link

Starred by 18 users

Issue metadata

Status: Fixed
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Launch-OWP
Launch-Accessibility: ----
Launch-Exp-Leadership: ----
Launch-Leadership: ----
Launch-Legal: ----
Launch-M-Approved: ----
Launch-M-Target: ----
Launch-Privacy: ----
Launch-Security: ----
Launch-Test: ----
Launch-UI: ----
Rollout-Type: ----

Sign in to add a comment

Remove insecure TLS version fallback

Project Member Reported by, Feb 3 2016

Issue description

(See 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

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.

*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, Feb 24 2016

The following revision refers to this bug:

commit 3b26751ff0ac3ca5d1377616b55d0284673dc232
Author: davidben <>
Date: Wed Feb 24 19:46:55 2016

Disable the TLS version fallback.

This sets the default minimum TLS fallback version to TLS 1.2. The code is
retained for now to support a resurrected SSLVersionFallbackMin admin policy.
The policy is set to expire in Chrome 53, matching the timeline for the
previous fallback removal. As an escape hatch (but I don't expect to need it),
it's also connected to a field trial.

This also tweaks the fallback code. The TLS 1.0 fallback leg is now completely
gone (the admin policy expired) and ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION
hits have leveled off (see Net.ErrorCodesForMainFrame3), cap the fallback code
to TLS 1.1. We will no longer even try TLS 1.0 ClientHellos for the purposes of
showing the error code. This will decrease the amount of time it takes to show
an error page in some cases.

The ssl_version_fallback_min toggle is also tweaked to reject all values below
TLS 1.1, so that the resurrected admin policy cannot be used to set the value
at TLS 1.0 again. (Though it would be moot due to the above change.)

We'll also want to add a link to some to-be-written Help Center article on the
error page, but that'll be done separately after chatting with UI folks.

BUG= 536200 , 583787 

Review URL:

Cr-Commit-Position: refs/heads/master@{#377352}


Comment 2 by, Apr 27 2016

I believe this is causing In addition to the error there, I occasionally get an ERR_SSL_PROTOCAL_ERROR, which points me to, 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.
44.2 KB View Download
50.2 KB View Download
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.
Filed  issue #607052  to track the broken UI.
Oh, my bad. I must have mis read the thread where we discussed this. 

I'll work on a fix right away. 
+awhalley, how does the launch process work? Were we supposed to close this at some point?
Status: Fixed (was: Assigned)

Comment 8 Deleted

Sign in to add a comment