gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon Josefsson
Subject: Re: [gnutls-dev] Possible bug in GnuTLS AES/SHA1
Date: Mon, 05 Feb 2007 10:26:46 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.93 (gnu/linux)

James Westby <address@hidden> writes:

> On (09/01/07 08:50), Simon Josefsson wrote:
>> James Westby <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]