Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

4.80 RC2 TLS interop between GnuTLS and NSS

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


snabb at epipe

May 19, 2012, 9:01 PM

Post #1 of 9 (493 views)
Permalink
4.80 RC2 TLS interop between GnuTLS and NSS

On 2012-05-19 14:50, Phil Pennock wrote:
> I have uploaded Exim 4.80 RC2 to:
> ftp://ftp.exim.org/pub/exim/exim4/test/
[..]
> Please report issues in reply to this email, on exim-users.

I think there is some TLS interoperability issue between Exim 4.80 RC2
built with GnuTLS and NSS (Netscape Security Services) on the client side.

I built RC2 on Ubuntu 12.04 x86_64 and as a result Thunderbird email
client on the same platform was not able to negotiate STARTSSL any
longer. The Thunderbird error message was not helpful at all:

Sending of message failed.
The message could not be sent using SMTP server localhost for an unknown
reason. Please verify that your SMTP server settings are correct and try
again, or contact your network administrator.

On the Exim side I see this (exim -bd -d-all+tls):

18935 Listening...
18935 Connection request from 127.0.0.1 port 47545
18935 1 SMTP accept process running
18935 Listening...
18939 Process 18939 is handling incoming connection from [127.0.0.1]
18939 Process 18939 is ready for new message
18939 initialising GnuTLS as a server
18939 GnuTLS global init required.
18939 initialising GnuTLS server session
18939 Expanding various TLS configuration options for session credentials.
18939 certificate file = /opt/exim/exim.crt
18939 key file = /opt/exim/exim.key
18939 TLS: cert/key registered
18939 TLS: tls_verify_certificates not set or empty, ignoring
18939 Initialising GnuTLS server params.
18939 GnuTLS tells us that for D-H PK, NORMAL is 2432 bits.
18939 read D-H parameters from file "/var/spool/exim/gnutls-params-2432"
18939 initialized server D-H parameters
18939 GnuTLS using default session cipher/priority "NORMAL"
18939 TLS: a client certificate will not be requested.
18939 Received TLS SNI "localhost" (unused for certificate selection)
18939 LOG: MAIN
18939 TLS error on connection from localhost [.127.0.0.1
(gnutls_handshake): A TLS packet with unexpected length was received.
18939 TLS failed to start
18939 LOG: smtp_connection MAIN
18939 SMTP connection from localhost [127.0.0.1] closed by EOF
18935 child 18939 ended: status=0x0
18935 normal exit, 0
18935 0 SMTP accept processes now running
18935 Listening...

Exim 4.80 RC2 has the following relevant build options:

SUPPORT_TLS=yes
USE_GNUTLS=yes
USE_GNUTLS_PC=gnutls

And in the configuration:

tls_advertise_hosts = *
tls_certificate = /opt/exim/exim.crt
tls_privatekey = /opt/exim/exim.key
daemon_smtp_ports = 25 : 443 : 587
tls_on_connect_ports = 443

Everything works fine with Exim 4.77 with the following build options:

SUPPORT_TLS=yes
USE_GNUTLS=yes
TLS_LIBS=-lgnutls -ltasn1 -lgcrypt

...and the same run-time configuration.

To debug this further, I pointed my firefox browser (which also uses
NSS) to https://localhost/ (which is a bit odd way to debug SMTP
problems, but I could not find any simple command-line client for
talking TLS with NSS). With firefox I got the following message when
connecting to 4.80 RC2:

Secure Connection Failed
An error occurred during a connection to localhost.
Unable to generate public/private key pair.
(Error code: sec_error_keygen_fail)

The log on the server side says again: "A TLS packet with unexpected
length was received."

When connecting with chromium I get the following:

This webpage is not available
The webpage at https://localhost/ might be temporarily down or it may
have moved permanently to a new web address.
Error 2 (net::ERR_FAILED): Unknown error.

When connecting to Exim 4.77 with GnuTLS using firefox I get the usual
complaint about untrusted certificate. After confirming a security
exception I can see the following in Exim's debug output:

20776 SMTP syntax error in "GET /favicon.ico HTTP/1.1" H=localhost
[127.0.0.1] unrecognized command

This obviously indicates that the TLS connection was successfully
negotiated this time.

If I compile Exim 4.80 RC2 with OpenSSL everything works fine. Also if I
test against Exim 4.80 RC2 with GnuTLS using "openssl s_client" or swaks
I do not have any issues. This seems to be NSS specific.

The GnuTLS library version on Ubuntu 12.04 is "2.12.14-5ubuntu3" and NSS
library is "3.13.1.with.ckbi.1.88-1ubuntu6".


I am trying this out next with Scientific Linux 6.2 (should be the same
as RHEL/CentOS 6.2) which has a different GnuTLS version. But it will
take some time.


Meanwhile, is anyone else able to reproduce this on the same or another
platform? Compile Exim 4.80 RC2 with GnuTLS and try to connect to it
with anything that uses NSS, such as Thunderbird, Firefox, Chromium etc.
Can you get a successful TLS connection?

I am unsure how to debug this further (I am not familiar with any of
these TLS libraries) but will be happy to assist.

--
Janne Snabb / EPIPE Communications
snabb [at] epipe - http://epipe.com/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


snabb at epipe

May 19, 2012, 10:14 PM

Post #2 of 9 (481 views)
Permalink
Re: 4.80 RC2 TLS interop between GnuTLS and NSS [In reply to]

On 2012-05-20 11:01, Janne Snabb wrote:
> I am trying this out next with Scientific Linux 6.2 (should be the same
> as RHEL/CentOS 6.2) which has a different GnuTLS version. But it will
> take some time.

It appears that:

- If I compile Exim 4.80 RC2 with GnuTLS (2.8.5-4.el6_2.2) on Scientific
Linux 6.2 I do not have problems connecting to it with NSS based client
(no matter if the client is shipped by SL or Ubuntu).

- If I attempt to connect to Exim 4.80 RC2 with GnuTLS
(2.12.14-5ubuntu3) on Ubuntu 12.04 with firefox running on SL 6.2 I
still have the same issue.

Thus the problem I am seeing seems to depend on the GnuTLS version Exim
is linked against. It does not work with Ubuntu version of GnuTLS but
works fine with Scientific Linux/RHEL version of GnuTLS.

--
Janne Snabb / EPIPE Communications
snabb [at] epipe - http://epipe.com/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


snabb at epipe

May 19, 2012, 11:08 PM

Post #3 of 9 (488 views)
Permalink
Re: 4.80 RC2 TLS interop between GnuTLS and NSS [In reply to]

On 2012-05-20 11:01, Janne Snabb wrote:
> I am unsure how to debug this further (I am not familiar with any of
> these TLS libraries) but will be happy to assist.

I put "#define EXIM_GNUTLS_LIBRARY_LOG_LEVEL 9" in src/tls-gnu.c and got
some additional output, see below.

Additionally I noticed that I can reproduce this issue also on Debian
"sid" with GnuTLS 2.12.19-1.

--
Janne Snabb / EPIPE Communications
snabb [at] epipe - http://epipe.com/

