GnuTLS/NSS interop in Exim 4.80 RC
help-gnutls-phil at spodhuis.org
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
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?
> . http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html
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.
NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT does not help.
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,
ARCFOUR-128, 3DES-CBC ARCFOUR-40.
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 22.214.171.124 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