Chrome 45: ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION

[ginaor...@gmail.com]

We are getting the following error message "ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION" when trying to access our website. Are there any fixes or workarounds for this?

[PhistucK]

Sounds like you are using an old version of the protocol (SSL 2?). I guess adding support for TLS 1.2 would fix this.

☆PhistucK

On Fri, Sep 4, 2015 at 7:32 PM, <ginaor...@gmail.com> wrote:

We are getting the following error message "ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION" when trying to access our website. Are there any fixes or workarounds for this?

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[David Benjamin]

The issue is likely that your server is buggy and we recently removed the insecure workaround it was relying on. See here for more information:
https://groups.google.com/a/chromium.org/forum/#!searchin/security-dev/fallback/security-dev/F6ZjP6FnyRE/bK7TKtvnHYsJ

What is your server running? (And what's the URL, if it's publicly accessible?)

On Fri, Sep 4, 2015 at 12:37 PM PhistucK <phis...@gmail.com> wrote:

Sounds like you are using an old version of the protocol (SSL 2?). I guess adding support for TLS 1.2 would fix this.

To make sure this doesn't spread, we have NOT started requiring TLS 1.2. Supporting TLS 1.2 with a modern configuration is recomemnded but not required. We have only stopped doing an insecure workaround for buggy servers.

[Gina Ortiz]

We addwe support for TLS 1.2 yesterday.

But the site uses 2008 SQL server which I've heard is not compatible with the updates protocol, could that be the issue?

https://www.benefitsconnect.net/admin

[David Benjamin]

The problem is not TLS 1.2, although your server does not appear to actually support it. There seems to be some problem with your server that prevents it from negotiating versions correctly. See this thread for more information:
https://groups.google.com/a/chromium.org/forum/#!searchin/security-dev/fallback/security-dev/F6ZjP6FnyRE/bK7TKtvnHYsJ

I don't think I've seen any of Microsoft's servers having version negotiation issues. Is your site behind a firewall or some SSL load-balancing product?

[Gina Ortiz]

Yes it is behind a firewall and a load balancing product, any idea of a workaround?

[David Benjamin]

What firewall or load balancer are you using? The bug is probably there.

[ignat soroko]

Is there a way to rollback to an earlier version of Chrome, which works smoothly with all sites? It would be a pity to switch to another browser because of this small bug.

[Eric Mill]

The issue isn't with the browser -- the ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION error clearly indicates a faulty server configuration that prevents the use of TLS' built-in version negotiation. Load balancers are known to be a common culprit -- I've seen F5 load balancers in particular have this bug.

If you're not the administrator of the site, you should find the person who is and poke them about it. I doubt the breakage will be limited to Chrome for very long.

-- Eric

On Tue, Sep 8, 2015 at 2:43 AM, ignat soroko <hayath...@gmail.com> wrote:

Is there a way to rollback to an earlier version of Chrome, which works smoothly with all sites? It would be a pity to switch to another browser because of this small bug.

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

--

konklone.com | @konklone

[David Benjamin]

Which website are you having problems with? Is this a public website or one internal to your organization?

David

[ignat....@gmail.com]

David,

It is the main students' portal at the University of Oklahoma:

https://ozone.ou.edu

Thanks!

Ignat

[PhistucK]

What a cryptic message for non techy users...
"SSL server probably obsolete."

☆PhistucK

[Hanno Böck]

On Tue, 8 Sep 2015 23:24:45 -0700 (PDT)
ignat....@gmail.com wrote:

> It is the main students' portal at the University of Oklahoma:
>
> https://ozone.ou.edu

This site has a lot of problems:
https://www.ssllabs.com/ssltest/analyze.html?d=ozone.ou.edu

The one that bites you here is the "TLS version intolerance" issue. It
doesn't correctly respont to requests with higher TLS versions.

Appart from that it is only allowing connections with RC4 and MD5. Most
browsers are in the process or plan to fully deprecate RC4.

This is clearly something the site operator has to fix.

--
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[Daniel Bratell]

On Wed, 09 Sep 2015 08:26:58 +0200, PhistucK <phis...@gmail.com> wrote:

What a cryptic message for non techy users...
"SSL server probably obsolete."

