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=supp...@cacert.org,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=c...@firedrake.org,CN=Firedrake CA,OU=Certificate Authority,O=Firedrake Synthesis,L=London,C=UK E=certifica...@globnix.org,CN=GlobNIX Certificate Authority 3,OU=Certification Authority,O=GlobNIX Systems,C=US E=supp...@cacert.org,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=c...@firedrake.org,CN=Firedrake CA,OU=Certificate Authority,O=Firedrake Synthesis,L=London,C=UK E=certifica...@globnix.org,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-dev Exim details at http://www.exim.org/ ##