$ sudo /opt/exim/bin/exim -bd -d-all+tls
Exim version 4.80_RC2 uid=0 gid=0 pid=4003 D=8000000
Berkeley DB: Berkeley DB 5.1.25: (January 28, 2011)
Support for: iconv() GnuTLS DKIM
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch dbm dbmjz
dbmnz dnsdb
Authenticators:
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile autoreply pipe smtp
Fixed never_users: 0
Size of off_t: 8
Compiler: GCC [4.6.3]
Library version: GnuTLS: Compile: 2.12.14
Runtime: 2.12.14
Library version: PCRE: Compile: 8.12PCRE_PRERELEASE
Runtime: 8.12 2011-01-15
WHITELIST_D_MACROS unset
TRUSTED_CONFIG_LIST unset
configuration file is /opt/exim/configure
log selectors = 00000ffc 00212001
cwd=/home/snabb/src/exim-4.80_RC2 3 args: /opt/exim/bin/exim -bd -d-all+tls
trusted user
admin user
4003 listening on all interfaces (IPv4) port 25
4003 listening on all interfaces (IPv4) port 443
4003 listening on all interfaces (IPv4) port 587
4003 pid written to /opt/exim/spool/exim-daemon.pid
4003 LOG: MAIN
4003 exim 4.80_RC2 daemon started: pid=4003, no queue runs, listening
for SMTP on port 25 (IPv4) port 587 (IPv4) and for SMTPS on port 443 (IPv4)
4003 daemon running with uid=115 gid=127 euid=115 egid=127
4003 Listening...
4003 Connection request from 127.0.0.1 port 35030
4003 1 SMTP accept process running
4003 Listening...
4011 Process 4011 is handling incoming connection from [127.0.0.1]
4011 initialising GnuTLS as a server
4011 GnuTLS global init required.
4011 initialising GnuTLS server session
4011 GnuTLS<4>: REC[0x1213b00]: Allocating epoch #0
4011
4011 Expanding various TLS configuration options for session credentials.
4011 certificate file = /opt/exim/exim.crt
4011 key file = /opt/exim/exim.key
4011 GnuTLS<2>: ASSERT: x509_b64.c:453
4011
4011 GnuTLS<2>: Could not find '-----BEGIN RSA PRIVATE KEY'
4011
4011 GnuTLS<2>: ASSERT: x509_b64.c:453
4011
4011 GnuTLS<2>: Could not find '-----BEGIN DSA PRIVATE KEY'
4011
4011 GnuTLS<2>: ASSERT: privkey.c:387
4011
4011 GnuTLS<2>: Falling back to PKCS #8 key decoding
4011
4011 TLS: cert/key registered
4011 TLS: tls_verify_certificates not set or empty, ignoring
4011 Initialising GnuTLS server params.
4011 GnuTLS tells us that for D-H PK, NORMAL is 2432 bits.
4011 read D-H parameters from file "/opt/exim/spool/gnutls-params-2432"
4011 initialized server D-H parameters
4011 GnuTLS using default session cipher/priority "NORMAL"
4011 TLS: a client certificate will not be requested.
4011 GnuTLS<2>: ASSERT: gnutls_constate.c:695
4011
4011 GnuTLS<4>: REC[0x1213b00]: Allocating epoch #1
4011
4011 GnuTLS<4>: REC[0x1213b00]: Expected Packet[0] Handshake(22) with
length: 1
4011
4011 GnuTLS<4>: REC[0x1213b00]: Received Packet[0] Handshake(22) with
length: 157
4011
4011 GnuTLS<4>: REC[0x1213b00]: Decrypted Packet[0] Handshake(22) with
length: 157
4011
4011 GnuTLS<3>: HSK[0x1213b00]: CLIENT HELLO was received [157 bytes]
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Client's version: 3.1
4011
4011 GnuTLS<2>: ASSERT: gnutls_db.c:238
4011
4011 GnuTLS<2>: EXT[0x1213b00]: Parsing extension 'SERVER NAME/0' (14
bytes)
4011
4011 Received TLS SNI "localhost" (unused for certificate selection)
4011 GnuTLS<2>: EXT[0x1213b00]: Parsing extension 'SESSION TICKET/35'
(0 bytes)
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Received safe renegotiation CS
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Removing ciphersuite:
DHE_DSS_3DES_EDE_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Removing ciphersuite:
DHE_DSS_AES_128_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Removing ciphersuite:
DHE_DSS_AES_256_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Removing ciphersuite:
DHE_DSS_CAMELLIA_128_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Removing ciphersuite:
DHE_DSS_CAMELLIA_256_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite:
DHE_RSA_3DES_EDE_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite:
DHE_RSA_AES_128_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite:
DHE_RSA_AES_256_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite:
DHE_RSA_CAMELLIA_128_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite:
DHE_RSA_CAMELLIA_256_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite: RSA_ARCFOUR_MD5
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite:
RSA_CAMELLIA_128_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Keeping ciphersuite:
RSA_CAMELLIA_256_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Selected cipher suite:
DHE_RSA_CAMELLIA_256_CBC_SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Selected Compression Method: NULL
4011
4011 GnuTLS<3>: HSK[0x1213b00]: Safe renegotiation succeeded
4011
4011 GnuTLS<2>: EXT[0x1213b00]: Sending extension SAFE RENEGOTIATION (1
bytes)
4011
4011 GnuTLS<3>: HSK[0x1213b00]: SessionID:
f58b3839e6e576898566c4edcda0bea947ef1746f3da42b8925207ee21d6d272
4011
4011 GnuTLS<3>: HSK[0x1213b00]: SERVER HELLO was sent [81 bytes]
4011
4011 GnuTLS<3>: HSK[0x1213b00]: CERTIFICATE was sent [455 bytes]
4011
4011 GnuTLS<3>: HSK[0x1213b00]: signing handshake data: using RSA-SHA1
4011
4011 GnuTLS<3>: HSK[0x1213b00]: SERVER KEY EXCHANGE was sent [749 bytes]
4011
4011 GnuTLS<3>: HSK[0x1213b00]: SERVER HELLO DONE was sent [4 bytes]
4011
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[0] Handshake(22) with
length: 81
4011
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[1] Handshake(22) with
length: 86
4011
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[1] Handshake(22) with
length: 455
4011
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[2] Handshake(22) with
length: 460
4011
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[2] Handshake(22) with
length: 749
4011
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[3] Handshake(22) with
length: 754
4011
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[3] Handshake(22) with
length: 4
4011
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[4] Handshake(22) with length: 9
4011
4011 GnuTLS<2>: ASSERT: gnutls_buffers.c:640
4011
4011 GnuTLS<2>: ASSERT: gnutls_record.c:969
4011
4011 GnuTLS<2>: ASSERT: gnutls_handshake.c:3061
4011
4011 LOG: MAIN
4011 TLS error on connection from localhost [127.0.0.1]
(gnutls_handshake): A TLS packet with unexpected length was received.
4003 child 4011 ended: status=0x0
4003 normal exit, 0
4003 0 SMTP accept processes now running
4003 Listening...

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


snabb at epipe

May 19, 2012, 11:28 PM

Post #4 of 9 (478 views)
Permalink
Re: 4.80 RC2 TLS interop between GnuTLS and NSS [In reply to]

On 2012-05-20 13:08, Janne Snabb wrote:
> Additionally I noticed that I can reproduce this issue also on Debian
> "sid" with GnuTLS 2.12.19-1.

However when linking against GnuTLS 3.0.19-2 on Debian "sid" I do not
see any problem. This issue clearly depends on the GnuTLS library
version in use.

I'll stop here for a while. Anybody has any clue?

--
Janne Snabb / EPIPE Communications
snabb [at] epipe - http://epipe.com/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


snabb at epipe

May 19, 2012, 11:52 PM

Post #5 of 9 (481 views)
Permalink
Re: 4.80 RC2 TLS interop between GnuTLS and NSS [In reply to]

On 2012-05-20 13:28, Janne Snabb wrote:
> On 2012-05-20 13:08, Janne Snabb wrote:
>> Additionally I noticed that I can reproduce this issue also on Debian
>> "sid" with GnuTLS 2.12.19-1.
>
> However when linking against GnuTLS 3.0.19-2 on Debian "sid" I do not
> see any problem. This issue clearly depends on the GnuTLS library
> version in use.

One more data point:

I can also reproduce the problem on FreeBSD 8.3 x86_64 with gnutls-2.12.18.

(Sorry about flooding these in individual messages.)

--
Janne Snabb / EPIPE Communications
snabb [at] epipe - http://epipe.com/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


