Closed Bug 430703 Opened 17 years ago Closed 17 years ago

Intermittent ssl_error_rx_unexpected_change_cipher when server supports TLS Session Ticket Extension

Categories

(NSS :: Libraries, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
3.12.1

People

(Reporter: KaiE, Assigned: ngm+mozilla)

References

Details

Attachments

(1 file)

reported here http://forums.mozillazine.org/viewtopic.php?t=650683 and I can reproduce. About 25% of the connection attempts, the SSL connection to https://limedaley.com/webmail/ fails with ssl_error_rx_unexpected_change_cipher
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Although this site's problem has the same user-visible symptom as bug 265298, it is not the same bug, so I'm reopening this. This site's bug is due to a problem with the new TLS Session Ticket Extension. Don't yet know if it's a client problem or a server problem. More info to follow shortly.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Intermittent ssl_error_rx_unexpected_change_cipher → Intermittent ssl_error_rx_unexpected_change_cipher when server supports TLS Session Ticket Extension
The attached file of ssltap output shows that this server is using the new TLS Session Ticket Extension. This is a brand new feature of TLS, brand new in FF3, and undoubtedly new in this server as well. I don't know if this is a server problem or client problem yet. Sadly, ssltap was not enhanced to understand TLS STE, so the output is perhaps not as informative as it might be, but I think it contains all the salient information. This output shows a series of connections. The first one seems to be OK. The second one attempts to restart the session established by the first one. The second one fails with the unexpected change_cipher_specs message. Wan-Teh, Please take this bug, or assign it to Nagendra Modadugu, as you see fit. IIRC, PSM implemented a way to disable this extension. Wan-Teh or Nagendra, please add a comment to this bug telling the reporter how to work around this bug by disabling TLSSTE. Thanks.
The RFE that added TLSSTE to NSS was bug 403563.
Depends on: tlsste
Priority: -- → P1
Target Milestone: --- → 3.12.1
(In reply to comment #3) > Wan-Teh or Nagendra, please add a comment to this bug telling the > reporter how to work around this bug by disabling TLSSTE. I guess the following will do it: - go to about:config - filter display by typing: tls - change the value for "security.enable_tls_session_tickets" to false
I believe this is an old OpenSSL bug that Nagendra's code used to work around, as indicated by this "dangling" comment without the matching code: Index: ssl3con.c =================================================================== RCS file: /cvsroot/mozilla/security/nss/lib/ssl/ssl3con.c,v retrieving revision 1.103 retrieving revision 1.103.8.1 diff -u -u -r1.103 -r1.103.8.1 --- ssl3con.c 22 Aug 2007 06:12:02 -0000 1.103 +++ ssl3con.c 22 Dec 2007 00:20:12 -0000 1.103.8.1 @@ -2522,6 +2521,10 @@ SSL_TRC(3, ("%d: SSL3[%d]: handle change_cipher_spec record", SSL_GETPID(), ss->fd)); + /* When doing a stateless resume, OpenSSL sends the SessionTicket + * extension but does not send a NewSessionTicket message so we + * work around the bug here. + */ if (ws != wait_change_cipher) { (void)SSL3_SendAlert(ss, alert_fatal, unexpected_message); PORT_SetError(SSL_ERROR_RX_UNEXPECTED_CHANGE_CIPHER); The workaround is to also allow |ws| to be wait_new_session_ticket there. I will do some experiments to verify this.
Assignee: nobody → wtc
Status: REOPENED → NEW
I'm looking into this.
Please ignore my comment 6. |ws| is wait_server_cert when we receive the change_cipher_spec message from the server. The problem is that the server decides to resume the session with our ticket, but responds with a ServerHello that has an empty session ID rather than the session ID we generated. This violates RFC 5507, Section 3.4 Interaction with TLS Session ID: When presenting a ticket, the client MAY generate and include a Session ID in the TLS ClientHello. If the server accepts the ticket and the Session ID is not empty, then it MUST respond with the same Session ID present in the ClientHello. This allows the client to easily differentiate when the server is resuming a session from when it is falling back to a full handshake.
The bug is in OpenSSL. limedaley.com is running on OpenSSL-0.9.8g with SSL session caching turned off. When session caching is turned off, an OpenSSL server returns a zero-length SessionID regardless of whether the session ticket extension has been negotiated. This behavior is in violation of RFC 5507 as noted by Wan-Teh. I will make a request to the OpenSSL team that this behavior be fixed, but in the mean time, the implication of this bug is: NSS clients that have enabled the session ticket extension will be unable to resume sessions with OpenSSL servers that have disabled session caching.
Workarounds till a fix is available: a) turn of session tickets in FF as per https://bugzilla.mozilla.org/show_bug.cgi?id=430703#c5 or b) enable session caching on the OpenSSL based server.
Assignee: wtc → ngm+mozilla
A fix has been committed to the OpenSSL source tree, and will become available with the next release thanks to Stephen Henson: http://cvs.openssl.org/chngview?cn=17088 [Note: this bug was not detected by the OpenSSL client due to lenient parsing of SessionID's. The OpenSSL client is now stricter: http://cvs.openssl.org/chngview?cn=17098]
Status: NEW → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Since this bug was not in NSS code, and was not fixed by any change to NSS, the proper resolution is "WORKSFORME" rather than "FIXED". I'll change it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: