clearer messages on cipher mismatch or antiquated SSL/TLS versions

3,945 views
Skip to first unread message

Corvin Russell

unread,
Jun 8, 2015, 11:49:16 AM6/8/15
to securi...@chromium.org
Hi Chrome devs, 

I notice that as of 44+ Chrome is defaulting to a minimum TLS version of 1.1. When visiting a website whose maximum version <1.1, the following message is displayed:

This webpage is not available
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Hide details
A secure connection cannot be established because this site uses an unsupported protocol.

This message is only informative to technically inclined users. Most users will problem-solve by trying an alternative browser (possibly at the direction of the deficient website), rather than knowing to navigate to chrome://flags. 

I suggest (1) that the error message be disambiguated to indicate whether it is a TLS version or cipher mismatch problem, or both; and (2) that the language be made more user friendly to explain what is wrong with these. Otherwise users are liable to interpret it as a Chrome problem, not a website problem, and they are likely to experience that some other browser "just works". 

By way of example, one service that supports only TLS 1.0 is EZproxy, which is an authentication gateway for premium online resources (journals, reference works, etc.) used by almost all university and municipal libraries in North America. I wrote to sup...@oclc.org, the entity responsible for EZproxy, and got the message below. Obviously, they feel no sense of hurry. Clearer error messages may have the added salutary effect of encouraging such companies to move faster on upgrading their services to current standards. 

Thank you for contacting OCLC Customer Support.

The development team for EZproxy stated TLS 1.1 & 1.2 will not be supported by EZProxy until version 6.1. They have not released the date for the release of version 6.1.

Please let me know if there is anything more I can help you with regarding this issue.


--
Twitter: @corvinr
My PGP key is here

Help restore privacy and freedom of association for everyone by using Signal on iPhone and TextSecure and RedPhone on Android.

Chris Bentzel

unread,
Jun 8, 2015, 12:00:26 PM6/8/15
to Corvin Russell, securi...@chromium.org, net...@chromium.org, rach...@google.com

David Benjamin

unread,
Jun 8, 2015, 12:01:59 PM6/8/15
to Chris Bentzel, Corvin Russell, securi...@chromium.org, net...@chromium.org, rach...@google.com
We didn't default to a minimum version of TLS 1.1. Are you sure you don't have something set in about:flags?

This is the second report we've had of this though... ugh, I bet the first change in https://crbug.com/487730 messed up any install which had previously set TLS 1.0 manually. I'll go verify this and, if so, merge the follow-up removal of the about:flags entry altogether to 44.

Corvin Russell

unread,
Jun 8, 2015, 12:05:12 PM6/8/15
to David Benjamin, Chris Bentzel, securi...@chromium.org, net...@chromium.org, rach...@google.com
I had previously set 1.0 manually, so that may be the case. It is definitely a change since the bump to 44 that did not result from any intermediate action on my part.

David Benjamin

unread,
Jun 8, 2015, 12:45:41 PM6/8/15
to Corvin Russell, Chris Bentzel, securi...@chromium.org, net...@chromium.org, rach...@google.com
And verified that this failure mode happens. Sorry about that! I've filed https://crbug.com/497802 to get this sorted out by the next beta release.

Incidentally, I'm fairly sure we added the entry to about:flags *after* we default TLS 1.0 to the minimum, so I'm not sure there was ever any point to changing that setting. :-)

Corvin Russell

unread,
Jun 8, 2015, 12:49:37 PM6/8/15
to David Benjamin, Chris Bentzel, securi...@chromium.org, net...@chromium.org, rach...@google.com
There was a point to manually changing it to TLS 1.0, if one had previously broken the internet by changing it to TLS 1.2. :-)


David Benjamin

unread,
Jun 8, 2015, 12:54:38 PM6/8/15
to Corvin Russell, Chris Bentzel, securi...@chromium.org, net...@chromium.org, rach...@google.com
Fair enough. :-)

(You should probably set it to "Default" now rather than explicitly "TLS 1.0".)

Rachel Ilan Simpson

unread,
Jun 11, 2015, 2:33:39 PM6/11/15
to David Benjamin, Corvin Russell, Chris Bentzel, securi...@chromium.org, net...@chromium.org
Thanks for looping me in Chris.

This webpage is not available
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Hide details
A secure connection cannot be established because this site uses an unsupported protocol. 
 
This message is only informative to technically inclined users. Most users will problem-solve by trying an alternative browser (possibly at the direction of the deficient website), rather than knowing to navigate to chrome://flags. 

Yes, I agree with this.

I suggest (1) that the error message be disambiguated to indicate whether it is a TLS version or cipher mismatch problem, or both; and

How important is this from a user perspective? What does it change in terms of user action? 

(2) that the language be made more user friendly to explain what is wrong with these. Otherwise users are liable to interpret it as a Chrome problem, not a website problem, and they are likely to experience that some other browser "just works". 

Yes, agreed, that's very important. Can you clarify for me a bit more what we think users should understand here? And what actions we want them to take?

Cheers!
Rachel

David Benjamin

unread,
Jun 11, 2015, 2:53:25 PM6/11/15
to Rachel Ilan Simpson, Corvin Russell, Chris Bentzel, securi...@chromium.org, net...@chromium.org
Further down the thread, it turned out this was simply a bug combined with the user flipping an unsupported flag in about:flags. I think we can set it aside as far as user actions and error messages go. If we were ever to actually disable TLS 1.0 (as this report assumed), we would consider metrics and whether users would actually see it.

We could now, if we wanted, distinguish between the server returning a version beyond our minimum from the other cases. We don't currently do this, and it may be worth doing so if we ever need to raise the minimum again. This wasn't possible before because NSS used to map the two to the same error code and it wasn't much of a concern.

The user action is the same for both cases, however: the site is broken. Contact whoever runs the site.

Rachel Ilan Simpson

unread,
Jun 12, 2015, 12:31:00 PM6/12/15
to David Benjamin, Corvin Russell, Chris Bentzel, securi...@chromium.org, net...@chromium.org
Thanks David, I see. 

The user action is the same for both cases, however: the site is broken. Contact whoever runs the site.

I've noted that for the audit. Thanks!

dfont...@gmail.com

unread,
Nov 6, 2015, 12:39:27 PM11/6/15
to Security-dev
I get this same message on Chrome Canary, but not the regular Chrome when I try to logon to the American Airlines website. So, I don't think it's American's problem, but Chrome (Canary) Google's problem. I've been using Chrome Canary as the regular Chrome has typing latency issues in the address bar.

Looks like Chrome is the wrong choice for a reliable browser.

David Benjamin

unread,
Nov 6, 2015, 1:30:25 PM11/6/15
to dfont...@gmail.com, Security-dev
https://www.aa.com depends on RC4, which is to be removed sometime next year around January or February. That puts it at Chrome 48, which is why it's on canary already. This was previously announced by us[0], Microsoft[1], and Mozilla[2,3]. All three browsers expect to remove it around that time.

It seems Mozilla recently managed to reach American Airlines via Twitter? I'll keep an eye on this and see if I can prod them as well.
Reply all
Reply to author
Forward
0 new messages