Closed
Bug 134125
Opened 22 years ago
Closed 18 years ago
SSL handshake cut-off with incorrect server configuration
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.7
People
(Reporter: julien.pierre, Assigned: nelson)
Details
Attachments
(3 files)
16.00 KB,
application/octet-stream
|
Details | |
16.00 KB,
application/octet-stream
|
Details | |
1.15 KB,
patch
|
Details | Diff | Splinter Review |
This is a follow-up to bug 134122 . The server was configured with a model socket and client auth required, but no trusted CAs in its database. When connecting with Communicator 4.79, the client displayed a "network error". Mozilla 0.9.9 just ignored the URL I type, keeping a blank page !!! IE just said that the page could not be displayed. NES logged the following : [28/Mar/2002:20:43:21] failure ( 4235): Error receiving connection (SSL_ERROR_NO_TRUSTED_SSL_CLIENT_CA - the CA that signed the client certificate is not trusted locally) An ssltap (shown below) showed that the client was sending the clienthelo message, but the server was not sending anything, apparently just closing the connection. I attached to the server and it showed that the above error was coming from the first PR_Recv on the newly-imported SSL socket after PR_Accept. Connection 1 is with Communicator 4.79 , 2 and 3 with Mozilla 0.9.9 (i did just one attempt, it made 2 connections), 4 and 5 with IE6 (again, just one browser attempt, but got two connections). Version: $Revision: 1.2 $ ($Date: 2002/03/15 06:04:32 $) $Author: wtc%netscape.com $ Connection #1 [Thu Mar 28 20:26:24 2002] Connected to strange:3000 --> [ alloclen = 72 bytes (72 bytes of 72) [Thu Mar 28 20:26:24 2002] [ssl2] ClientHelloV2 { version = {0x03, 0x00} cipher-specs-length = 45 (0x2d) sid-length = 0 (0x00) challenge-length = 16 (0x10) cipher-suites = { (0x010080) SSL2/RSA/RC4-128/MD5 (0x020080) SSL2/RSA/RC4-40/MD5 (0x030080) SSL2/RSA/RC2CBC128/MD5 (0x040080) SSL2/RSA/RC2CBC40/MD5 (0x060040) SSL2/RSA/DES56-CBC/MD5 (0x0700c0) SSL2/RSA/3DES192EDE-CBC/MD5 (0x000004) SSL3/RSA/RC4-128/MD5 (0x00feff) ????/????????/?????????/??? (0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA (0x00fefe) ????/????????/?????????/??? (0x000009) SSL3/RSA/DES56-CBC/SHA (0x000064) TLS/RSA_EXPORT1024/RC4-56/SHA (0x000062) TLS/RSA_EXPORT1024/DES56_CBC/SHA (0x000003) SSL3/RSA/RC4-40/MD5 (0x000006) SSL3/RSA/RC2CBC40/MD5 } session-id = { } challenge = { 0xd9b9 0x432a 0x4c5a 0x0988 0xa69b 0xba97 0x8b7d 0xaeeb } } ] Read EOF on Server socket. [Thu Mar 28 20:26:24 2002] Read EOF on Client socket. [Thu Mar 28 20:26:24 2002] Connection #2 [Thu Mar 28 20:26:37 2002] Connected to strange:3000 --> [ alloclen = 72 bytes (72 bytes of 72) [Thu Mar 28 20:26:37 2002] [ssl2] ClientHelloV2 { version = {0x03, 0x01} cipher-specs-length = 45 (0x2d) sid-length = 0 (0x00) challenge-length = 16 (0x10) cipher-suites = { (0x010080) SSL2/RSA/RC4-128/MD5 (0x030080) SSL2/RSA/RC2CBC128/MD5 (0x0700c0) SSL2/RSA/3DES192EDE-CBC/MD5 (0x060040) SSL2/RSA/DES56-CBC/MD5 (0x020080) SSL2/RSA/RC4-40/MD5 (0x040080) SSL2/RSA/RC2CBC40/MD5 (0x000004) SSL3/RSA/RC4-128/MD5 (0x00feff) ????/????????/?????????/??? (0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA (0x00fefe) ????/????????/?????????/??? (0x000009) SSL3/RSA/DES56-CBC/SHA (0x000064) TLS/RSA_EXPORT1024/RC4-56/SHA (0x000062) TLS/RSA_EXPORT1024/DES56_CBC/SHA (0x000003) SSL3/RSA/RC4-40/MD5 (0x000006) SSL3/RSA/RC2CBC40/MD5 } session-id = { } challenge = { 0x95be 0x81ab 0xd2da 0x0b5b 0xa3bb 0x284f 0x3097 0x5761 } } ] Read EOF on Server socket. [Thu Mar 28 20:26:37 2002] Read EOF on Client socket. [Thu Mar 28 20:26:37 2002] Connection #3 [Thu Mar 28 20:26:37 2002] Connected to strange:3000 --> [ alloclen = 72 bytes (72 bytes of 72) [Thu Mar 28 20:26:37 2002] [ssl2] ClientHelloV2 { version = {0x03, 0x00} cipher-specs-length = 45 (0x2d) sid-length = 0 (0x00) challenge-length = 16 (0x10) cipher-suites = { (0x010080) SSL2/RSA/RC4-128/MD5 (0x030080) SSL2/RSA/RC2CBC128/MD5 (0x0700c0) SSL2/RSA/3DES192EDE-CBC/MD5 (0x060040) SSL2/RSA/DES56-CBC/MD5 (0x020080) SSL2/RSA/RC4-40/MD5 (0x040080) SSL2/RSA/RC2CBC40/MD5 (0x000004) SSL3/RSA/RC4-128/MD5 (0x00feff) ????/????????/?????????/??? (0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA (0x00fefe) ????/????????/?????????/??? (0x000009) SSL3/RSA/DES56-CBC/SHA (0x000064) TLS/RSA_EXPORT1024/RC4-56/SHA (0x000062) TLS/RSA_EXPORT1024/DES56_CBC/SHA (0x000003) SSL3/RSA/RC4-40/MD5 (0x000006) SSL3/RSA/RC2CBC40/MD5 } session-id = { } challenge = { 0xc24f 0xe0e8 0x59e3 0xa769 0x1ca4 0x3ac0 0x894f 0xc1ba } } ] Read EOF on Server socket. [Thu Mar 28 20:26:37 2002] Read EOF on Client socket. [Thu Mar 28 20:26:37 2002] Connection #4 [Thu Mar 28 20:27:06 2002] Connected to strange:3000 --> [ alloclen = 78 bytes (78 bytes of 78) [Thu Mar 28 20:27:06 2002] [ssl2] ClientHelloV2 { version = {0x03, 0x00} cipher-specs-length = 51 (0x33) sid-length = 0 (0x00) challenge-length = 16 (0x10) cipher-suites = { (0x000004) SSL3/RSA/RC4-128/MD5 (0x000005) SSL3/RSA/RC4-128/SHA (0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA (0x010080) SSL2/RSA/RC4-128/MD5 (0x0700c0) SSL2/RSA/3DES192EDE-CBC/MD5 (0x030080) SSL2/RSA/RC2CBC128/MD5 (0x000009) SSL3/RSA/DES56-CBC/SHA (0x060040) SSL2/RSA/DES56-CBC/MD5 (0x000064) TLS/RSA_EXPORT1024/RC4-56/SHA (0x000062) TLS/RSA_EXPORT1024/DES56_CBC/SHA (0x000003) SSL3/RSA/RC4-40/MD5 (0x000006) SSL3/RSA/RC2CBC40/MD5 (0x020080) SSL2/RSA/RC4-40/MD5 (0x040080) SSL2/RSA/RC2CBC40/MD5 (0x000013) SSL3/DHE-DSS/DES192EDE3CBC/SHA (0x000012) SSL3/DHE_DSS/DES56-CBC/SHA (0x000063) TLS/DHE-DSS_EXPORT1024/DES56-CBC/SHA } session-id = { } challenge = { 0x389a 0x5f60 0xdfdd 0xeeb6 0x1228 0xe692 0x4034 0x7f0a } } ] Read EOF on Server socket. [Thu Mar 28 20:27:06 2002] Read EOF on Client socket. [Thu Mar 28 20:27:06 2002] Connection #5 [Thu Mar 28 20:27:06 2002] Connected to strange:3000 --> [ alloclen = 45 bytes (45 bytes of 45) [Thu Mar 28 20:27:06 2002] [ssl2] ClientHelloV2 { version = {0x00, 0x02} cipher-specs-length = 18 (0x12) sid-length = 0 (0x00) challenge-length = 16 (0x10) cipher-suites = { (0x010080) SSL2/RSA/RC4-128/MD5 (0x0700c0) SSL2/RSA/3DES192EDE-CBC/MD5 (0x030080) SSL2/RSA/RC2CBC128/MD5 (0x060040) SSL2/RSA/DES56-CBC/MD5 (0x020080) SSL2/RSA/RC4-40/MD5 (0x040080) SSL2/RSA/RC2CBC40/MD5 } session-id = { } challenge = { 0x4b09 0x2f49 0x3ca6 0x984a 0x8e8c 0x17bc 0x1f5d 0x3c68 } } ] <-- [ alloclen = 5 bytes (5 bytes of 5) [Thu Mar 28 20:27:06 2002] [ssl2] UnknownType 0x00 {...} ] Read EOF on Client socket. [Thu Mar 28 20:27:06 2002] Read EOF on Server socket. [Thu Mar 28 20:27:06 2002] This indicates that the client sent the Clienthelo message. But there is nothing coming from the server. I think what's going on is that when we get to the SSL layer in PR_Recv, we check the socket's properties and find that they are wrong (no CA certs). So we return the error back to the caller, without even reading the clienthelo message or bothering to send an SSL alert to the client telling them that our server is basically hosed .
Reporter | ||
Comment 1•22 years ago
|
||
Assigning to Nelson per our talk.
Assignee: wtc → nelsonb
Priority: -- → P2
Target Milestone: --- → 3.4.1
Reporter | ||
Comment 2•22 years ago
|
||
Reporter | ||
Comment 3•22 years ago
|
||
Reporter | ||
Comment 4•22 years ago
|
||
I have attached cert and key DBs to use with selfserv to reproduce this problem. The test command is as below. (strange)/u/jpierre/nss/34/mozilla/dist/SunOS5.8_DBG.OBJ/bin{72} !68 ./selfserv -n Server-Cert -p 2000 -m -r -r -w enterprise As soon as you connect with a browser, you get the following message on the console : selfserv: HDX PR_Read returned error -12199: No certificate authority is trusted for SSL client authentication. FYI, I tried to use my GAT client to debug this problem on the client side also. What happens on the client is is : error: PR_Send failure - NSPR rc = -5938 , OS rc = 0 End of file There doesn't appear to be any SSL reported there, which is a little odd.
Comment 5•22 years ago
|
||
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Reporter | ||
Updated•22 years ago
|
Target Milestone: 3.5 → 3.6
Assignee | ||
Comment 7•22 years ago
|
||
Two observations and a question about this bug. Obs 1) As reported above, NES logged an error message that said: (SSL_ERROR_NO_TRUSTED_SSL_CLIENT_CA - the CA that signed the client certificate is not trusted locally) I think that text is a mis-interpretation of error SSL_ERROR_NO_TRUSTED_SSL_CLIENT_CA. The text cited above seems to suggest that some client cert was received, but it was not issued by a CA that is trusted to issue client auth certs. That is not the correct meaning of SSL_ERROR_NO_TRUSTED_SSL_CLIENT_CA. SSL_ERROR_NO_TRUSTED_SSL_CLIENT_CA means that THERE is NO CA cert known to the server that is trusted to issue SSL client CA certs, and therefore no client client auth request can possibly succeed, and in fact, we cannot send a properly formed SSL client auth request, because we have no CA name to send in the client auth request. The error message displayed by selfserv is correct in this case. Obs #2) One ssltap output shown above shows a 5 byte response received from the server after a client hello. That is utterly bogus and should never happen. If that is repeatable, a bug should be filed about it. Question: What exact behavior does this bug assert is in error? What behavior would this bug like to see changed? It would be inappropriate to simply complete the SSL handshake without the client auth request, given that the server application has requested that the SSL library perform a client auth request. Is the bug suggesting that the server should send an alert to the client instead of abruptly terminating? If so, What alert would you propose?
Reporter | ||
Comment 8•22 years ago
|
||
1) you are right that the text of the NES error message is in error. I will file a bug on this 2) the failures were repeatable at the time I filed the bug, using the cert & key databases attached I agree that it would be improper for the server to complete the handshake without the client cert. Indeed, I would like to have some sort of alert happen - or at least something more graceful than an abrupt disconnect by the server, which appears to be occurring here. I don't know what alert best fits, I don't have a list. Since there may not be one for this specific case, we'll have to find the closest fit. Is there a way that we could behave as if there were no configured cipher suites on the server side in this case, so that the negotiation of the handshake would fail "cleanly". I realize this isn't exactly equivalent, but since the server requires client auth and yet is unable to do it, this may be the closest logical match.
Assignee | ||
Comment 9•22 years ago
|
||
Mass retarget all my old NSS bugs that were previous targeted at NSS versions that have now been released.
Target Milestone: 3.6 → 3.7
Assignee | ||
Comment 10•22 years ago
|
||
Here a new wrinkle in this bug. The TLS working group has produced a draft that is intended to supersede RFC 2246, the TLS spec. The expired draft may presently be found at http://www.watersprings.org/pub/id/draft-ietf-tls-rfc2246-bis-01.txt It was intended to only clarify some things, not to change the protocol, but ... it changed the definition of CertificateRequest to explicitly allow a CertificateRequest to contain NO names (an empty list) of trusted certificate authorities. Now, the questions are: a) Should we change NSS to allow servers to do this? b) Should the NSS TLS client code allow this? It presently does not. It treats an empty list of CA names as a malformed cert request.
Assignee | ||
Comment 11•22 years ago
|
||
This patch would make libSSL stop treating cert requests that have no CA names as protocol errors. It would also change the default client auth cert selection function to find no matching cert unless the user had chosen one explicitly before the handshake was begun. Existing application-supplied client auth cert selection functions might crash if they were called with a NULL list of CA names, so this change might not be completely backwards binary compatible.
Comment 12•22 years ago
|
||
Moved to target milestone 3.8 because the original NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Assignee | ||
Comment 13•21 years ago
|
||
Remove target milestone of 3.8, since these bugs didn't get into that release.
Target Milestone: 3.8 → ---
Assignee | ||
Updated•19 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
Assignee | ||
Comment 14•18 years ago
|
||
This bug was fixed back in NSS 3.7. See ssl3con.c rev 1.44
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.7
You need to log in
before you can comment on or make changes to this bug.
Description
•