(slightly OT)

I suggest "Server is a big black security hole and we do not dare enter".

If Google doesn't adopt that explanation, maybe I can convince the translators here at Opera to use it. :-)

/Daniel

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[David Benjamin]

As Hanno mentioned, this server is quite problematic. Even without the version intolerance bug, it requires RC4 which will be removed in the future:

https://groups.google.com/a/chromium.org/d/msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ

Do you run this server? Now is a good time to revisit its configuration. If not, could you get in touch with whoever does and find out what software they're running? Specifically what SSL stack, is there some kind of a firewall in front of it, etc? The ServerHello contains no extensions, so I'm guessing it's something old, but it's not clear what.

David

[padmapr...@gmail.com]

On Friday, September 4, 2015 at 10:02:25 PM UTC+5:30, ginaor...@gmail.com wrote:
> We are getting the following error message "ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION" when trying to access our website. Are there any fixes or workarounds for this?

This is pathetic situation, we are experiencing off-late, it used to work earlier. Latest chrome ( v45) we see this issue often.

Unable to login to most of the websites as well.
Time to move to a different browser :)

-Prasad

[PhistucK]

Can you list the URLs for which you get it?

Perhaps the team can try and talk to them in order to fix their server.

Nevertheless, enjoy your different browser! :)

☆PhistucK

[Padma Prasad D]

Thanks for the quick response.

Some of the URL's, I tired are on my intranet, you can provide any relevant information which I can pass it onto my team to get this addressed.

Following URL also has same issue if I try in Internet

https://www.mtsindia.in/

[PhistucK]

For the intranet ones, you can point the team to this thread, or to this one (linked from one of the posts) -

https://groups.google.com/a/chromium.org/forum/#!searchin/security-dev/fallback/security-dev/F6ZjP6FnyRE/bK7TKtvnHYsJ

Updating the servers (or reconfiguring their TLS stack) will probably fix the issue, I believe.

Also, note that as a workaround, you can set a group policy that re-enables the feature, but as time goes by, the feature will be dropped completely from Chrome and probably from the rest of the browsers as well (Firefox already dropped it, for example).

See the crbug link the linked thread mentions.

☆PhistucK

[Gina Ortiz]

We've installed a new load balancer. The load balancer we had didn't support the upgrade. At present we are redirecting our web servers so that they don't hit the load balancer. This is the temp solution. Once the new one is up and running we will add the servers.

Thank you for all your help.

[Hanno Böck]

On Mon, 14 Sep 2015 15:42:46 +0530

Padma Prasad D <padmapr...@gmail.com> wrote:

> Following URL also has same issue if I try in Internet
>
> https://www.mtsindia.in/

This one is actually interesting, I think chrome devs should have a
look here, there's something strange going on.

It has a lot of problems:
https://www.ssllabs.com/ssltest/analyze.html?d=mtsindia.in&s=116.202.228.67

*but* there is nothing here that would explain why chrome wouldn't
connect to it. It should support TLS 1.0 with some still supported
ciphers (TLS_RSA_WITH_AES_128_CBC_SHA at least) and the version
intolerance doesn't indicate a problem with TLS 1.1/1.2 connection
attempts (I hope the ssl labs test is correct here).

Chrome shows an
ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION
error. I don't know why. Firefox connects to the site.

[David Benjamin]

This server is version-intolerant, but not in a usual way. SSL Labs' test is not very good and doesn't capture what's going on with that site.

It seems to negotiate SSL 3.0 when you offer TLS 1.1 or TLS 1.2, but TLS 1.0 if you offer TLS 1.0! SSL 3.0 is now forbidden, so those handshakes fail. Both Chrome and Firefox have rather liberal fallback conditions, so that triggers the fallback and (used to) eventually work when going down to TLS 1.0.

Firefox is only working because they have mtsindia.in on their whitelist. Chrome does not maintain a fallback whitelist. I would like to avoid doing that if possible and would prefer that enterprises use SSLVersionFallbackMin and work towards fixing their servers.

I see a "Contact Us" link on their page, so I'll send them a note.

David 

[David Benjamin]

