Closed Bug 1151781 Opened 5 years ago Closed 5 years ago

e3.greyridge.com is TLS 1.1/1.2 intolerant

Categories

(Web Compatibility :: Desktop, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: tom.hill, Unassigned)

References

()

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

Tried to connect to https://e3.greyridge.com/ssltest.html



Actual results:

Got an error:  Secure connection failed.  The connection to e3.greyridge.com was interrupted whilst the page was loading.


Expected results:

This server used to work fine with SSL using Version 36 on Windows 7.  It is using slightly older SSL protocols (specifically TLSv1.0 is the highest supported protocol) as it is the Oracle HTTP Server underneath (rebranded version of Apache but using Oracle SSL rather than straight OpenSSL) but still allows connection without issue from Chrome (41.0) and IE 11.

I couldn't find a way to enable a dump of the handshake between Firefox and the server to help debug this.  If there is a simple way to do this, please let me know and I will attach them.
(In reply to Loic from comment #1)
> Regression range:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=f1f48ccb2d4e&tochange=5b01216f97f8
> 
> Another TLS intolerance, I think.
> https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fe3.greyridge.
> com%2Fssltest.html

I agree.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: Version 37 SSL Failure / Version 36 OK → e3.greyridge.com is TLS 1.1/1.2 intolerant
Version: 37 Branch → unspecified
Tom:

Thanks for the report. It looks like the server being used is intolerant to TLS 1.1 and 1.2. Based on your e-mail address, I assume you can get the server fixed, or contact someone who can?

The server in question can be added to a whitelist so that fallbacks will occur again by default, but the earliest that change will hit a release version is Firefox 38 .

Thanks!
Hi there.

So you know, the server itself is running OHS11g which is a relatively up to date part of the Oracle Fusion Middleware stack.  From experience, the chances of Oracle releasing timely patches for the SSL stack are limited to none, so this might affect a number of sites.

We're looking at sticking vanilla apache in front of the server as a proxy anyway, however this obviously requires significant testing to ensure no regressions.  

So we know what to tell our clients whilst we update our infrastructure, could you tell me

1. What has changed between 36 and 37 which causes the protocol intolerance to TLSv1.1 and TLSv1.2 to be a problem.
2. What is the likely timescale for the v38 release

Thanks for the quick investigation and feedback
(In reply to Tom from comment #4)
> So you know, the server itself is running OHS11g which is a relatively up to
> date part of the Oracle Fusion Middleware stack.  From experience, the
> chances of Oracle releasing timely patches for the SSL stack are limited to
> none, so this might affect a number of sites.

That's unfortunate, but nothing you can do I guess.

> 1. What has changed between 36 and 37 which causes the protocol intolerance
> to TLSv1.1 and TLSv1.2 to be a problem.

In previous Firefox versions, connections to servers that are TLS 1.1/1.2 intolerant are retried with lower TLS versions in an attempt to increase compatibility. However, this practice enables attackers to MITM connections, and cause fallbacks to older, less secure versions.

Hence, in Firefox 37, TLS version fallbacks have been disabled by default except for sites on a static whitelist, with the intent of eventually eliminating fallbacks entirely.

You can see Bug 1084025 and Bug 1114816 for more details.

> 2. What is the likely timescale for the v38 release

Firefox 38 should be released on the week of 2015-05-12: https://wiki.mozilla.org/RapidRelease/Calendar
In the mean time, these prefs (in most to least preferred) can be set so connections are possible again:
security.tls.insecure_fallback_hosts = e3.greyridge.com (a comma separated list of domains)
security.tls.version.fallback-limit = 1
security.tls.version.max = 1
Component: Security: PSM → Desktop
Product: Core → Tech Evangelism
Thanks for the detailed information.  Could you also add https://server1.isoinabox.co.uk/ to the static whitelist for now, in case we haven't got the reverse proxy solution in place before FF38 comes out.

To be honest, I've never been keen on the OHS SSL implementation, so putting a proxy in front is not a hardship.  It's just not much fun implementing and testing it across all our systems!
(In reply to Tom from comment #7)
> Thanks for the detailed information.  Could you also add
> https://server1.isoinabox.co.uk/ to the static whitelist for now, in case we
> haven't got the reverse proxy solution in place before FF38 comes out.

Sure. Note that this bug is a Tech Evangelism bug, so it tracks when your servers are fixed. The whitelist work will be done in Bug 1142769, so you might want to CC yourself there as well.

> To be honest, I've never been keen on the OHS SSL implementation, so putting
> a proxy in front is not a hardship.  It's just not much fun implementing and
> testing it across all our systems!

Yes, I understand. Thanks for the patience!
By the way, something you should probably look at is that Mozilla's SSL guidelines here

https://wiki.mozilla.org/Security/Server_Side_TLS

suggest TLSv1,TLSv1.1 and TLSv1.2 for intermediate compatibility (which is effectively the strongest "usable" setting, since modern excludes any version of IE below 11).  This is also brought up by the SSL configuration generator which simply uses

SSLProtocol ALL -SSLv2 -SSLv3

These should probably point out that you can't just run TLSv1 now
Fixed.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.