919677 - NSS advertises TLS 1.2 ciphersuites in a TLS 1.1 ClientHello

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Ryan Sleevi]

NSS advertises SHA-256 ciphersuites with a TLS 1.1 ClientHello.

This breaks interop with PolarSSL servers because they also have a bug - they accept the SHA-256 ciphersuite and then break because they negotiated TLS 1.1

Comment 1

[Ryan Sleevi]

Originally reported by Adam Langley against Chromium at https://code.google.com/p/chromium/issues/detail?id=297151

Comment 2

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

Is the problem that the PolarSSL server breaks itself by negotiating a SHA-256 ciphersuite and then has some internal error? Or, is the problem that the PolarSSL server negotiates a SHA-256 cipher suite and then we, the NSS client refuses to continue because SHA-256 is not allowed?

If it is the former, then that sucks pretty bad. If it is the latter, then IMO we should just try to keep going with the SHA-256 cipher suite even on a TLS 1.1 connection, treating it like a TLS 1.2 connection except for the on-the-wire record version numbers.

Comment 3

[Eric Rescorla (:ekr)]

Fixed title.

Comment 4

[Adam Langley]

Initially I thought that PolarSSL was picking a SHA256 cipher suite and then falling over its own shoelaces, but having looked at the NSS code, I'm now not sure. NSS doesn't check the version when sending the cipher suites in the ClientHello, but does check the version when processing the ServerHello, so it's possible that it's NSS that's breaking when Polar sends a SHA256 cipher suite back.

I don't have an example PolarSSL server to be sure however. I tried https://polarssl.org, but it doesn't exhibit this problem.
 
(Chromium patch: https://codereview.chromium.org/23928007/, out for Wan-Teh's review)

Comment 5

[Adam Langley]

I confirmed with the PolarSSL folks that the issue is that NSS chokes on the SHA256 ciphersuite in the ServerHello. It's not an internal, PolarSSL error.

Comment 6

[Gervase Markham [:gerv]]

Is this what's ironically preventing me from viewing https://www.imperialviolet.org/2013/03/20/alpn.html in Firefox 27.0a1?

Secure Connection Failed

An error occurred during a connection to www.imperialviolet.org. SSL peer selected a cipher suite disallowed for the selected protocol version. (Error code: ssl_error_cipher_disallowed_for_version)

Gerv

Comment 7

[Adam Langley]

(In reply to Gervase Markham [:gerv] from comment #6)
> Is this what's ironically preventing me from viewing
> https://www.imperialviolet.org/2013/03/20/alpn.html in Firefox 27.0a1?

Yes, I'm running a prerelease Go 1.2 on that server. It's on my todo list now to not try selecting these cipher suites out-of-version.

Comment 8

[Wan-Teh Chang]

Attachment: Patch by Adam Langley

This patch has been reviewed by me at https://codereview.chromium.org/23928007/.

Comment 9

[Wan-Teh Chang]

Patch checked in: https://hg.mozilla.org/projects/nss/rev/203eb8e22a97

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

We need this landed to mozilla-central (and possibly uplifted to mozilla-aurora if there's time and it's low risk).  Can you prepare the patch & mark for checkin?

Comment 11

[Wan-Teh Chang]

lsblakk: yes, Brian Smith or I can prepare a NSS 3.15.3 Beta 1 release and push it to
mozilla-central.

Comment 12

[Wan-Teh Chang]

Kai: this bug should be considered a regression in NSS 3.15.1.
We should include the fix in NSS 3.15.3. Thanks.

Comment 13

[Kai Engert (:KaiE:)]

(In reply to Wan-Teh Chang from comment #12)
> Kai: this bug should be considered a regression in NSS 3.15.1.
> We should include the fix in NSS 3.15.3. Thanks.

I agree, I had suggested the same on our list, and I've included it in the NSS_3_15_3_BETA3 tag already.

It's included, because the branch is based on revision 10853:eeb277ec054c, which came after the landing of this bug in revision 10852:203eb8e22a97

Comment 14

[Kai Engert (:KaiE:)]

(I agree it would have been clearer, if I had used NSS_3_15_2_RTM as the base for the branch. But I had followed your proposal to use a more recent snapshot, if possible, and that revision seemed appropriate, as it contained only the version number change and the checkin for this bug.)

Comment 15

[Al Billings [:abillings - ex-MoCo]]

Can someone tell me if there is a reason why this issue, fixed in NSS 3.15.3, doesn't have a CVE assigned?

I'm writing an advisory for the NSS update in the current release and want to reference bugs/CVEs that we addressed with the NSS update.

Comment 16

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

(In reply to Al Billings [:abillings] from comment #15)
> Can someone tell me if there is a reason why this issue, fixed in NSS
> 3.15.3, doesn't have a CVE assigned?

This is a compatibility bug, not a security bug.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

All right. This won't be called out then.

Comment 18

[Wan-Teh Chang]

Al: this bug is fixed in NSS 3.15.3 because it is a regression.