Closed Bug 1320695 Opened 3 years ago Closed 3 years ago

Enable use of session ticket keys if server has no RSA key pair

Categories

(NSS :: Libraries, defect)

3.27
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: frantisek, Assigned: mt)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160729111717

Steps to reproduce:

# NSS_CIPHER="C00A"
# OPENSSL_CIPHER="ECDHE-ECDSA-AES256-SHA"
# ulimit -c unlimited
# openssl ecparam -genkey -name prime256v1 -out ec.key
# openssl req -new -x509 -key ec.key -out ec-cert.pem -days 3650 -subj "/CN=localhost" -nodes
# openssl pkcs12 -name ec -export -inkey ec.key -out ec.p12 -in ec-cert.pem -passout "pass:"
# mkdir nssdb
# certutil -N --empty-password -d sql:./nssdb
# certutil -A -d sql:./nssdb/ -n ec -t ',,' -a -i ec-cert.pem
# pk12util -i ec.p12 -d sql:./nssdb -W ''
# /usr/lib64/nss/unsupported-tools/selfserv -d sql:./nssdb/ -p 4433 -V tls1.0: -H 1 -e ec -c :$NSS_CIPHER -u &>server.log &
# sleep 3
# openssl s_client -connect localhost:4433 -CAfile ec-cert.pem -cipher $OPENSSL_CIPHER -sess_out sess.pem 2>>client_err.log >>client_out.log < /dev/null
# openssl s_client -connect localhost:4433 -CAfile ec-cert.pem -cipher $OPENSSL_CIPHER -sess_out sess.pem 2>>client_err.log >>client_out.log < /dev/null


Actual results:

# cat client_err.log 
depth=0 CN = localhost
verify return:1
139942008751992:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
depth=0 CN = localhost
verify return:1
139640958179192:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

# cat server.log 
selfserv: HDX PR_Read returned error 0:
Success
selfserv: HDX PR_Read returned error -5925:
The one-time function was previously called and failed. Its error code is no longer available


Expected results:

Handshake should not fail and selfserv should be able to handle following connections.

Example using SessionID:
# NSS_CIPHER="C00A"
# OPENSSL_CIPHER="ECDHE-ECDSA-AES256-SHA"
# ulimit -c unlimited
# openssl ecparam -genkey -name prime256v1 -out ec.key
# openssl req -new -x509 -key ec.key -out ec-cert.pem -days 3650 -subj "/CN=localhost" -nodes
# openssl pkcs12 -name ec -export -inkey ec.key -out ec.p12 -in ec-cert.pem -passout "pass:"
# mkdir nssdb
# certutil -N --empty-password -d sql:./nssdb
# certutil -A -d sql:./nssdb/ -n ec -t ',,' -a -i ec-cert.pem
# pk12util -i ec.p12 -d sql:./nssdb -W ''
# /usr/lib64/nss/unsupported-tools/selfserv -d sql:./nssdb/ -p 4433 -V tls1.0: -H 1 -e ec -c :$NSS_CIPHER &>server.log &
# sleep 3
# openssl s_client -connect localhost:4433 -CAfile ec-cert.pem -cipher $OPENSSL_CIPHER -sess_out sess.pem -no_ticket 2>>client_err.log >>client_out.log < /dev/null
# openssl s_client -connect localhost:4433 -CAfile ec-cert.pem -cipher $OPENSSL_CIPHER -sess_out sess.pem -no_ticket 2>>client_err.log >>client_out.log < /dev/null

## RESULTS:
# cat server.log

