[gnutls-dev] Re: Bug#396867: gnutls-bin: does not seem to properly handle rehandshake request
jas at extundo.com
Sun Nov 5 10:00:12 CET 2006
Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> this is http://bugs.debian.org/396867 submitted by Marc Haber.
> cu andreas
> On 2006-11-03 Marc Haber <mh+debian-bugs at zugschlus.de> wrote:
>> Package: gnutls-bin
>> Version: 1.4.4-2
>> Severity: normal
>> I have one internal https server (running IIS on Windows Server 2003)
>> which seems to request a rehandshake after the http request was
>> transmitted. This seems to badly confuse gnutls-cli:
>> | $ gnutls-cli -p 443 a.b.c.d
>> | Resolving 'a.b.c.d'...
>> | Connecting to 'a.b.c.d:443'...
>> | - Certificate type: X.509
>> | - Got a certificate list of 1 certificates.
>> | - Certificate info:
>> | # The hostname in the certificate does NOT match 'a.b.c.d'.
>> | # valid since: Wed Jul 20 12:23:32 CEST 2005
>> | # expires at: Wed Sep 9 12:34:44 CEST 2009
>> | # fingerprint: 6B:22:44:F3:22:CC:BA:36:64:70:0F:C0:D5:CD:87:9E
>> | # Subject's DN: C=DE,ST=BW,L=City,O=Site,OU=Site,CN=some.invalid.host.name.example
>> | # Issuer's DN: CN=unqualifiedname
>> | - Peer's certificate issuer is unknown
>> | - Peer's certificate is NOT trusted
>> | - Version: TLS 1.0
>> | - Key Exchange: RSA
>> | - Cipher: ARCFOUR 128
>> | - MAC: MD5
>> | - Compression: NULL
>> | - Handshake was completed
>> | - Simple Client Mode:
>> | GET / HTTP/1.0
>> | *** Non fatal error: Rehandshake was requested by the peer.
>> After this, nothing happens any more. Ctrl-C out.
There is some code in cli.c:
check_rehandshake (socket_st *socket, int ret)
if (socket->secure && ret == GNUTLS_E_REHANDSHAKE)
/* There is a race condition here. If application
* data is sent after the rehandshake request,
* the server thinks we ignored his request.
* This is a bad design of this client.
printf ("*** Received rehandshake request\n");
/* gnutls_alert_send( session, GNUTLS_AL_WARNING, GNUTLS_A_NO_RENEGOTIATION); */
ret = do_handshake (socket);
So it seems there may be some sub-optimal cli.c design here.
It would be much easier to fix this if there were a public server that
exhibits this problem, so I can debug exactly what gnutls-cli is
doing. Any chance of finding one?
Btw, I assume this problem confuses gnutls-cli, and not the actual
libgnutls, right? In other words, you didn't find this bug because
some application that uses libgnutls failed, did you?
>> Trying the same with openssl s_client -connect a.b.c.d:443 works fine.
>> With other servers (for example running apache on Linux), gnutls-cli
>> works fine as well.
>> -- System Information:
>> Debian Release: 4.0
>> APT prefers unstable
>> APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
>> Architecture: i386 (i686)
>> Shell: /bin/sh linked to /bin/bash
>> Kernel: Linux 22.214.171.124-scyw00225
>> Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
>> Versions of packages gnutls-bin depends on:
>> ii libc6 2.3.6.ds1-7
>> ii libgcrypt11 1.2.3-2
>> ii libgnutls13 1.4.4-2
>> ii libgpg-error0 1.4-1
>> ii libopencdk8 0.5.9-2
>> ii libtasn1-3 0.3.6-2
>> ii zlib1g 1:1.2.3-13
> The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
> vision of the emperor's, and its inclusion in this work does not constitute
> tacit approval by the author or the publisher for any such projects,
> howsoever undertaken. (c) Jasper Ffforde
More information about the Gnutls-devel