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)
NSS
Libraries
Tracking
(Not tracked)
RESOLVED
WORKSFORME
3.12.1
People
(Reporter: KaiE, Assigned: ngm+mozilla)
References
Details
Attachments
(1 file)
62.97 KB,
text/plain
|
Details |
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
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Comment 2•17 years ago
|
||
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
Comment 3•17 years ago
|
||
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.
Comment 4•17 years ago
|
||
The RFE that added TLSSTE to NSS was bug 403563.
Reporter | ||
Comment 5•17 years ago
|
||
(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
Comment 6•17 years ago
|
||
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
Assignee | ||
Comment 7•17 years ago
|
||
I'm looking into this.
Comment 8•17 years ago
|
||
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.
Assignee | ||
Comment 9•17 years ago
|
||
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.
Assignee | ||
Comment 10•17 years ago
|
||
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 | ||
Updated•17 years ago
|
Assignee: wtc → ngm+mozilla
Assignee | ||
Comment 12•17 years ago
|
||
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 ago → 17 years ago
Resolution: --- → FIXED
Comment 13•17 years ago
|
||
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 → ---
Updated•17 years ago
|
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•