Actually, this doesn't seem to be an online form. Padma, I'm guessing you're one of their customers? Could you contact them and let them know their website has problems? They probably have some incredibly buggy load balancer or firewall in front of their server. See this thread for more information.

https://groups.google.com/a/chromium.org/forum/#!searchin/security-dev/fallback/security-dev/F6ZjP6FnyRE/bK7TKtvnHYsJ

In the meantime, you may set the SSLVersionFallbackMin administrative policy across your organization, as described elsewhere in this thread and here:

https://www.chromium.org/administrators/policy-list-3#SSLVersionFallbackMin

For configuring policies on Windows and in general, see:

https://www.chromium.org/administrators/policy-templates

https://support.google.com/chrome/a/answer/187202

This will temporarily work around the problem until you resolve the problems with your servers. You should reach out to your software vendors and ask them if there is an update which resolves the bugs.

The servers in question are simply buggy. We have not removed any older versions of any protocols. Rather we have removed the workaround for the very small fraction of servers which never implemented TLS 1.0 correctly. This workaround is insecure and harms security of all websites for all users, not just the small fraction of broken servers.

 

David

[David Benjamin]

On Mon, Sep 14, 2015 at 7:49 AM Gina Ortiz <ginaor...@gmail.com> wrote:

We've installed a new load balancer. The load balancer we had didn't support the upgrade. At present we are redirecting our web servers so that they don't hit the load balancer. This is the temp solution. Once the new one is up and running we will add the servers.

Thank you for all your help.

Glad to hear it. Thanks for resolving the issue! This is in part an ecosystem problem, so fixing problematic servers is much appreciated.

David

[Hanno Böck]

On Mon, 14 Sep 2015 16:22:05 +0000
David Benjamin <davi...@chromium.org> wrote:

> It seems to negotiate SSL 3.0 when you offer TLS 1.1 or TLS 1.2, but
> TLS 1.0 if you offer TLS 1.0! SSL 3.0 is now forbidden, so those
> handshakes fail. Both Chrome and Firefox have rather liberal fallback
> conditions, so that triggers the fallback and (used to) eventually
> work when going down to TLS 1.0.

Ah that's interesting to learn.
Are you aware of a test tool that is capable of detecting and
separating the various variants of version intolerance? Might be handy
to have something.

I will ping Ivan, maybe he wants to update SSL labs check on it.

[David Benjamin]

On Mon, Sep 14, 2015 at 12:40 PM Hanno Böck <ha...@hboeck.de> wrote:

On Mon, 14 Sep 2015 16:22:05 +0000
David Benjamin <davi...@chromium.org> wrote:

> It seems to negotiate SSL 3.0 when you offer TLS 1.1 or TLS 1.2, but
> TLS 1.0 if you offer TLS 1.0! SSL 3.0 is now forbidden, so those
> handshakes fail. Both Chrome and Firefox have rather liberal fallback
> conditions, so that triggers the fallback and (used to) eventually
> work when going down to TLS 1.0.

Ah that's interesting to learn.
Are you aware of a test tool that is capable of detecting and
separating the various variants of version intolerance? Might be handy
to have something.

My testing tool is "try it in Chrome and look at net-internals", followed by "play around with BoringSSL's command-line client, optionally with flags that match Chrome's ClientHello", followed by "play with other browsers and look at Wireshark". :-)

It's hard to do a definitive test that's not actually trying it in a browser. E.g. this particular one only manifests if you forbid SSL 3.0. I've seen evidence of servers which implement TLS 1.2 client auth wrong, so it only manifests if you try to authenticate. I've also seen servers that implement AES-GCM wrong, so that only manifests if you complete the handshake.

 

I will ping Ivan, maybe he wants to update SSL labs check on it.

I would be mildly curious if this particular version negotiation bug exists elsewhere, but this is the first time I've ever heard of it. I can guess how it happened, but it really is quite bizarre!

David

[David Benjamin]

On Mon, Sep 14, 2015 at 12:46 PM David Benjamin <davi...@chromium.org> wrote:

On Mon, Sep 14, 2015 at 12:40 PM Hanno Böck <ha...@hboeck.de> wrote:

On Mon, 14 Sep 2015 16:22:05 +0000
David Benjamin <davi...@chromium.org> wrote:

> It seems to negotiate SSL 3.0 when you offer TLS 1.1 or TLS 1.2, but
> TLS 1.0 if you offer TLS 1.0! SSL 3.0 is now forbidden, so those
> handshakes fail. Both Chrome and Firefox have rather liberal fallback
> conditions, so that triggers the fallback and (used to) eventually
> work when going down to TLS 1.0.

Ah that's interesting to learn.
Are you aware of a test tool that is capable of detecting and
separating the various variants of version intolerance? Might be handy
to have something.

My testing tool is "try it in Chrome and look at net-internals", followed by "play around with BoringSSL's command-line client, optionally with flags that match Chrome's ClientHello", followed by "play with other browsers and look at Wireshark". :-)

It's hard to do a definitive test that's not actually trying it in a browser. E.g. this particular one only manifests if you forbid SSL 3.0. I've seen evidence of servers which implement TLS 1.2 client auth wrong, so it only manifests if you try to authenticate. I've also seen servers that implement AES-GCM wrong, so that only manifests if you complete the handshake.

If you want a classifier, this may be a start:

https://code.google.com/p/chromium/codesearch#chromium/src/net/socket/ssl_client_socket_openssl.cc&l=1071

https://code.google.com/p/chromium/codesearch#chromium/src/net/ssl/ssl_failure_state.h&rcl=1442215459&l=10

These all correspond to different kinds of failures I've seen. At this point, SSL_FAILURE_BUGGY_GCM seems to be the biggest source of problems. So, actually, if SSL Labs or others are interested in classifying those, flagging that would probably be most helpful.
 

[vasco.m....@gmail.com]

Online check-in on TAAG https://fastcheck.sita.aero/cce-presentation-web-dt/entryUpdate.do also don't work. I had to use Microsoft Internet Explorer.

[PhistucK]

I suggest that you use their feedback or contact link to let them know about it, this is a good first step.

☆PhistucK

On Fri, Nov 27, 2015 at 2:58 AM, <vasco.m....@gmail.com> wrote:

Online check-in on TAAG https://fastcheck.sita.aero/cce-presentation-web-dt/entryUpdate.do also don't work. I had to use Microsoft Internet Explorer.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.

[David Benjamin]

This server also will stop working next year on other browsers (including Internet Explorer), so they'll need to get themselves fixed. I'll see if there's any way we can reach out on our end.

[pe...@petermcgrath.com]

On Tuesday, September 8, 2015 at 5:19:56 PM UTC+10, Eric Mill wrote:
> The issue isn't with the browser -- the ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION error clearly indicates a faulty server configuration that prevents the use of TLS' built-in version negotiation. Load balancers are known to be a common culprit -- I've seen F5 load balancers in particular have this bug.
>

Eric - you are an idiot. The browser has been programmed to reject these connections.

The issue IS with the browser, and google's decision to disable support for this version of SSL.

This is just another reason not to use chrome.

[Chris Palmer]

Please don't resort to name-calling. It's not cool and entirely counter-productive.

Anyway, I think you'll find that all mainstream browsers are moving toward not supporting TLS configurations that do not provide the intended security guarantees. Modern, up-to-date server software should pose no problem.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.

[hieuv...@gmail.com]

Vào 23:32:25 UTC+7 Thứ Sáu, ngày 04 tháng 9 năm 2015, ginaor...@gmail.com đã viết:

[Joe Mason]

Yes, upgrade the version of SSL your website is using. Older versions have security holes.

I recommend getting a free SSL report for your site from https://www.ssllabs.com/ssltest/ to see the latest security guidelines.

[660391257pela...@gmail.com]

[Eric Lawrence]

What is the URL of the site in question? Have you tried running the SslLabs.com server test on it to see what it has available?

In general, it is likely that the site will need to have its software updated to a more modern configuration. 

[David Benjamin]

(Chrome hasn't shown that error code since August 2016 so you probably also should update you browser.)

[carledwar...@gmail.com]

I own the site and im the only one with to block it and fix it. It will be up running and if you want to help and have dev. Skills feel free to help but,I have 24 -7 monitoring on the system.thanks carl