Re: GnuTLS/NSS interop in Exim 4.80 RC

[Nikos Mavrogiannopoulos]

On Tue, May 22, 2012 at 10:38 AM, Janne Snabb <address@hidden> wrote:

> The previously discussed interop problem between GnuTLS and NSS
> manifests itself in such a way that NSS client just closes the TCP
> connection after it receives the "Server Hello" packet which it does not
> like. The GnuTLS library provides very misleading diagnostics in that case:
> [..snip..]
> 4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[3] Handshake(22) with
> length: 4
> 4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[4] Handshake(22) with length: 9
> 4011 GnuTLS<2>: ASSERT: gnutls_buffers.c:640
> 4011 GnuTLS<2>: ASSERT: gnutls_record.c:969
> 4011 GnuTLS<2>: ASSERT: gnutls_handshake.c:3061
[...]
> Instead of seeing an indication of EOF, GnuTLS reports "TLS packet with
> unexpected length was received". One must dive into gnutls_buffers.c to
> realize that it was EOF that just happened:

Indeed this was a long time request, but would have broken the API
(many clients or servers of gnutls check for that error code to
determine eof). Thus we have only incorporated that update in the
latest 3.0.x releases. Meaning that in a 3.0.x you should have
received the error code GNUTLS_E_PREMATURE_TERMINATION.

> I updated the NSS bug [1] with simple instructions on how to reproduce
> the issue using GnuTLS command line tools and Firefox. Even if the hard
> limit in NSS is fixed quickly, this will be a burden for TLS server side
> developers for many years to come. Luckily new versions of GnuTLS now
> have ECDHE-RSA key exchange support as it masks the DHE-RSA interop
> problem. People can survive with recent NSS clients if they make sure
> that ECDHE-RSA is enabled on their servers.

Thank you.

regards,
Nikos