Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

mrc0mmand
Copy link
Member

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
Copy link
Member

Unexpected pass because of missing rlGetTestState

why it's not added?

@mrc0mmand
Copy link
Member Author

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

gnutls_pid=$!
rlRun "rlWaitForSocket -p $gnutls_pid 4433"

# OpenSSL server setup
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

below is a client, not server

gnutls_pid=$!
rlRun "rlWaitForSocket -p $gnutls_pid 4433"

# OpenSSL server setup
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

below are settings for client

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mrc0mmand mrc0mmand force-pushed the gnutls-renego-with-openssl branch from 67891df to b2d4123 Compare February 1, 2017 18:58
@tomato42
Copy link
Member

tomato42 commented Feb 9, 2017

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 mrc0mmand force-pushed the gnutls-renego-with-openssl branch from b2d4123 to c377062 Compare March 11, 2017 14:53
@mrc0mmand mrc0mmand added the WIP label Mar 12, 2017
mrc0mmand and others added 4 commits March 13, 2017 17:55
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 mrc0mmand force-pushed the gnutls-renego-with-openssl branch from c377062 to 862d098 Compare March 13, 2017 17:14
@mrc0mmand
Copy link
Member Author

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
Copy link
Member Author

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

@tomato42
Copy link
Member

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

if [[ $proto == "tls1_1" ]]; then
options+=(-tls1_1)
fi
rlRun -s "(sleep 0.5; echo R; sleep 0.5; echo Q) | ${options[*]}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@tomato42
Copy link
Member

tomato42 commented May 5, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants