[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
confirmation that debian #480041 is a gnutls problem, and steps to repro
From: |
Daniel Kahn Gillmor |
Subject: |
confirmation that debian #480041 is a gnutls problem, and steps to reproduce |
Date: |
Thu, 20 Nov 2008 19:02:30 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
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
pgpJLTOX8GLHL.pgp
Description: PGP signature
- confirmation that debian #480041 is a gnutls problem, and steps to reproduce,
Daniel Kahn Gillmor <=
- Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Nikos Mavrogiannopoulos, 2008/11/21
- Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Joe Orton, 2008/11/21
- Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Nikos Mavrogiannopoulos, 2008/11/21
- Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Joe Orton, 2008/11/21
- Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Daniel Kahn Gillmor, 2008/11/22
- Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Joe Orton, 2008/11/22
- Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Daniel Kahn Gillmor, 2008/11/22
- Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Joe Orton, 2008/11/22
- Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Nikos Mavrogiannopoulos, 2008/11/23
- Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce, Joe Orton, 2008/11/28