gnutls/renegotiation-with-NSS: Test extension by mrc0mmand · Pull Request #9 · redhat-qe-security/interoperability

mrc0mmand · 2017-01-29T22:49:52Z

This PR extends the gnutls/renegotiation-with-NSS test with following:

Various combinations of KEX, MAC and PRF algorithms
Renegotiation with client authentication

Found issue:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA does not work in any case when TLS 1.2 is disabled (other DHE-DSS ciphersuites work as intened).

Without TLS 1.2:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: GNUTLS <-> NSS [TLS_DHE_DSS_WITH_AES_128_CBC_SHA, tls1_1]
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

...
:: [   PASS   ] :: Command 'gnutls-serv --x509keyfile dsa-server/key.pem --x509certfile <(cat ${C_CERT[$idx]} ${C_SUBCA[$idx]}) --http --port 4433 --priority NORMAL:+VERS-TLS1.2 >server.log 2>server.err &' (Expected 0, got 0)
...
:: [  BEGIN   ] :: Running './nss-client.expect /usr/lib64/nss/unsupported-tools/tstclnt -r 1 -d sql:nss-ca-db -h localhost -p 4433 -V tls1.0:tls1.1'
spawn /bin/sh -c /usr/lib64/nss/unsupported-tools/tstclnt -r 1 -d sql:nss-ca-db -h localhost -p 4433 -V tls1.0:tls1.1
tstclnt: read from socket failed: SSL_ERROR_INTERNAL_ERROR_ALERT: Peer reports it experienced an internal error.
:: [   FAIL   ] :: Command './nss-client.expect /usr/lib64/nss/unsupported-tools/tstclnt -r 1 -d sql:nss-ca-db -h localhost -p 4433 -V tls1.0:tls1.1' (Expected 0, got 1)
...
:: [  BEGIN   ] :: Running 'cat server.log'
Set static Diffie-Hellman parameters, consider --dhparams.

* Accepted connection from IPv6 ::1 port 59946 on Sun Jan 29 17:14:36 2017
Error: Public key signing has failed.
:: [   PASS   ] :: Command 'cat server.log' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'cat server.err'
HTTP Server listening on IPv4 0.0.0.0 port 4433...done
HTTP Server listening on IPv6 :: port 4433...done
Error in handshake
Exiting via signal 15
:: [   PASS   ] :: Command 'cat server.err' (Expected 0, got 0)


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: NSS <-> GNUTLS [TLS_DHE_DSS_WITH_AES_128_CBC_SHA, tls1_1]
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

...
:: [   PASS   ] :: Command '/usr/lib64/nss/unsupported-tools/selfserv -d sql:./nssdb/ -p 4433 -V tls1.0: -H 1 -c :0032 -S dsa-server >server.log 2>server.err &' (Expected 0, got 0)
...
:: [  BEGIN   ] :: Running 'gnutls-cli --rehandshake --x509cafile ca/cert.pem --port 4433 --priority NORMAL:-VERS-TLS1.2 localhost </dev/null'
*** Fatal error: Public key signature verification has failed.
*** Handshake has failed
GnuTLS error: Public key signature verification has failed.
Processed 1 CA certificate(s).
Resolving 'localhost'...
Connecting to '::1:4433'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=localhost', issuer `CN=DSA CA', DSA key 2048 bits, signed using DSA-SHA256, activated `2017-01-29 22:13:13 UTC', expires `2018-01-29 22:13:13 UTC', SHA-1 fingerprint `80802f298b059f8e6e6e4be1ccc6a21ede6356c5'
Public Key ID:
327e98054f8f82d35fe73cf208bafe2f151cea3c
Public key's random art:
+--[ DSA 2048]----+
|                 |
|          .      |
|      . .o .     |
|     o +.oo      |
|    o =oS o..    |
|     o OE..+     |
|      + +o. +    |
|       o.. + .   |
|     .+o.oo .    |
+-----------------+

- Certificate[1] info:
 - subject `CN=DSA CA', issuer `O=Example CA', DSA key 2048 bits, signed using RSA-SHA256, activated `2012-01-29 22:13:12 UTC', expires `2027-01-29 22:13:12 UTC', SHA-1 fingerprint `7b0879ccc9d6a8b981c6358efe1842bf45b2894a'
