gnutls/renegotiation-with-OpenSSL: Test extension

[mrc0mmand]

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

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

Also, the same issues as in #9 apply to this PR:

• TLS_DHE_DSS_WITH_AES_128_CBC_SHA doesn't work in GNUTLS when TLS 1.2 is disabled
• Unexpected pass because of missing rlGetTestState

[tomato42]

Unexpected pass because of missing rlGetTestState

why it's not added?

[mrc0mmand]

It's part of the #5 PR, so I'd like to avoid creating unnecessary merge conflicts.

[tomato42]

below is a client, not server

[tomato42]

below are settings for client

[mrc0mmand]

Thanks, I'm not sure how it got there...

[tomato42]

first, the # NSS on RHEL-6 does not support SHA-384 PRF comment doesn't apply, as it's a GnuTLS-OpenSSL test case, secondly no AES-GCM ciphersuite should work on RHEL-6 and gnutls doesn't support them.

I'm postponing this PR until #5 is merged

[mrc0mmand]

I've disabled this test on RHEL 6 and applied a 'workaround' for TLS_DHE_DSS_AES_128_CBC_SHA1 which doesn't work with DSA keys > 1024-bits (TLS < 1.2). With these changes this test works on RHEL/CentOS 7.3, but on Fedora 25 and RHEL 7.4 something has changed and OpenSSL <-> GnuTLS (server, client) now for some reason can't complete renegotiation when client certificates are used.

The first handshake is completed successfully, but the renegotiation fails with following error:

GnuTLS (client)

|<5>| REC[0xc00820]: Sent Packet[1] Handshake(22) in epoch 2 and length: 69
|<11>| HWRITE: wrote 1 bytes, 0 bytes left.
|<11>| WRITE FLUSH: 1625 bytes in buffer.
|<11>| WRITE: wrote 1625 bytes, 0 bytes left.
|<3>| ASSERT: gnutls_buffers.c:1138
- Handshake was completed

- Simple Client Mode:

- Server has requested a certificate.
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=localhost', issuer `CN=RSA CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2017-03-13 18:18:23 UTC', expires `2018-03-13 18:18:23 UTC', SHA-1 fingerprint `e5304de8e5613e07b97c1d182b755ec760aced98'
Public Key ID:
c9c690aca4934a1e915b437b7ca081b7e5f2e2a9
Public key's random art:
+--[ RSA 2048]----+
|  .o .           |
| .o.=o..         |
| o.==o+.         |
|  +*oo.+ .       |
| ++ +   S        |
|o..o . .         |
|... o            |
|   o             |
| E.              |
+-----------------+

- Certificate[1] info:
 - subject `CN=RSA CA', issuer `O=Example CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2012-03-13 18:18:23 UTC', expires `2027-03-13 18:18:23 UTC', SHA-1 fingerprint `9640d1f105e8d5bd2f42a4a42f8a7e68131f3ed8'
- Certificate[2] info:
 - subject `O=Example CA', issuer `O=Example CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2012-03-13 18:18:23 UTC', expires `2027-03-13 18:18:23 UTC', SHA-1 fingerprint `206fe79e9f7433ffa1f55af7cfdae3d9dcce4abc'
- Status: The certificate is trusted. 
*** Received alert [10]: Unexpected message
...
*** Fatal error: A TLS fatal alert has been received.
...
*** ReHandshake has failed
GnuTLS error: A TLS fatal alert has been received.

OpenSSL (server)

SSL_accept:before accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client certificate A
SSL3 alert write:fatal:unexpected_message
SSL_accept:error in SSLv3 read client key exchange A
139679461828512:error:1408E0F4:SSL routines:ssl3_get_message:unexpected message:s3_both.c:408:

This happens with all tested ciphersuites.

[mrc0mmand]

Downstream bugs for the issue:
RHEL 7: BZ#1434091
Fedora: BZ#1434420

[tomato42]

RHEL 7: BZ#1434091
Fedora: BZ#1434420

Wow, nice job!

I guess then we need to mark those cases as irrelevant for RHEL-7.4 and earlier (hoping for fix in 7.5). It would be nice to have a fix in Fedora before merging though, but a check for version there is probably also acceptable...

[tomato42]

that's not reliable in my experience, but let's see how it works out...

[tomato42]

given that RHBZ#1434091 won't be fixed any time soon, I wonder if we shouldn't workaround it, merge the workarounded version and either prepare a PR that removes the workaround or just create an issue that reminds us to check if it is fixed in next RHEL