FYI, the upcoming GnuTLS 2.1.7 have a new API where applications can provide a string to gnutls to set protocol priorities, and it can be used to disable padding. An application could call:
gnutls_priority_set_direct (session, "NORMAL:%COMPAT", NULL, 0); Instead of calling gnutls_set_default_priority(). This will do the same, but will also disable padding. The application could even get this string from the user or a configuration file, so that not all users are exposed to the vulnerability by default. Users that want to disable padding could then change 'NORMAL' into 'NORMAL:%COMPAT' manually. /Simon "Nikos Mavrogiannopoulos" <[EMAIL PROTECTED]> writes: > OpenSSL does not support random padding. They handle TLS 1.0 padding exactly > as SSL 3.0, thus this issue does not occur there. I believe that random > padding > is important feature that avoids statistical attacks on the data, so > it's enabled by default > in gnutls. > > On 11/5/07, Simon Josefsson <[EMAIL PROTECTED]> wrote: >> Nikos wrote: >> >> > 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. >> >> Why doesn't this problem happen with OpenSSL? Does it MAC padding under >> some circumstances? Could GnuTLS do the same? >> >> /Simon >> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]