# cat client_err.log 
depth=0 CN = localhost
verify return:1
DONE
depth=0 CN = localhost
verify return:1
DONE
Attached patch proposed patchSplinter Review
This happens because of missing RSA keypair on the server side, which is used to wrap and cache the generated session ticket keys.  IMO, in that case NSS could disable caching and continue the handshake with the generated keys.
Attachment #8817168 - Flags: review?(kaie)
Note: This is a remote DoS flaw. we have assigned CVE-2016-9574 to this issue.
(In reply to Huzaifa Sidhpurwala from comment #2)
> Note: This is a remote DoS flaw. we have assigned CVE-2016-9574 to this
> issue.

I'm not sure if this is really a remote DoS flaw.  Even though selfserv prints a misleading message ("The one-time function was previously called and failed."), the behavior that the client can observe is identical between the first and second calls: the connection is terminated because the session ticket extension doesn't work with the given server setting.

I thought that the CVE was for the downstream bug for NSS 3.21 series, which leads to a crash with the same reproducing steps:
https://bugzilla.redhat.com/show_bug.cgi?id=1397482
(In reply to Daiki Ueno [:ueno] from comment #3)
> (In reply to Huzaifa Sidhpurwala from comment #2)
> > Note: This is a remote DoS flaw. we have assigned CVE-2016-9574 to this
> > issue.
> 
> I'm not sure if this is really a remote DoS flaw.  Even though selfserv
> prints a misleading message ("The one-time function was previously called
> and failed."), the behavior that the client can observe is identical between
> the first and second calls: the connection is terminated because the session
> ticket extension doesn't work with the given server setting.
> 
> I thought that the CVE was for the downstream bug for NSS 3.21 series, which
> leads to a crash with the same reproducing steps:
> https://bugzilla.redhat.com/show_bug.cgi?id=1397482

You are right, please scratch this comment. The CVE is for our downstream nss version :)
(In reply to Daiki Ueno [:ueno] from comment #3)
> (In reply to Huzaifa Sidhpurwala from comment #2)
> > Note: This is a remote DoS flaw. we have assigned CVE-2016-9574 to this
> > issue.
> 
> I'm not sure if this is really a remote DoS flaw.  Even though selfserv
> prints a misleading message ("The one-time function was previously called
> and failed."), the behavior that the client can observe is identical between
> the first and second calls: the connection is terminated because the session
> ticket extension doesn't work with the given server setting.

My understanding of Frantisek is that if on the second connection client does not advertise session ticket extension, the connection will still fail.

Frantisek, can you confirm?
 
> I thought that the CVE was for the downstream bug for NSS 3.21 series, which
> leads to a crash with the same reproducing steps:
> https://bugzilla.redhat.com/show_bug.cgi?id=1397482

But yes, that does make it a different issue.
(In reply to Hubert Kario from comment #5)
> My understanding of Frantisek is that if on the second connection client
> does not advertise session ticket extension, the connection will still fail.

It is not the case.  From the implementation, it is unlikely that the first connection causes such side effect, because a different code path is taken depending on whether session ticket extension is advertised.

I have confirmed that, if I run s_client with -no_ticket option for the second time, the connection succeeds:

# First time
$ openssl s_client -connect localhost:4433 -CAfile ec-cert.pem -cipher ECDHE-ECDSA-AES256-SHA -sess_out sess.pem >/dev/null </dev/null         
depth=0 CN = localhost
verify return:1
140625545222008:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
zsh: exit 1

# Second time
$ openssl s_client -connect localhost:4433 -CAfile ec-cert.pem -cipher ECDHE-ECDSA-AES256-SHA -sess_out sess.pem -no_ticket >/dev/null </dev/null
depth=0 CN = localhost
verify return:1
DONE
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changing the bug summary, based on comment 1.
Summary: Using SessionTicket extension along with any ECDHE-ECDSA ciphersuite renders selfserv unusable → Disable caching of session ticket keys, if server runs with EC key pair, but without RSA key pair
Comment on attachment 8817168 [details] [diff] [review]
proposed patch

I think Daiki's suggestion is to always disable caching of session tickets, if no RSA server key pair is available.

I don't know well enough how session tickets work, so I'm adding Martin and Tim to CC, wo I noticed are currently working on other changes related to that code.

I've submitted a try build with the suggested patch:
https://treeherder.mozilla.org/#/jobs?repo=nss-try&revision=c38cc8f6243979eceb80715652187284c1b13cb3
Attachment #8817168 - Flags: review?(kaie) → review?(ttaubert)
Comment on attachment 8817168 [details] [diff] [review]
proposed patch

Review of attachment 8817168 [details] [diff] [review]:
-----------------------------------------------------------------

Configuring only an EC cert should not break session tickets, it should simply use the EC key pair to wrap the symkey, no? Maybe this was a bug, maybe it's fixed by Martin's patch.
Attachment #8817168 - Flags: review?(ttaubert)
(In reply to Tim Taubert [:ttaubert] from comment #9)
> Configuring only an EC cert should not break session tickets, it should
> simply use the EC key pair to wrap the symkey, no? Maybe this was a bug,
> maybe it's fixed by Martin's patch.

Ni'ing Marting for his opinion.
Flags: needinfo?(martin.thomson)
Yes, the patch for Bug 1325035 will make it possible to operate with only an ECDSA certificate.  It will not actively block use of tickets; which we should probably also do.
Flags: needinfo?(martin.thomson)
To iterate on this: we don't have the means to use an EC key for wrapping keys.  We might want to add that, but we shouldn't block on that.  Requiring RSA for key wrapping isn't terrible.

I would approve the patch here, it's fine, but it will need rebasing on top of the changes for bug 1325035.
I've rebased the patch, and I can take this on:  See https://nss-review.dev.mozaws.net/D176
Assignee: nobody → martin.thomson
Summary: Disable caching of session ticket keys, if server runs with EC key pair, but without RSA key pair → Enable use of session ticket keys if server has no RSA key pair
https://hg.mozilla.org/projects/nss/rev/81305956dc4a715c38b759b5eaeae52d4506a121
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.30
You need to log in before you can comment on or make changes to this bug.