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@???,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@???,CN=Firedrake CA,OU=Certificate Authority,O=Firedrake Synthesis,L=London,C=UK
E=certificates@???,CN=GlobNIX Certificate Authority 3,OU=Certification Authority,O=GlobNIX Systems,C=US
E=support@???,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@???,CN=Firedrake CA,OU=Certificate Authority,O=Firedrake Synthesis,L=London,C=UK
E=certificates@???,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
