Open Bug 1107103 Opened 5 years ago Updated 5 years ago

https://wcis.ceiwc.com does not work in Firefox 34 and later

Categories

(NSS :: Libraries, defect, major)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

REOPENED

People

(Reporter: therubex, Unassigned)

Details

(Keywords: regression)

SSL 3.0 Broken in Firefox 34

(At least some) sites that required SSL 3.0 to be enabled no longer work as of FF34.

URL: https://wcis.ceiwc.com/sso/Login.do

That page will not load.
Setting security.tls.version.min;0 no longer works.

It does work in Firefox 33.

So unless there are some other Prefs that need to be tweaked, looks like a regression to me.

> SSL peer rejected a handshake message for unacceptable content.
> (Error code: ssl_error_illegal_parameter_alert)

Another site: https://servizididattica.unical.it/ssweb/gissweb.home
(from https://bugzilla.mozilla.org/show_bug.cgi?id=951156#c33)

SeaMonkey 2.31 is likewise affected.
Assignee: nobody → nobody
Component: General → Libraries
Product: Core → NSS
Version: 34 Branch → 3.0
(I moved this to NSS | Libraries, but have no idea what the Version should be.)
SSL 3 is dead.

https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Indeed.  From the Firefox 34 release notes:

 Changed: Disabled SSLv3
According to https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwcis.ceiwc.com%2F, this server does support TLS 1.0. However, it also says that the server is "extension intolerant."

More work should be done to identify exactly what the extension intolerance issue is, to see if it can be worked around--e.g. by changing the order of extensions in the ClientHello, by dropping the padding extension, etc.
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: WONTFIX → ---
Summary: SSL 3.0 Broken in Firefox 34 → https://wcis.ceiwc.com does not work in Firefox 34 and later
With the Summary: change, perhaps there is some reference information in the link below that could help?

http://forums.mozillazine.org/viewtopic.php?p=13862063#p13862063
> So unless there are some other Prefs that need to be tweaked, looks like a
> regression to me.

Setting:

security.tls.version.min;0
AND
security.tls.version.fallback-limit;0

allows the ceiwc.com & unical.it pages to load.
So, what exactly is the difference between security.tls.version.min and .fallback-limit if either of those prevents you to go below the minimum and need to be set to 0 to be able to use SSL 3.0?

This looks a bit redundant to me (and we are exposing .min in SeaMonkey's UI but not .fallback-limit).
From, http://www.dslreports.com/forum/r29703508-FF34-and-SSL3

> In the Bug, Brian spoke of "extension intolerance issue ... changing the order of
> extensions in the ClientHello".

> Now I have no idea what that means, but maybe it is for those reasons that I can
> see different results at different times with the same tls Pref settings."

Now maybe this is totally expected behavior, for you, but seeing different behavior, for me, is nothing more then confusing ;-).

IOW...

1. Starting with a new Profile, neither ceiwc page will load, by default in FF34.
2. Once you change the two tls Prefs to '0', both pages will load.
3. But then if you revert those changes back to defaults, then the one page loads but the other will not.

It is 3. that was unexpected for me, as I would have expected 1.
Oh, that link didn't work, lets try again, twice (with one purposely broken).

http://www.dslreports.com/forum/r29703508-FF34-and-SSL3
h ttp:/ /www.dslreports.com/forum/r29703508-FF34-and-SSL3
You need to log in before you can comment on or make changes to this bug.