Description of problem: When tstclnt is used with -r 2 option server break the connection. Version-Release number of selected component (if applicable): nss-tools-3.12.6-1.el5_4 nss-3.12.6-1.el5_4 How reproducible: Always. Steps to Reproduce: 1. Create NSS database and import keys (http://barstool.build.redhat.com/~thoger/CVE-2009-3555/) 2. Run selfserv: selfserv -d /nss/database -n www.example.com -p 4433 -v 3. Run ctstclnt: tstclnt -h www.example.com -p 4433 -d /nss/database -r 2 -2 Actual results: Client: subject DN: CN=www.example.com,OU=Web Servers,O=My Company Ltd,ST=Berkshire,C=GB issuer DN: CN=CA.example.com,OU=Certificate Authority,O=My Company Ltd,L=Newbury,ST=Berkshire,C=GB 0 cache hits; 1 cache misses, 0 cache not reusable 0 stateless resumes subject DN: CN=www.example.com,OU=Web Servers,O=My Company Ltd,ST=Berkshire,C=GB issuer DN: CN=CA.example.com,OU=Certificate Authority,O=My Company Ltd,L=Newbury,ST=Berkshire,C=GB 1 cache hits; 1 cache misses, 0 cache not reusable 0 stateless resumes tstclnt: read from socket failed: Cannot communicate securely with peer: no common encryption algorithm(s). Server: selfserv: About to call accept. selfserv: HDX PR_Read returned error -12182: SSL peer has no certificate for the requested DNS name. Expected results: Connected, no errors. Additional info:
This request was evaluated by Red Hat Product Management for inclusion. Since this component is not scheduled to be updated in the current Red Hat Enterprise Linux release, it has been denied. You may re-open your request by asking your support representative to propose it for the next release.
I dug deeper into this, the error occurs on the server side in the same code part as was pointed out in the following upstream bug as breaking renegotiation when SSLv2 hellos are used: https://bugzilla.mozilla.org/show_bug.cgi?id=537356#c74 i.e. error occurs here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.129&mark=6512-6524#6501 as ss->ssl3.cwSpec->srvVirtName is: {type = siBuffer, data = 0x0, len = 0} srvVirtName seems to get lost during the first re-handshake in the following part: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.136&mark=6383-6399#6380 where ss->ssl3.cwSpec->srvVirtName is: {type = siBuffer, data = 0x7fffec015920 "www.example.com", len = 15} but sid->u.ssl3.srvName is: {type = siBuffer, data = 0x0, len = 0} Relevant code was introduced with the addition of server-side SNI handling code: https://bugzilla.mozilla.org/show_bug.cgi?id=360421
Looks like server names are not properly inserted into session cache: https://bugzilla.mozilla.org/show_bug.cgi?id=360421#c44
Tomas, thanks for working with the responsible developer in the upstream bug, I'm assigning this one to you.
Fix for the server name cache initialization issue: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/security/nss/lib/ssl&command=DIFF_FRAMESET&file=sslsnce.c&rev1=1.52&rev2=1.53&root=/cvsroot
Patch for InitCache is now committed upstream. Giving back to component owner in RHEL.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
NSS packages in RHEL-5 and RHEL-4 were rebased to version 3.12.7 as a requirement of the updated Firefox: https://rhn.redhat.com/errata/RHSA-2010-0681.html Upstream version 3.12.7 includes the patch mentioned in comment #5 and is no longer affected by this problem.