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

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Frantisek Sumsal]

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

Comment 1

[Daiki Ueno [:ueno]]

Attachment: proposed patch

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.

Comment 2

[Huzaifa Sidhpurwala]

Note: This is a remote DoS flaw. we have assigned CVE-2016-9574 to this issue.

Comment 3

[Daiki Ueno [:ueno]]

(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

Comment 4

[Huzaifa Sidhpurwala]

(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 :)

Comment 5

[Hubert Kario]

(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.

Comment 6

[Daiki Ueno [:ueno]]

(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

Comment 7

[Kai Engert (:KaiE:)]

Changing the bug summary, based on comment 1.

Comment 8

[Kai Engert (:KaiE:)]

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

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

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.

Comment 10

[Tim Taubert [:ttaubert] (inactive)]

(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.

Comment 11

[Martin Thomson [:mt:]]

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.

Comment 12

[Martin Thomson [:mt:]]

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.

Comment 13

[Martin Thomson [:mt:]]

I've rebased the patch, and I can take this on:  See https://nss-review.dev.mozaws.net/D176

Comment 14

[Martin Thomson [:mt:]]

https://hg.mozilla.org/projects/nss/rev/81305956dc4a715c38b759b5eaeae52d4506a121