Summary: | qmail-smtpd fails after starttls | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joe Frisbie <symphony.red> |
Component: | Current packages | Assignee: | Qmail Team (OBSOLETE) <qmail-bugs+disabled> |
Status: | VERIFIED TEST-REQUEST | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | Alpha | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 29485 |
Description
Joe Frisbie
2005-01-10 07:57:21 UTC
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 |