confirmation that debian #480041 is a gnutls problem, and steps to reproduce

[Daniel Kahn Gillmor]

OK, i'm now sure that debian #480041 is a gnutls problem, and not just
due to something wacky in libneon (though there may be libneon bits as
well).  Here's a way to duplicate the problem without using libneon.

Add the following line to /etc/hosts:

127.0.0.1 fubar.example.org

Generate an X.509 self-signed key/cert pair (or use an existing
key/cert pair -- it doesn't have to be self-signed):

  mkdir /tmp/testing && cd /tmp/testing
  openssl req -newkey rsa:1024 -keyout key.pem -nodes -subj '/CN=fubar.example.org' -x509 > cert.pem

Configure an apache2 virtualhost like this:

--------------------------------
<VirtualHost 127.0.0.1:443>
ServerName fubar.example.org
DocumentRoot /var/www/

SSLEngine on
SSLCertificateFile /tmp/testing/cert.pem
SSLCertificateKeyFile /tmp/testing/key.pem
SSLCACertificateFile /tmp/testing/cert.pem

<Location "/">
 SSLVerifyClient optional
</Location>

</VirtualHost>
--------------------------------

Then run the following command to simulate a web connection:

HTTP_QUERY='GET / http/1.1\r\nHost: fubar.example.org\r\n\r\n'
(sleep 3 && echo -e "$HTTP_QUERY" && sleep 3) | gnutls-cli fubar.example.org

The tail of the output looks like this for me:

---------------------------------
  ...
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

*** Non fatal error: Rehandshake was requested by the peer.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [10]: Unexpected message
*** Server has terminated the connection abnormally.
---------------------------------

The apache2 error log looks like:

[Thu Nov 20 18:55:30 2008] [error] Re-negotiation handshake failed: Not accepted by client!?

Interestingly, if i don't wrap the "SSLVerifyClient optional" line in
the <Location /> tag, the connection goes through cleanly.  I think
this means that the problem appears when the handshake is
re-negotiated after some traffic has already been sent.

Hope this is helpful in debugging the problem.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20081120/7cfcc2bf/attachment.pgp>