[Pkg-gnutls-maint] Bug#402861: gnutls

[Nikos Mavrogiannopoulos]

On Monday 22 October 2007, Nikos Mavrogiannopoulos wrote:
> On Sun, Aug 19, 2007 at 08:38:42AM +0200, Andreas Metzler wrote:
> > > Something that might help in debugging without much fuss, would be
> > > to test handshake by enabling other ciphersuites.
> > > That would be for gnutls-serv to only enable:
> > > a. key exchage: DHE-RSA  cipher: 3DES
> > > b. key exchange: DHE-RSA cipher: AES_256_CBC
> > > c. key exchange: RSA cipher ARCFOUR
> > > and return the traces if possible.
> > I have done these three tests (and a fourth against a gnutls-serv with
> > no restrictions for kx and cipher), and have attached the traces.
> > Version of gnutls-bin and libgnutls13 is 1.7.19-1.
> I have no clue what this could be. I only posses a Sony-Ericsson W810 which
> connects to my test gnutls server just fine, so I cannot reproduce or test
> it. If you could find a combination of ciphers, protocols, macs that work
> with these phones, I'd like to see the trace as well. However since I'm
> unable to reproduce I don't expect much.

Ok it seems that with the help of Hanno Wagner I managed to debug this issue.
These clients fail to understand TLS 1.0 record packets with a padding added. 
This only occurs when using non stream ciphers (i.e. not arcfour) and does 
not occur when using SSL 3.0 which does not allow such padding. So one point 
is for users of these devices to report that as bug.

However a fix in gnutls is not easy to do. If we disable the random padding in 
TLS 1.0 we do disable a nice feature of TLS that protects against statistical 
attacks. Thus I'd be against such a fix.

A solution for the clients would be to only allow SSL 3.0 (if they can 
configure it).

What I can do within gnutls is to add a function to disable this protection 
and servers that require maximum compatibility could use it.

(thus gnutls 2.2 will introduce gnutls_session_enable_compatibility_mode() to 
counter client bugs)

regards,
Nikos