pdp at exim

May 20, 2012, 2:24 AM

Post #6 of 9 (486 views)
Permalink
Re: 4.80 RC2 TLS interop between GnuTLS and NSS [In reply to]

On 2012-05-20 at 12:14 +0700, Janne Snabb wrote:
> It appears that:
>
> - If I compile Exim 4.80 RC2 with GnuTLS (2.8.5-4.el6_2.2) on Scientific
> Linux 6.2 I do not have problems connecting to it with NSS based client
> (no matter if the client is shipped by SL or Ubuntu).
>
> - If I attempt to connect to Exim 4.80 RC2 with GnuTLS
> (2.12.14-5ubuntu3) on Ubuntu 12.04 with firefox running on SL 6.2 I
> still have the same issue.

Installed Thunderbird, dealt with it ignoring the SMTP server settings
and using the original one, not the one marked default, smacked it about
until it really did send to a test GnuTLS server, and confirmed.

gnutls-2.12.18

% export NSPR_LOG_FILE=$HOME/log-mozilla
% export NSPR_LOG_MODULES=all:5
% ./thunderbird

Wish I knew the correct NSPR module names for Thunderbird's SMTP support,
getting both SMTP and TLS. *sigh* 2.4MB of logs. Well, at least there
are logs.

If I do just NSPR_LOG_MODULES=smtp:5 then I get SMTP-level traces, but
nothing else. It does log that an EHLO was sent again after TLS; I
suspect that this is pre-buffering of a command to be sent immediately
once TLS is negotiated and that it never got sent.

This: https://wiki.mozilla.org/MailNews:Logging
suggests that there is no logging for SSL/TLS in the NSPR_LOG_MODULES
support, and ssltap should be used instead. I looked at ssltap briefly
when I looked for the NSS equivalent of "openssl s_client" /
"gnutls-cli" and failed to find anything.

So, ssltap is a proxy, but doesn't do its own decoding/re-encoding, so
isn't enough on its own to test the NSS libraries (I tried, I connected
with openssl client). It just dumps the data it sees passing, decoding
the TLS structures (given -s). It's also IPv4 only, creating more work,
*grump*. So, switch SMTP server to SSL-on-connect, set up ssltap to
connect to that, point Thunderbird to ssltap ...

