Closed Bug 134125 Opened 22 years ago Closed 18 years ago

SSL handshake cut-off with incorrect server configuration

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: julien.pierre, Assigned: nelson)

Details

Attachments

(3 files)

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 .
Assigning to Nelson per our talk.
Assignee: wtc → nelsonb
Priority: -- → P2
Target Milestone: --- → 3.4.1
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.
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Set target milestone to NSS 3.5.
Target Milestone: 3.4.1 → 3.5
Target Milestone: 3.5 → 3.6
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?  
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.
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
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.  
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.
Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Remove target milestone of 3.8, since these bugs didn't get into that release.
Target Milestone: 3.8 → ---
QA Contact: bishakhabanerjee → jason.m.reid
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.

Attachment

General

Creator:
Created:
Updated:
Size: