GnuTLS/NSS interop in Exim 4.80 RC

Phil Pennock help-gnutls-phil at
Mon May 21 01:02:34 CEST 2012

On 2012-05-20 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
>  From what I can tell it is the client for some reason terminates the
> connection. What is the output on the client? Do you have a tcpdump of
> the issue? Have you tried alternative priority strings than normal
> [0]?

The client is using NSS and from what I can tell does not log problems
at the NSS level.  I've searched for ways to do that but failed.  The
protocol dump email I referenced in the first post includes the output
from ssltap; is that sufficient or do you want a raw packet capture?

> [0].

Well, I need to add a new test to the test suite, since I had omitted an
assignment and the default of NORMAL was always being used.

NORMAL:%COMPAT does not help.

*does* work.

With just "NORMAL:-CIPHER-ALL:+ARCFOUR-128" negotiation works and the
negotiated protocol is TLS1.0:RSA_ARCFOUR_MD5:128.  So it's not %COMPAT
that causes issues.

"AEAD" isn't recognised in 2.12.  Looking at the .texi I see that 2.12
supports: AES-128-CBC, AES-256-CBC, CAMELLIA-128-CBC, CAMELLIA-256-CBC,

Incrementally adding each of the items listed below in turn, I needed:
go get Thunderbird negotiating.

NORMAL:-AES-128-CBC:-AES-256-CBC is *not* sufficient.
NORMAL:-CAMELLIA-256-CBC:-CAMELLIA-128-CBC is *not* sufficient.

strings(1) on libnss3.dylib shipped with Thunderbird (MacOS) suggests
that it is which is far more recent than anything listed on

However, Exim supports both OpenSSL and GnuTLS.  If I use an OpenSSL
Exim, then Thunderbird successfully delivers using

So it's not Camellia in itself that's the problem.  It's those ciphers
as offered by GnuTLS, as opposed to OpenSSL.


More information about the Gnutls-help mailing list