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

Status: RESOLVED WORKSFORME

(NSS :: Libraries, defect)

Description

[Richard van den Berg]

User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) 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

[Richard van den Berg]

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.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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

Comment 3

[Adam Langley]

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

[Wan-Teh Chang]

Attachment: 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.

Comment 5

[Wan-Teh Chang]

Attachment: SSL handshake trace between Chrome and https://governors.iadb.org/

Comment 6

[Wan-Teh Chang]

Attachment: 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

[Richard van den Berg]

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.