Fallback from TLSv1 to SSLv3 due to different order of cipher suites



8 years ago
8 years ago


(Reporter: richard, Assigned: briansmith)



Firefox Tracking Flags

(Not tracked)



(3 attachments)



8 years ago
User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110420 (CK-bz-1.2) Firefox/3.6.17
Build ID: 20110420140830

Steps to reproduce:

Connect to a HTTPS site through a Bluecoat ProxySG device.

Actual results:

The TLSv1 Client Hello lists cipher suite TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00FF) first. This causes the proxy to respond with an Alert: Warning, Unrecognized Name (0x0170). This in turn causes Firefox to restart the request with a SSLv3 Client Hello. This time TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00FF) is on the bottom of the offered cipher suite list and the connection is established without problems.

Expected results:

NSS should be consistent in where it places the TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00FF) in the cipher suite list. For the above example, the bottom of the list seems the most safe.

Comment 1

8 years ago
Never mind the mention of Bluecoat ProxySG in the above. Other sites connect fine using TLSv1. It seems the fallback to SSLv3 only occurs with some sites like https://governors.iadb.org/ which makes me wonder how common this problem is.
There are two issues to consider:

1. Should we send the SCSV first (like we do now) or last?

2. Currently, we send the SCSV whenver SSL 3.0 is enabled. This logic does not make sense. Either we should send it whenever the SSL 3.0 *or TLS* is enabled (i.e. all the time in ssl3con.c), or we should send it only when TLS is not enabled. Note that the specification says that sending both the SCSV and the renegotiation extension is "not recommended."
Assignee: nobody → bsmith
Target Milestone: --- → 3.12.11

Comment 3

8 years ago
See also https://bugzilla.mozilla.org/show_bug.cgi?id=549042

(In short, in Chrome we only send the SCSV when TLS is disabled.)

Comment 4

8 years ago
Created attachment 548856 [details]
SSL handshake trace between Firefox and https://governors.iadb.org/

This bug requires more investigation.  I don't think it is caused
by the SCSV.

When I visit https://governors.iadb.org/ with Firefox and Chrome,
I see the server send the unrecognized_name alert (at the warning
level) before the server_hello handshake message, but I see no
sign of falling back on SSLv3.  The TLS 1.0 handshakes succeed.
In fact, the server echoes the renegotiation_info extension in
server_hello with both Firefox and Chrome, implying that the
server understands both the SCSV and the renegotiation_info

The unrecognized_name alert is an alert for the Server Name Indication
extension.  I verified that Chrome and Firefox send the correct server
name (governors.iadb.org) in the Server Name Indication extension.
So this seems like a bug in the server's Server Name Indication code.

Unless someone can reproduce not only the unrecognized_name alert
but also the TLS to SSLv3 fallback, we don't need to do anything about
this bug.  I cannot reproduce the TLS to SSLv3 fallback.

Comment 5

8 years ago
Created attachment 548858 [details]
SSL handshake trace between Chrome and https://governors.iadb.org/

Comment 6

8 years ago
Created attachment 548859 [details]
SSL handshake trace between Safari 5.0.5 (Mac OS X 10.6.8) and https://governors.iadb.org/

With Safari, which uses neither the SCSV nor the renegotiation_info
extension, the server still sends the unrecognized_name alert.

Comment 7

8 years ago
I can confirm that with FF 5.0.1 with a direct connection, there is no fallback to SSLv3. I experienced this behavior with FF 3.6.17 behind a proxy. Either of those could be at fault, but there is no issue with the current FF.
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.