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

[Simon Josefsson]

James Westby <jw+debian at jameswestby.net> writes:

> On (09/01/07 08:50), Simon Josefsson wrote:
>> James Westby <jw+debian at jameswestby.net> writes:
>> > As for debugging the actual data on the wire I'm not sure of the best
>> > approach for doing this.
>> 
>> Using wireshark and comparing between two sessions, one that work, and
>> one that doesn't, and look for differences, is the only I can think
>> of...  there are some TLS dump tools around, but none as versatile as
>> wireshark + RFC + pen&paper.
>> 
>
> I have sat down tonight and gone through two packet captures that Marc
> provided me with. One is the failing one, the other obtained by
> disallowing SHA. The only difference that I can see is in the cipher
> suite negotiated, which is purely the server's decision. Everything that
> was going on seemed to tie in OK with the RFC as well.
>
> It seems that the client doesn't fall back to SSL v3, I don't know where
> I got that from. Both of the sequences use TLS1.0 all the way through.

Thanks for doing that!

Is it easy for administrators to disable SHA with the application that
was used here (exim IIRC)?  Perhaps a work-around would be
configuration options to disable SHA-1 for particular IP's, or an
option to attempt a to re-handshake a failed handshake without SHA-1.
Of course, none of it should be the default, but options would allow
administrators to relax the defaults to make things work with this
client.

> 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.  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.

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.

/Simon