On an alpha box with: qmail-1.03-r15 (compiled with +ssl) openssl-0.9.7d-r2 glibc-2.3.2-r12 After STARTTLS, qmail-smtpd only accepts QUIT command; all others generate "read:errno=0" for a response and drop the connection with reporting any errors to the error log. This is a major problem because some MTAs, when they see that STARTTLS is available will always attempt a TLS session which fails. The end result is that the mail is returned to the sender as undeliverable. On the other hand, some MTAs don't do the STARTTLS and can succesfully deliver mail. Outside mail appears to be working, because some of it arrives. Other mail is undeliverable WITH NO Reproducible: Always Steps to Reproduce: 1. emerge qmail with +ssl; and start with /etc/init.d/svscan start 2. attempt en-clair connection with telnet: works fine. 3. attempt ssl/tls session Actual Results: 2. unencrypted (works) $ telnet mae smtp Trying 18.62.3.162... Connected to mae.mit.edu. Escape character is '^]'. 220 mae.mit.edu ESMTP EHLO bombur.mit.edu 250-mae.mit.edu 250-STARTTLS 250-SIZE 0 250-PIPELINING 250 8BITMIME VRFY jf@mae.mit.edu 252 send some mail, i'll try my best AUTH LOGIN 530 Must issue a STARTTLS command first (#5.7.0) QUIT 221 mae.mit.edu Connection closed by foreign host. 3. After STARTTLS, only QUIT works: 3a. EHLO failing: $ openssl s_client -connect mae:25 -starttls smtp -CAfile CA-sens-cert.pem CONNECTED(00000003) depth=1 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT verify return:1 depth=0 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu verify return:1 --- Certificate chain 0 s:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu i:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT --- Server certificate -----BEGIN CERTIFICATE----- MIIDkjCCAnoCARQwDQYJKoZIhvcNAQEEBQAwgZ8xEzARBgoJkiaJk/IsZAEZEwNl ... Me0YXI6h -----END CERTIFICATE----- subject=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu issuer=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT --- No client certificate CA names sent --- SSL handshake has read 1122 bytes and written 484 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 0DB15293E29ADA088B84F755F04896199C7F898ACA33567EEF5A0FBAB7898EF6 Session-ID-ctx: Master-Key: 91246DB110B0B84CF9CBB9531685A0BA2FF971277638FBD14BE361A87F051B795B148987B2ED6721 A83B8263DAEAF174 Key-Arg : None Start Time: 1105371307 Timeout : 300 (sec) Verify return code: 0 (ok) --- 220 mae.mit.edu ESMTP EHLO ajexp3.mit.edu read:errno=0 3b. AUTH LOGIN failing: $ openssl s_client -connect mae:25 -starttls smtp -CAfile CA-sens-cert.pem CONNECTED(00000003) depth=1 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT verify return:1 depth=0 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu verify return:1 --- Certificate chain 0 s:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu i:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT --- Server certificate -----BEGIN CERTIFICATE----- MIIDkjCCAnoCARQwDQYJKoZIhvcNAQEEBQAwgZ8xEzARBgoJkiaJk/IsZAEZEwNl ... Me0YXI6h -----END CERTIFICATE----- subject=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu issuer=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT --- No client certificate CA names sent --- SSL handshake has read 1122 bytes and written 484 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: D6F6BBC1E456D44A3339618E33CD26D537ACE0390824199052A96D333A55F84F Session-ID-ctx: Master-Key: 8984578062C3CFEB25C3A3F14C6097CCAB2F6F560F11E424271E66346DD90F6160BD2A2034CB5AEA 2EA72DDE371CE75A Key-Arg : None Start Time: 1105371629 Timeout : 300 (sec) Verify return code: 0 (ok) --- 220 mae.mit.edu ESMTP AUTH LOGIN read:errno=0 3c. QUIT working (notice correct DONE reply from server): $ openssl s_client -connect mae:25 -starttls smtp -CAfile CA-sens-cert.pem CONNECTED(00000003) depth=1 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT verify return:1 depth=0 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu verify return:1 --- Certificate chain 0 s:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu i:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT --- Server certificate -----BEGIN CERTIFICATE----- MIIDkjCCAnoCARQwDQYJKoZIhvcNAQEEBQAwgZ8xEzARBgoJkiaJk/IsZAEZEwNl ... Me0YXI6h -----END CERTIFICATE----- subject=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu issuer=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT --- No client certificate CA names sent --- SSL handshake has read 1122 bytes and written 484 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 668F4505281D3ECB1B46A710F6849CD0D1328B6B7B8143B48FCA950B4EE7700C Session-ID-ctx: Master-Key: 1BF83B8EB7F0942615363D812298223DA5F80697C7CBDD8315BFFDFA2FA9A1823DD08EA54716AA77 CE8C205EEC3960F8 Key-Arg : None Start Time: 1105371719 Timeout : 300 (sec) Verify return code: 0 (ok) --- 220 mae.mit.edu ESMTP QUIT DONE Expected Results: After STARTTLS, all SMTP commands should have been available. Portage 2.0.51-r3 (default-linux/alpha/2004.3, gcc-3.3.2, glibc-2.3.2-r12, 2.4. 20-gentoo-alpha-r2 alpha) ================================================================= System uname: 2.4.20-gentoo-alpha-r2 alpha EV45 Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.18-r2 Libtools: sys-devel/libtool-1.4.1-r10 ACCEPT_KEYWORDS="alpha" AUTOCLEAN="yes" CFLAGS="-mcpu=ev45 -O3 -pipe " CHOST="alpha-unknown-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/ distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="alpha avi berkdb bitmap-fonts crypt cups curl doc emacs encode f77 fbcon flash foomaticdb fortran gd gdbm gif gtk2 imap imlib jpeg kde kerberos krb4 leim libg++ libwww mad maildir mikmod mpeg ncurses nls nocardbus odbc oss pam pdflib perl plotutils png postgres python quicktime readline samba sasl spell ssl tcpd tiff truetype wmf xml xml2 xmms xv zlib"
Umm, that should be "without reporting any errors to the error log" and "Ohter mail is undeliverable WITH NO INDICATION IN LOG"
Hello Joe Could you please test qmail-1.03-r16, which is hardmasked? It has a completly new patch for STARTTLS which also fixes some problems on big-endian architectures. Thanks, Michael
Okay, I tried -r16. Not even the SSL connection could be negotiated (on the client side): $ openssl s_client -connect mae:25 -starttls smtp -CAfile CA-sens-cert.pem CONNECTED(00000003) And then it hangs. The qmail-smtpd processes burn cpu on the server and do not die on a normal shutdown. Still nothing in likely the system or qmail logs. After kill the server process, the client adds: 31194:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:
Verified the problem. Now I'll try to fix it.
Ok, now, after testing the whole evening, I can say this: it works. Just not as fast as it could. On my testing machine (provided by kloeri@g.o -- thanks!), it takes about 2.5 minutes to get the connection initialized by qmail-smtpd. I think this is somehow related to openssl, but not to qmail. Could you please try it yourself again with this command? openssl s_client -connect localhost:25 -starttls smtp -state -showcerts
Ok, this is back to -r15. And I can now build test qmails without perturbing our running system. This is the complete output requested: $ openssl s_client -connect mae:1963 -starttls smtp -CAfile CA-sens-cert.pem -state -showcerts CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT verify return:1 depth=0 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu i:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT -----BEGIN CERTIFICATE----- MIIDkjCCAnoCARQwDQYJKoZIhvcNAQEEBQAwgZ8xEzARBgoJkiaJk/IsZAEZEwNl ZHUxEzARBgoJkiaJk/IsZAEZEwNtaXQxEzARBgoJkiaJk/IsZAEZEwNybGUxFDAS BgoJkiaJk/IsZAEZEwRzZW5zMRUwEwYDVQQLEwxDZXJ0aWZpY2F0ZXMxMTAvBgNV BAMTKENBIFNlbnNvcnkgQ29tbXVuaWNhdGlvbiBHcm91cCwgUkxFLCBNSVQwHhcN MDMwOTE5MTg0NzEyWhcNMDgwOTE3MTg0NzEyWjB+MRMwEQYKCZImiZPyLGQBGRMD ZWR1MRMwEQYKCZImiZPyLGQBGRMDbWl0MRMwEQYKCZImiZPyLGQBGRMDcmxlMRQw EgYKCZImiZPyLGQBGRMEc2VuczERMA8GA1UECxMITWFjaGluZXMxFDASBgNVBAMT C21hZS5taXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2oi1 TPNCwAN61MNPCzvjSy6rArfvDfsI3hrPtvhId9xvU+Cpe/lJRmRtaRHNVHL/wYhV xKgpFUI9QuF7EcQPJFrPHMXs8pIGROGOnFgeHmAjecX41e/fvU3ru0V+dwpJ0Zx/ jaWQDZr9rAUxHajFlZ7lkKK3N5ZG+NRWj1YePEmEvTrqKyVlhtZ0bSi9FimSBHws rHPEwB9Rr/YnJjIMOgBqbdgvWDBAirUt23NFGWV/bpTyEelF4Uk3bFvUDE6kONf2 10FvWPsJXT2yCIRf2FoMU8iajfu8oKdj6qJVmI9T++JjLtCDyFh+sQLInSYNH5xh aVwqoWGJtrFwnnZMlwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQA8QkffnsjKZG1j qbDQR8xPzafP6rBn5xiMth/ZvOUcAZ7k88nrAg9HgRabKIANIXbBupwSP/xqw3i8 9jM6Z9fdnOxsCh1i860DHl0qffkJvkwotoZu08LTiBB+aH60n+2GFxkXfqaH9aYN Qnif/iT6VHboDNJkz6d2/e7uHRzRZslNZsPh3Lsaz5NB+OG0g3dtK6fkNZIiK5EM um+Ut8LiBbUBaLqKbEPiRBivCzed9cF7n4Y5YNCIR88Byx0Keg2HkANPCaUIBpAI 0hqr4rtZDlmLLT28G/giCI5kpKeXn4PpuMYjb/10N9nPkUJRnHAvEr/+BF4w2TnI Me0YXI6h -----END CERTIFICATE----- --- Server certificate subject=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu issuer=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT --- No client certificate CA names sent --- SSL handshake has read 1122 bytes and written 484 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: C9A14A6C6CE2A1B4385313A4C53794176C1360888509C0CE4F2510C5541673C7 Session-ID-ctx: Master-Key: EA5FDE71BB3AE3A8A0C9A687156F3E36241EF15D8D8FAED305FDAB945F7405EA28105282581ABAE2E01E339F1E350094 Key-Arg : None Start Time: 1106149922 Timeout : 300 (sec) Verify return code: 0 (ok) --- 220 mae.mit.edu ESMTP EHLO ajexp3.mit.edu read:errno=0 SSL3 alert write:warning:close notify
This is the -r16 version. On my machine it takes more like 5 minutes to get to the ESMTP reponse. Also note the login failure. This same username/password combination works fine with the -r15 qmail-smtpd server (compiled with USE='-ssl') with sslserver (from sysapps/ucspi-ssl) instead of tcpserver. It is also unlikely that it is SSL -- we're running using mod_ssl with apache and have SSL (only) connections to our ldap server. These, in addition to ucspi-ssl, all work fine. $ openssl s_client -connect mae:1963 -starttls smtp -CAfile CA-sens-cert.pem -state -showcerts CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT verify return:1 depth=0 /DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server key exchange A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu i:/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT -----BEGIN CERTIFICATE----- MIIDkjCCAnoCARQwDQYJKoZIhvcNAQEEBQAwgZ8xEzARBgoJkiaJk/IsZAEZEwNl ZHUxEzARBgoJkiaJk/IsZAEZEwNtaXQxEzARBgoJkiaJk/IsZAEZEwNybGUxFDAS BgoJkiaJk/IsZAEZEwRzZW5zMRUwEwYDVQQLEwxDZXJ0aWZpY2F0ZXMxMTAvBgNV BAMTKENBIFNlbnNvcnkgQ29tbXVuaWNhdGlvbiBHcm91cCwgUkxFLCBNSVQwHhcN MDMwOTE5MTg0NzEyWhcNMDgwOTE3MTg0NzEyWjB+MRMwEQYKCZImiZPyLGQBGRMD ZWR1MRMwEQYKCZImiZPyLGQBGRMDbWl0MRMwEQYKCZImiZPyLGQBGRMDcmxlMRQw EgYKCZImiZPyLGQBGRMEc2VuczERMA8GA1UECxMITWFjaGluZXMxFDASBgNVBAMT C21hZS5taXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2oi1 TPNCwAN61MNPCzvjSy6rArfvDfsI3hrPtvhId9xvU+Cpe/lJRmRtaRHNVHL/wYhV xKgpFUI9QuF7EcQPJFrPHMXs8pIGROGOnFgeHmAjecX41e/fvU3ru0V+dwpJ0Zx/ jaWQDZr9rAUxHajFlZ7lkKK3N5ZG+NRWj1YePEmEvTrqKyVlhtZ0bSi9FimSBHws rHPEwB9Rr/YnJjIMOgBqbdgvWDBAirUt23NFGWV/bpTyEelF4Uk3bFvUDE6kONf2 10FvWPsJXT2yCIRf2FoMU8iajfu8oKdj6qJVmI9T++JjLtCDyFh+sQLInSYNH5xh aVwqoWGJtrFwnnZMlwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQA8QkffnsjKZG1j qbDQR8xPzafP6rBn5xiMth/ZvOUcAZ7k88nrAg9HgRabKIANIXbBupwSP/xqw3i8 9jM6Z9fdnOxsCh1i860DHl0qffkJvkwotoZu08LTiBB+aH60n+2GFxkXfqaH9aYN Qnif/iT6VHboDNJkz6d2/e7uHRzRZslNZsPh3Lsaz5NB+OG0g3dtK6fkNZIiK5EM um+Ut8LiBbUBaLqKbEPiRBivCzed9cF7n4Y5YNCIR88Byx0Keg2HkANPCaUIBpAI 0hqr4rtZDlmLLT28G/giCI5kpKeXn4PpuMYjb/10N9nPkUJRnHAvEr/+BF4w2TnI Me0YXI6h -----END CERTIFICATE----- --- Server certificate subject=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Machines/CN=mae.mit.edu issuer=/DC=edu/DC=mit/DC=rle/DC=sens/OU=Certificates/CN=CA Sensory Communication Group, RLE, MIT --- No client certificate CA names sent --- SSL handshake has read 1652 bytes and written 356 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA Server public key is 2048 bit SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES128-SHA Session-ID: 52A86665472C7ECAAA16368F09E747D9D873C51EEE2FBACE55F972E196D80889 Session-ID-ctx: Master-Key: 63C121179808FF2466CA482608403B932A1580B3D0DB9D0134CA4FAF9927A881BE8998AE6A1CA38F8D10CD82FE2718A1 Key-Arg : None Start Time: 1106169469 Timeout : 300 (sec) Verify return code: 0 (ok) --- 220 mae.mit.edu ESMTP EHLO ajexp3.mit.edu 250-mae.mit.edu 250-PIPELINING 250-8BITMIME 250-AUTH LOGIN PLAIN CRAM-MD5 250 SIZE 0 AUTH LOGIN 334 VXNlcm5hbWU6 Y3VybHk= 334 UGFzc3dvcmQ6 Zm9vYmFy SSL3 alert read:warning:close notify closed SSL3 alert write:warning:close notify
Did I understand this right, that -r16 actually does work, even if it's slow?
Depends on what you mean by work. -r16 does seem to complete the SSL negotiation after a five minute delay while it is churning the CPU. The AUTH LOGIN, however, subsequently fails. The AUTH LOGIN configuration is known to work with -r15. It seems unlikely the current problem (long session setup, auth failure) is related to SSL because we're using the same openssl libraries in a variety of other applications on the same machine with no difficulty.
This morning, running a fresh version of the -r16 server, the connection took over 15 minutes to get to the ESMTP prompt, all while using 75-95% of the CPU. Commands other than AUTH LOGIN seem to work.
While playing around with bug 88746 (I was also bored) I noticed this CPU chugging slowness as well. As you can see from comment 6 (-r15) and comment 7 (-r16), the ciphers are different (AES128-SHA and DHE-RSA-AES128-SHA, respectively). If you don't have a dh<bits>.pem in /var/qmail/control it is generated on the fly. This caused the slowness for me. Perhaps the qmail-genrsacert.sh cron job should also generate a dh<bits>.pem? See also the usage section in http://inoa.net/qmail-tls/netqmail-1.05-tls-20050329.patch
This looks very interesting. I'll look into it before we're going into ~arch with qmail-1.03-r16. Thanks for the info!
I've enhanced qmail-genrsacert.sh so it can generate multiple keys. You have to edit it, tough. Just change the keys=""-variable. If it works, we can add more numbers to the distributed file. Can you test that, please?
After testing SSL and after noticing it was slow as hell, I've extended the cronjob again and now it also generates the Diffie-Hellman Parameters. That are the dh{512,1024}.pem files. Delivering mails via SSL is now very fast for me using -r16.
Yeah, the new qmail-genrsacert.sh script seems to do its job, even if regenerating the DH params too often on a slow host would be a major pita. I can't say anything about the AUTH LOGIN problems of comment 9 and 10, though, as I don't use it.
I tested SMTP AUTH today with checkpassword-pam and it works for me. However, it needs some special configuration. Until I integrate it into the run scripts, here's what I used: QMAIL_SMTP_POST="/usr/bin/checkpassword-pam -s system-auth" Also remember that checkpassword-pam needs to be set sticky (+s). See more about this in README.auth.gz
Can someone of you please provide an example of using the "usual" checkpassword? I don't know what's useful for users, as I don't use SMTP AUTH.
Ok, I gave qmail-1.03-r16 its own conf-smtpd. Just remerge qmail, run etc-update and edit /var/qmail/control/conf-smtpd. I've included samples for cmd5checkpw and checkpassword-pam.
Closing
