[gnutls-dev] Re: Bug#396867: gnutls-bin: does not seem to properly handle rehandshake request

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
> 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
>
>> Hi,

Hi Marc!

>> 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[0] 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:

static void
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?

Thanks,
Simon

>> 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.
>
>> Greetings
>> Marc
>
>> -- 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 2.6.18.1-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