[gnutls-dev] Possible bug in GnuTLS AES/SHA1

[James Westby]

On (05/02/07 10:26), Simon Josefsson wrote:
> James Westby <jw+debian at jameswestby.net> writes:
> > This only leaves the encrypted bits to check. Do you know of anyway to
> > do this? Apparently wireshark can do some of it if you give it the
> > server's private key. Marc would it be possible for you to generate a
> > testing key and certificate and provide them to me along with a trace of
> > the session when using them?
> 
> Yup, as far as I know, wireshark should be able to decrypt everything.
> Looking at that output for both failed and successful sessions would
> be good.

Yes, it decrypts everything (it gives an extra tab at the bottom with
the decrypted values in). I'm not sure that it actually verifies the
message contents. Specifically the server finished meesage that is prime
suspect includes a hash based on previous messages (not sure that I need
to tell you that of all people.) It's behaviour for say failed checksums
in TCP packets is to highlight that, so maybe it would do it here as
well, though it uses a different part of the screen.

(Note to anyone else who wants to try this specify the key in the
wireshark properties as 

  ip,port,protocol,/path/to/key

not with

  ip:port:/path/to/key

as some places claim.)

I'm not entirely sure that I have given the protocol correctly, so maybe
that will make a difference. I have the source here, so I will try and
see if it makes any attempts to verify stuff.

Also I'm going to see if I can find the bits in the openssl source that
do this and use them to check the dump. Failing that I might have to
resort to coding up something myself, but hopefully it wont come to
that.

Simon, can I ask when you would be satisfied that GnuTLS is behaving
correctly? Would calculations of all values do it? Anything more or less?

> Comparing with a successful OpenSSL handshake would be best.
> IIRC, OpenSSL could negotiate successfully with SHA-1?  Then there
> must be some kind of difference in what is sent over the wire.

Marc has also provided me with a dump of an OpenSSL transaction. the
differences that I saw with a quick look was that the client certificate
wasn't requested, and that the 256 variant of TLS_RSA_AES_CBC_SHA was
picked by the server. The first can be done with the -verify option to
s_server, the second can be done with the -ciphers option, somehow, but
it is not clear what the format of this option is. In a private exchange
with Marc he is helping me to get the traces as similar as possible.

> 
> Btw, it might be better to compare against the OpenSSL dump rather
> than comparing against the RFC.  Following the RFC isn't guaranteed to
> work against the client, but if OpenSSL works against the client, it
> is doing something that the client likes.  We could mimic that
> behaviour if we know what it is.

That sounds fair. If I can see a difference then I will try and pinpoint
it to allow you to decide what to do.

Thanks,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256