Open Bug 1107103 Opened 5 years ago Updated 5 years ago does not work in Firefox 34 and later


(NSS :: Libraries, defect, major)

Windows XP
Not set


(Not tracked)



(Reporter: therubex, Unassigned)


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


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:

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.
Closed: 5 years ago
Resolution: --- → WONTFIX
Indeed.  From the Firefox 34 release notes:

 Changed: Disabled SSLv3
According to, 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.
Keywords: regression
Resolution: WONTFIX → ---
Summary: SSL 3.0 Broken in Firefox 34 → 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?
> So unless there are some other Prefs that need to be tweaked, looks like a
> regression to me.



allows the & 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).

> 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 ;-).


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).
h ttp:/ /
You need to log in before you can comment on or make changes to this bug.