- Certificate[2] info:
 - subject `O=Example CA', issuer `O=Example CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2012-01-29 22:13:12 UTC', expires `2027-01-29 22:13:12 UTC', SHA-1 fingerprint `718d96a8c8d203d263186fe332f9a28c1b2db1c5'
- Status: The certificate is trusted. 
:: [   FAIL   ] :: Command 'gnutls-cli --rehandshake --x509cafile ca/cert.pem --port 4433 --priority NORMAL:-VERS-TLS1.2 localhost </dev/null' (Expected 0, got 1)
...
:: [  BEGIN   ] :: Running 'cat server.err'
selfserv: HDX PR_Read returned error -12188:
Peer reports it experienced an internal error.
:: [   PASS   ] :: Command 'cat server.err' (Expected 0, got 0)
...

With TLS 1.2:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: GNUTLS <-> NSS [TLS_DHE_DSS_WITH_AES_128_CBC_SHA, tls1_2]
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

...
:: [   PASS   ] :: Command 'gnutls-serv --x509keyfile dsa-server/key.pem --x509certfile <(cat ${C_CERT[$idx]} ${C_SUBCA[$idx]}) --http --port 4433 --priority NORMAL:+VERS-TLS1.2 >server.log 2>server.err &' (Expected 0, got 0)
...
:: [  BEGIN   ] :: Running './nss-client.expect /usr/lib64/nss/unsupported-tools/tstclnt -r 1 -d sql:nss-ca-db -h localhost -p 4433 -V tls1.0:'
spawn /bin/sh -c /usr/lib64/nss/unsupported-tools/tstclnt -r 1 -d sql:nss-ca-db -h localhost -p 4433 -V tls1.0:
subject DN: CN=localhost
issuer  DN: CN=DSA CA
0 cache hits; 1 cache misses, 0 cache not reusable
0 stateless resumes
Received 0 Cert Status items (OCSP stapled data)
subject DN: CN=localhost
issuer  DN: CN=DSA CA
0 cache hits; 2 cache misses, 0 cache not reusable
0 stateless resumes
Received 0 Cert Status items (OCSP stapled data)
GET / HTTP/1.0

HTTP/1.0 200 OK
Content-type: text/html
...
<TABLE border=1><TR><TD>Protocol version:</TD><TD>TLS1.2</TD></TR>
<TR><TD>Certificate Type:</TD><TD>X.509</TD></TR>
<TR><TD>Key Exchange:</TD><TD>DHE-DSS</TD></TR>
<TR><TD>Compression</TD><TD>NULL</TD></TR>
<TR><TD>Cipher</TD><TD>AES-256-CBC</TD></TR>
<TR><TD>MAC</TD><TD>SHA1</TD></TR>
<TR><TD>Ciphersuite</TD><TD>DHE_DSS_AES_256_CBC_SHA1</TD></TR></p></TABLE>
<hr><P>Your HTTP header was:<PRE></PRE></P>
</BODY></HTML>

:: [   PASS   ] :: Command './nss-client.expect /usr/lib64/nss/unsupported-tools/tstclnt -r 1 -d sql:nss-ca-db -h localhost -p 4433 -V tls1.0:' (Expected 0, got 0)
:: [   PASS   ] :: File '/var/tmp/tmp.8cDVFV4hzp' should contain 'HTTP/1.0 200 OK' 
<TABLE border=1><TR><TD>Protocol version:</TD><TD>TLS1.2</TD></TR>
:: [   PASS   ] :: File '/var/tmp/tmp.8cDVFV4hzp' should contain 'TLS1.2' 
...
:: [  BEGIN   ] :: Running 'cat server.log'
Set static Diffie-Hellman parameters, consider --dhparams.
...
- Version: TLS1.2
- Key Exchange: DHE-DSS
- Server Signature: DSA-SHA256
- Cipher: AES-256-CBC
- MAC: SHA1
- Compression: NULL
- Options: safe renegotiation,
- Channel binding 'tls-unique': 44865d47af7ed0ce53151b98
:: [   PASS   ] :: Command 'cat server.log' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'cat server.err'
HTTP Server listening on IPv4 0.0.0.0 port 4433...done
HTTP Server listening on IPv6 :: port 4433...done
No certificates found!
*** Received hello message
Exiting via signal 15
:: [   PASS   ] :: Command 'cat server.err' (Expected 0, got 0)

I said above, this issue happens in all four cases - NSS <-> GNUTLS and GNUTLS <-> NSS (both with and without client authentication). First I thought that it's related to BZ#1397365, but this is a renegotiation and moreover it works when TLS 1.2 is enabled.

@tomato42, @ep69 any ideas?

Edit: As this branch is based on the master, some tests (including this one) don't have the rlGetTestState command and their end. This causes unexpected passes in Travis.

Edit 2: This issue is definitely in GNUTLS as I encountered it just a few seconds ago while working on gnutls/renegotiation-with-OpenSSL test.

tomato42 · 2017-01-30T16:28:03Z

Edit 2: This issue is definitely in GNUTLS as I encountered it just a few seconds ago while working on gnutls/renegotiation-with-OpenSSL test.

then please update the bug and file a bug upstream

tomato42 · 2017-01-30T16:40:07Z

Edit: As this branch is based on the master, some tests (including this one) don't have the rlGetTestState command and their end. This causes unexpected passes in Travis.

so in what order do we need to merge the PRs to get truthful results from Travis?

mrc0mmand · 2017-01-30T16:49:31Z

#5 and #8 must be merged to provide relevant results. There is unfortunately a one conflict in .travis.yml but thankfully it's nothing complicated.

mrc0mmand · 2017-02-01T09:43:42Z

Downstream bug for RHEL 7 can be found here: BZ#1418018. If it gets confirmed, I'll file it upstream (and for other affected downstream versions) as well.

mrc0mmand · 2017-02-25T17:16:57Z

As the BZ#1418018 is not a bug, 6c4b06f contains a fix for this issue. TLS_DHE_DSS_WITH_AES_128_CBC_SHA now uses 1024-bit DSA keys in all cases. No other changes were necessary, as this ciphersuite is the only non-TLSv1.2 one, which uses DSA keys, in this test. One possible improvement would be using a 1024-bit keys only when testing TLSv1.1 and lower instead of using it for all TLS versions.

If this fix is sufficient, I'll add it to other GnuTLS tests, which are affected by this issue.

tomato42 · 2017-03-22T16:06:09Z

One possible improvement would be using a 1024-bit keys only when testing TLSv1.1 and lower instead of using it for all TLS versions.

either option is fine, I'd say

mrc0mmand · 2017-03-22T17:53:48Z

While trying to reproduce the GnuTLS bug from #10 I noticed a strange behavior of NSS' selfserv utility. When -rr is used, which should mean 'request and require a client certificate on initial handshake', the CERTIFICATE REQUEST message is sent on both handshakes:

## Epoch #1
...
|<4>| HSK[0x21f4820]: CERTIFICATE REQUEST (13) was received. Length 63[67], frag offset 0, frag length: 63, sequence: 0
|<3>| ASSERT: gnutls_buffers.c:1375
|<4>| EXT[0x21f4820]: rcvd signature algo (4.3) ECDSA-SHA256
|<4>| EXT[0x21f4820]: rcvd signature algo (5.3) ECDSA-SHA384
|<4>| EXT[0x21f4820]: rcvd signature algo (6.3) ECDSA-SHA512
|<4>| EXT[0x21f4820]: rcvd signature algo (2.3) ECDSA-SHA1
|<4>| EXT[0x21f4820]: rcvd signature algo (8.4) (null)
|<4>| EXT[0x21f4820]: rcvd signature algo (8.5) (null)
|<4>| EXT[0x21f4820]: rcvd signature algo (8.6) (null)
|<4>| EXT[0x21f4820]: rcvd signature algo (4.1) RSA-SHA256
|<4>| EXT[0x21f4820]: rcvd signature algo (5.1) RSA-SHA384
|<4>| EXT[0x21f4820]: rcvd signature algo (6.1) RSA-SHA512
|<4>| EXT[0x21f4820]: rcvd signature algo (2.1) RSA-SHA1
|<4>| EXT[0x21f4820]: rcvd signature algo (4.2) DSA-SHA256
|<4>| EXT[0x21f4820]: rcvd signature algo (5.2) DSA-SHA384
|<4>| EXT[0x21f4820]: rcvd signature algo (6.2) DSA-SHA512
|<4>| EXT[0x21f4820]: rcvd signature algo (2.2) DSA-SHA1
|<3>| ASSERT: gnutls_buffers.c:1138
|<4>| HSK[0x21f4820]: SERVER HELLO DONE (14) was received. Length 0[0], frag offset 0, frag length: 1, sequence: 0
...
## Epoch #2
...
|<4>| HSK[0x21f4820]: CERTIFICATE REQUEST (13) was received. Length 63[67], frag offset 0, frag length: 63, sequence: 0
|<3>| ASSERT: gnutls_buffers.c:1375
|<4>| EXT[0x21f4820]: rcvd signature algo (4.3) ECDSA-SHA256
|<4>| EXT[0x21f4820]: rcvd signature algo (5.3) ECDSA-SHA384
|<4>| EXT[0x21f4820]: rcvd signature algo (6.3) ECDSA-SHA512
|<4>| EXT[0x21f4820]: rcvd signature algo (2.3) ECDSA-SHA1
|<4>| EXT[0x21f4820]: rcvd signature algo (8.4) (null)
|<4>| EXT[0x21f4820]: rcvd signature algo (8.5) (null)
|<4>| EXT[0x21f4820]: rcvd signature algo (8.6) (null)
|<4>| EXT[0x21f4820]: rcvd signature algo (4.1) RSA-SHA256
|<4>| EXT[0x21f4820]: rcvd signature algo (5.1) RSA-SHA384
|<4>| EXT[0x21f4820]: rcvd signature algo (6.1) RSA-SHA512
|<4>| EXT[0x21f4820]: rcvd signature algo (2.1) RSA-SHA1
|<4>| EXT[0x21f4820]: rcvd signature algo (4.2) DSA-SHA256
|<4>| EXT[0x21f4820]: rcvd signature algo (5.2) DSA-SHA384
|<4>| EXT[0x21f4820]: rcvd signature algo (6.2) DSA-SHA512
|<4>| EXT[0x21f4820]: rcvd signature algo (2.2) DSA-SHA1
|<3>| ASSERT: gnutls_buffers.c:1138
|<4>| HSK[0x21f4820]: SERVER HELLO DONE (14) was received. Length 0[0], frag offset 0, frag length: 1, sequence: 0

But when -rrrr is used, which should request and require certificate on second handshake, selfserv doesn't send CERTIFICATE REQUEST on any handshake:

## Epoch #1
...
|<4>| HSK[0x20ac820]: CERTIFICATE (11) was received. Length 2453[2457], frag offset 0, frag length: 2453, sequence: 0
|<3>| ASSERT: gnutls_buffers.c:1375
...
|<3>| ASSERT: gnutls_buffers.c:1138
|<4>| HSK[0x20ac820]: SERVER HELLO DONE (14) was received. Length 0[0], frag offset 0, frag length: 1, sequence: 0
...
## Epoch #2
...
|<4>| HSK[0x20ac820]: CERTIFICATE (11) was received. Length 2453[2457], frag offset 0, frag length: 2453, sequence: 0
|<3>| ASSERT: gnutls_buffers.c:1375
...|<3>| ASSERT: gnutls_buffers.c:1138
|<4>| HSK[0x20ac820]: SERVER HELLO DONE (14) was received. Length 0[0], frag offset 0, frag length: 1, sequence: 0

Just out of curiosity, I also tried -r and -rrr which requests (but not requires) certificates on initial or second handshake respectively, but with the same results as above (-r requests a client cert on both handshakes, -rrr doesn't request client certs at all).

This behavior can be reproduced on RHEL 7.3, 7.4 and Fedora 25.

@tomato42, is this an expected behavior and I'm just missing something, or it's a real issue?

GnuTLS on RHEL 6 has minimal TLS 1.2 implementation and most of the ciphersuites/features used in this test don't work there.

tomato42

Looks good.
Thanks!

mrc0mmand · 2017-03-23T13:35:30Z

Thanks for the review. Just to clear things up - is the behavior described in my previous comment expected?

tomato42 · 2017-03-24T11:44:39Z

Just to clear things up - is the behavior described in my previous comment expected?

those are renegotiation or resumption handshakes? because I'd say it's a bug only for the renegotiation case...

mrc0mmand · 2017-03-26T16:16:00Z

Yes, it's happening only on renegotiation. I'll file a downstream bug to confirm if it's a real issue.

mrc0mmand mentioned this pull request Jan 30, 2017

gnutls/renegotiation-with-OpenSSL: Test extension #10

Open

mrc0mmand mentioned this pull request Jan 30, 2017

Beakerlib fix #8

Merged

mrc0mmand added a commit that referenced this pull request Mar 8, 2017

Temporarily disable this test until #9 is merged

339adc9

mrc0mmand force-pushed the gnutls-renego-with-nss branch from 6c4b06f to 424b6a7 Compare March 11, 2017 14:55

This was referenced Mar 11, 2017

gnutls/resumption-with-OpenSSL: Test extension #13

Open

gnutls/resumption-with-NSS: Test extension #14

Open

mrc0mmand and others added 2 commits March 12, 2017 17:45

renegotiation-with-NSS: Test extension

1f45876

Dump server logs on phase fail

b105adc

mrc0mmand force-pushed the gnutls-renego-with-nss branch from 424b6a7 to a69995c Compare March 12, 2017 16:45

mrc0mmand added the WIP label Mar 12, 2017

Use 1024-bit DSA keys with TLS_DHE_DSS_AES_128_CBC_SHA1

a077b35

mrc0mmand added 2 commits March 22, 2017 19:36

Explicitly enable DHE-DSS

29c01ec

Disable this test on RHEL/CentOS 6

4de6777

GnuTLS on RHEL 6 has minimal TLS 1.2 implementation and most of the ciphersuites/features used in this test don't work there.

mrc0mmand force-pushed the gnutls-renego-with-nss branch from a69995c to 4de6777 Compare March 22, 2017 18:38

mrc0mmand added the review-ready label Mar 22, 2017

tomato42 approved these changes Mar 23, 2017

View reviewed changes

tomato42 merged commit e8a74d2 into master Mar 23, 2017

mrc0mmand deleted the gnutls-renego-with-nss branch May 8, 2017 14:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gnutls/renegotiation-with-NSS: Test extension#9

gnutls/renegotiation-with-NSS: Test extension#9
tomato42 merged 5 commits intomasterfrom
gnutls-renego-with-nss

mrc0mmand commented Jan 29, 2017 •

edited

Loading

Uh oh!

tomato42 commented Jan 30, 2017

Uh oh!

tomato42 commented Jan 30, 2017

Uh oh!

mrc0mmand commented Jan 30, 2017

Uh oh!

mrc0mmand commented Feb 1, 2017

Uh oh!

mrc0mmand commented Feb 25, 2017 •

edited

Loading

Uh oh!

tomato42 commented Mar 22, 2017

Uh oh!

mrc0mmand commented Mar 22, 2017

Uh oh!

tomato42 left a comment

Uh oh!

mrc0mmand commented Mar 23, 2017

Uh oh!

tomato42 commented Mar 24, 2017

Uh oh!

mrc0mmand commented Mar 26, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mrc0mmand commented Jan 29, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tomato42 commented Jan 30, 2017

Uh oh!

tomato42 commented Jan 30, 2017

Uh oh!

mrc0mmand commented Jan 30, 2017

Uh oh!

mrc0mmand commented Feb 1, 2017

Uh oh!

mrc0mmand commented Feb 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tomato42 commented Mar 22, 2017

Uh oh!

mrc0mmand commented Mar 22, 2017

Uh oh!

tomato42 left a comment

Choose a reason for hiding this comment

Uh oh!

mrc0mmand commented Mar 23, 2017

Uh oh!

tomato42 commented Mar 24, 2017

Uh oh!

mrc0mmand commented Mar 26, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mrc0mmand commented Jan 29, 2017 •

edited

Loading

mrc0mmand commented Feb 25, 2017 •

edited

Loading