13.23 KB, text/plain
13.48 KB, text/plain
8.86 KB, text/plain
User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:126.96.36.199) 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.
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
See also https://bugzilla.mozilla.org/show_bug.cgi?id=549042 (In short, in Chrome we only send the SCSV when TLS is disabled.)
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 extension. 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.
Created attachment 548858 [details] SSL handshake trace between Chrome and https://governors.iadb.org/
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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.