----------------------------8< cut here >8------------------------------
Looking up "localhost"...
Proxy socket ready and listening
Connected to localhost:24
--> [.
(169 bytes of 164)
SSLRecord { [Sun May 20 05:11:47 2012]
type = 22 (handshake)
version = { 3,1 }
length = 164 (0xa4)
handshake {
type = 1 (client_hello)
length = 160 (0x0000a0)
ClientHelloV3 {
client_version = {3, 1}
random = {...}
session ID = {
length = 0
contents = {...}
}
cipher_suites[36] = {
(0x00ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV
(0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA
(0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
(0x0088) TLS/DHE-RSA/CAMELLIA256-CBC/SHA
(0x0087) TLS/DHE-DSS/CAMELLIA256-CBC/SHA
(0x0039) TLS/DHE-RSA/AES256-CBC/SHA
(0x0038) TLS/DHE-DSS/AES256-CBC/SHA
(0xc00f) TLS/ECDH-RSA/AES256-CBC/SHA
(0xc005) TLS/ECDH-ECDSA/AES256-CBC/SHA
(0x0084) TLS/RSA/CAMELLIA256-CBC/SHA
(0x0035) TLS/RSA/AES256-CBC/SHA
(0xc007) TLS/ECDHE-ECDSA/RC4-128/SHA
(0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA
(0xc011) TLS/ECDHE-RSA/RC4-128/SHA
(0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA
(0x0045) TLS/DHE-RSA/CAMELLIA128-CBC/SHA
(0x0044) TLS/DHE-DSS/CAMELLIA128-CBC/SHA
(0x0033) TLS/DHE-RSA/AES128-CBC/SHA
(0x0032) TLS/DHE-DSS/AES128-CBC/SHA
(0xc00c) TLS/ECDH-RSA/RC4-128/SHA
(0xc00e) TLS/ECDH-RSA/AES128-CBC/SHA
(0xc002) TLS/ECDH-ECDSA/RC4-128/SHA
(0xc004) TLS/ECDH-ECDSA/AES128-CBC/SHA
(0x0096) TLS/RSA/SEED-CBC/SHA
(0x0041) TLS/RSA/CAMELLIA128-CBC/SHA
(0x0004) SSL3/RSA/RC4-128/MD5
(0x0005) SSL3/RSA/RC4-128/SHA
(0x002f) TLS/RSA/AES128-CBC/SHA
(0xc008) TLS/ECDHE-ECDSA/3DES-EDE-CBC/SHA
(0xc012) TLS/ECDHE-RSA/3DES-EDE-CBC/SHA
(0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0xc00d) TLS/ECDH-RSA/3DES-EDE-CBC/SHA
(0xc003) TLS/ECDH-ECDSA/3DES-EDE-CBC/SHA
(0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
}
compression[1] = {
(00) NULL
}
extensions[47] = {
extension type server_name, length [21] = {
0: 00 13 00 00 10 6d 61 69 6c 2e 67 6c 6f 62 6e 69 | .....mail.globni
10: 78 2e 6e 65 74 | x.net
}
extension type elliptic_curves, length [8] = {
0: 00 06 00 17 00 18 00 19 | ........
}
extension type ec_point_formats, length [2] = {
0: 01 00 | ..
}
extension type session_ticket, length [0]
}
}
}
}
]
<-- [.
(3772 bytes of 81, with 3686 left over)
SSLRecord { [Sun May 20 05:11:47 2012]
type = 22 (handshake)
version = { 3,1 }
length = 81 (0x51)
handshake {
type = 2 (server_hello)
length = 77 (0x00004d)
ServerHello {
server_version = {3, 1}
random = {...}
session ID = {
length = 32
contents = {...}
}
cipher_suite = (0x0088) TLS/DHE-RSA/CAMELLIA256-CBC/SHA
compression method = (00) NULL
extensions[5] = {
extension type renegotiation_info, length [1] = {
0: 00 | .
}
}
}
}
}
(3772 bytes of 1547, with 2134 left over)
SSLRecord { [Sun May 20 05:11:47 2012]
type = 22 (handshake)
version = { 3,1 }
length = 1547 (0x60b)
handshake {
type = 11 (certificate)
length = 1543 (0x000607)
CertificateChain {
chainlength = 1540 (0x0604)
Certificate {
size = 1537 (0x0601)
data = { saved in file 'cert.001' }
}
}
}
}
(3772 bytes of 1052, with 1077 left over)
SSLRecord { [Sun May 20 05:11:47 2012]
type = 22 (handshake)
version = { 3,1 }
length = 1052 (0x41c)
handshake {
type = 12 (server_key_exchange)
length = 1048 (0x000418)
}
}
(3772 bytes of 1063, with 9 left over)
SSLRecord { [Sun May 20 05:11:47 2012]
type = 22 (handshake)
version = { 3,1 }
length = 1063 (0x427)
handshake {
type = 13 (certificate_request)
length = 1059 (0x000423)
CertificateRequest {
certificate types[2] = { 01 02 }
certificate_authorities[1054] = {
E=support [at] cacert,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc.
E=ca [at] firedrake,CN=Firedrake CA,OU=Certificate Authority,O=Firedrake Synthesis,L=London,C=UK
E=certificates [at] globnix,CN=GlobNIX Certificate Authority 3,OU=Certification Authority,O=GlobNIX Systems,C=US
E=support [at] cacert,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc.
E=ca [at] firedrake,CN=Firedrake CA,OU=Certificate Authority,O=Firedrake Synthesis,L=London,C=UK
E=certificates [at] globnix,CN=GlobNIX Certificate Authority 3,OU=Certification Authority,O=GlobNIX Systems,C=US
}
}
}
}
(3772 bytes of 4)
SSLRecord { [Sun May 20 05:11:47 2012]
type = 22 (handshake)
version = { 3,1 }
length = 4 (0x4)
handshake {
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
Read EOF on Client socket. [Sun May 20 05:11:47 2012]
Read EOF on Server socket. [Sun May 20 05:11:47 2012]
Connection 1 Complete [Sun May 20 05:11:47 2012]
----------------------------8< cut here >8------------------------------

I disabled the server TLS verification, in case, and that didn't help.

----------------------------8< cut here >8------------------------------
29792 GnuTLS<4>: REC[0x803187000]: Sending Packet[4] Handshake(22) with length: 4
29792
29792 GnuTLS<4>: REC[0x803187000]: Sent Packet[5] Handshake(22) with length: 9
29792
29792 GnuTLS<2>: ASSERT: gnutls_buffers.c:640
29792
29792 GnuTLS<2>: ASSERT: gnutls_record.c:969
29792
29792 GnuTLS<2>: ASSERT: gnutls_handshake.c:3054
29792
29792 LOG: MAIN
29792 TLS error on connection from [::1]:61703 I=[::1]:24 (gnutls_handshake): A TLS packet with unexpected length was received.
29792 search_tidyup called
----------------------------8< cut here >8------------------------------

I find it interesting that ssltap does show the length=4 packet but
*not* the length=9 packet which GnuTLS claims it was sent.

I begin to suspect a GnuTLS bug. Wild uneducated guess is that it's
related to the client sending elliptic_curves and ec_point_formats in
its extensions list, since GnuTLS doesn't support those.

This seems like a release blocker to me.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users at spodhuis

May 20, 2012, 2:46 AM

Post #7 of 9 (474 views)
Permalink
Re: 4.80 RC2 TLS interop between GnuTLS and NSS [In reply to]

On 2012-05-20 at 05:24 -0400, Phil Pennock wrote:
> Wish I knew the correct NSPR module names for Thunderbird's SMTP support,
> getting both SMTP and TLS. *sigh* 2.4MB of logs. Well, at least there
> are logs.

Er, for clarity, I did look closely but didn't see any SSL/TLS traces in
those logs.

> This: https://wiki.mozilla.org/MailNews:Logging
> suggests that there is no logging for SSL/TLS in the NSPR_LOG_MODULES
> support, and ssltap should be used instead.

Eyeball MkII being unable to find the log-lines in the all:5 output, I
proceeded to check further and discovered that.

(I didn't give up at a 2.4MB log for starting a mail client and trying
to send one mail pulled from Drafts and then quitting. I just sighed. I
guess that's what I get for bumping up the log level.)

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


snabb at epipe

May 20, 2012, 3:11 AM

Post #8 of 9 (480 views)
Permalink
Re: 4.80 RC2 TLS interop between GnuTLS and NSS [In reply to]

On 2012-05-20 16:24, Phil Pennock wrote:

> I find it interesting that ssltap does show the length=4 packet but
> *not* the length=9 packet which GnuTLS claims it was sent.

Look at the log closer:

4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[1] Handshake(22) with
length: 455
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[2] Handshake(22) with
length: 460
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[2] Handshake(22) with
length: 749
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[3] Handshake(22) with
length: 754
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

There are actually two lines for each sent packet. The "Sending" line
and "Sent" line disagree about the packet length consistently with 5.
Thus there is no packet with length 9 but it is the same packet as the
packet with length 4. I suppose one of the log messages includes a
packet header and the other one does not.

> I begin to suspect a GnuTLS bug. Wild uneducated guess is that it's
> related to the client sending elliptic_curves and ec_point_formats in
> its extensions list, since GnuTLS doesn't support those.

I looked the handshake using Wireshark, it seems to be able to decode it
well. It shows something interesting: It is the client (NSS) who closes
the TCP connection right after receiving the "Server Hello" from
Exim/GnuTLS. It looks like NSS is *receiving* something that it does not
like. It would be good to figure out how to get some debug output from
NSS...

--
Janne Snabb / EPIPE Communications
snabb [at] epipe - http://epipe.com/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users at spodhuis

May 20, 2012, 3:35 AM

Post #9 of 9 (476 views)
Permalink
Re: 4.80 RC2 TLS interop between GnuTLS and NSS [In reply to]

On 2012-05-20 at 17:11 +0700, Janne Snabb wrote:
> On 2012-05-20 16:24, Phil Pennock wrote:
> > I find it interesting that ssltap does show the length=4 packet but
> > *not* the length=9 packet which GnuTLS claims it was sent.
>
> Look at the log closer:

*sigh* I wish I hadn't run Thunderbird ;) as polled all my mail in such
a way that it no longer appears "new" and I missed this message until
I'd written to help-gnutls.

> 4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[1] Handshake(22) with
> length: 455
> 4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[2] Handshake(22) with
> length: 460
> 4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[2] Handshake(22) with
> length: 749
> 4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[3] Handshake(22) with
> length: 754
> 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
>
> There are actually two lines for each sent packet. The "Sending" line
> and "Sent" line disagree about the packet length consistently with 5.
> Thus there is no packet with length 9 but it is the same packet as the
> packet with length 4. I suppose one of the log messages includes a
> packet header and the other one does not.

Oh crap. I parsed it as "we are sending packet" and "we have been sent
packet". Deoh. Okay, 6am, I *really* need to go get some sleep.

FWIW, I've modified git head so that Exim now checks for a trailing
newline in the message sent from GnuTLS and the output is no longer so
spaced out.

In a *working* session I see:
31728 GnuTLS<4>: REC[0x803193000]: Sending Packet[3] Handshake(22) with length: 4
31728 GnuTLS<4>: REC[0x803193000]: Sent Packet[4] Handshake(22) with length: 9
31728 GnuTLS<4>: REC[0x803193000]: Expected Packet[1] Handshake(22) with length: 1
31728 GnuTLS<4>: REC[0x803193000]: Received Packet[1] Handshake(22) with length: 310
31728 GnuTLS<4>: REC[0x803193000]: Decrypted Packet[1] Handshake(22) with length: 310
31728 GnuTLS<3>: HSK[0x803193000]: CLIENT KEY EXCHANGE was received [310 bytes]

So where a working session logs "Expected Packet", the broken sessions
log:
29792 GnuTLS<2>: ASSERT: gnutls_buffers.c:640
29792 GnuTLS<2>: ASSERT: gnutls_record.c:969
29792 GnuTLS<2>: ASSERT: gnutls_handshake.c:3054

> I looked the handshake using Wireshark, it seems to be able to decode it
> well. It shows something interesting: It is the client (NSS) who closes
> the TCP connection right after receiving the "Server Hello" from
> Exim/GnuTLS. It looks like NSS is *receiving* something that it does not
> like. It would be good to figure out how to get some debug output from
> NSS...

Since ssltap never sees the data, those GnuTLS assertions must be
resulting from a torn-down session, and so Exim's subsequent regular log
of session closed by EOF is not EOF by client after TLS abort, but the
EOF triggered the ASSERT failures.

Woot! Checked out origin/gnutls_2_12_x in my git clone of GnuTLS, and
check gnutls_buffers.c and I see:

if (ret == 0)
{ /* EOF */
gnutls_assert ();
return 0;
}

That could do with something more graceful, so that the application can
find out what really happened. We log:
(gnutls_handshake): A TLS packet with unexpected length was received.
so the "unexpected length" is gnutls_strerror(), even though
<gnutls/gnutls.h> says:
#define GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9 /* GNUTLS_A_RECORD_OVERFLOW */

I don't see a better error code for peer EOF, but calling EOF a record
overflow is still a little confusing to dumbasses like me.

Okay, is clearly NSS disliking the server_hello_done.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.