Marc (& Sam), Would you please elaborate a little on this? I'm trying to straighten things up on QMail-Toaster and could use a little help. I'm far from an openssl expert, but I'm learning. ;)
The qmail TLS patch that's presently in place (Frederik Vermeulen - qmail-tls 20060104 http://inoa.net/qmail-tls/) is a little outdated. It has provisions for rsa512.pem along with dh512.pem and dh1024.pem files. I see that rsa key exchange is now disabled by default, so that code is dead. I'm wondering though about dh512.pem vs dh1024.pem files. These are generated by the openssl dhparam command for the respective key lengths. From the patch code, I see that a key length parameter is given to the callback function, which controls which pem file is used. Here's the callback function from the patch: +DH *tmp_dh_cb(SSL *ssl, int export, int keylen) +{ + if (!export) keylen = 1024; + if (keylen == 512) { + FILE *in = fopen("control/dh512.pem", "r"); + if (in) { + DH *dh = PEM_read_DHparams(in, NULL, NULL, NULL); + fclose(in); + if (dh) return dh; + } + } + if (keylen == 1024) { + FILE *in = fopen("control/dh1024.pem", "r"); + if (in) { + DH *dh = PEM_read_DHparams(in, NULL, NULL, NULL); + fclose(in); + if (dh) return dh; + } + } + return DH_generate_parameters(keylen, DH_GENERATOR_2, NULL, NULL); +} I'm at a loss determining where this keylen comes from. I'm not finding where it's set or determined. I'm also wondering, should 2048 and 4096 key lengths also be included? They are mentioned in the man page (http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html) Notes section, but not in the code examples found there. How are the multiple key lengths implemented (distinguished) in the tls-dhparams-file option of the spamdyke configuration? Thanks for your help with this. I'm learning a lot. P.S. Sam, the documentation refers to "openssl dhparams". Should be "openssl dhparam" (no S in dhparam). P.P.S. Sam, the documentation says "the default list of ciphers is usually fine". What *is* the default list? Same as what the "openssl ciphers" command returns (iow, all of them, in no particular order)? Thanks again. -- -Eric 'shubes' On 02/05/2014 06:34 AM, Marc Gregel wrote: > Just for the records: > With Version 5.0.0 and the new option "tls-dhparams-file" everything > works great, TLS uses the strong cipher suites now! > Thank you :-) > > > 2013-09-10 Marc Gregel <[email protected] > <mailto:[email protected]>>: > > Looking forward to the Update :-) > > > 2013/9/10 Sam Clippinger > <[email protected] > <mailto:[email protected]>> > > I think you're exactly right -- I'll need to add another TLS > option to spamdyke to accept the DH parameters and pass them to > OpenSSL with the callback. I'll have to figure out how to test > it as well... > > Thanks for finding that link, I don't think I would have even > looked at a function with "tmp" in its name! > > -- Sam Clippinger > > > > > On Sep 9, 2013, at 3:34 AM, Marc Gregel wrote: > >> Hi Sam, >> >> is it possible that the problem is because of missing "dh keys"? >> I think (!) spamdyke don't use or call something like this here: >> http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html - >> read the 'notes' part >> so cipher with EDHE:DE won't work. >> >> My server/openssl is fine because the orginal qmail-tls works >> with cipher EDHE_DH"! So the problem is the tls handling of >> spamdyke?! >> >> >> 2013/9/8 Sam Clippinger >> <[email protected] >> <mailto:[email protected]>> >> >> Hmmm... I think you may be beyond the edge of my >> expertise, but I'll certainly try to help if I can. >> spamdyke uses the OpenSSL library to handle SSL and TLS, >> so anything that works with OpenSSL on the command line >> should work with spamdyke as well. The option >> "tls-cipher-list" serves the same function as the >> "-cipher" option to "openssl". spamdyke just takes the >> text it's given and passes it to >> the SSL_CTX_set_cipher_list() function in the OpenSSL >> library before the connection is established. The ciphers >> you give should be ones listed when you run "openssl >> ciphers" from the command line, I'm not sure how it >> handles abbreviations. >> >> It's possible the problem is actually within openssl's >> SMTP client. If it's not starting the SMTP connection and >> asking for TLS correctly, the client could be sending >> encrypted text while the server is still in plaintext mode >> or vice-versa. That would yield some strange error >> messages on both sides. >> >> I think I would suggest configuring spamdyke on port 465 >> with "tls-level" set to "smtps" and the "tls-cipher-list" >> option set to your specific ciphers. Then use this >> command to connect and test (substitute your ciphers as >> appropriate): >> openssl s_client -quiet -cipher "EXP-RC4-MD5" -connect >> localhost:465 >> If it connects and you see the "220" greeting banner, it's >> working. If you see an "alert handshake failure", you've >> probably selected a cipher the server doesn't support. >> >> -- Sam Clippinger >> >> >> >> >> On Sep 7, 2013, at 3:18 PM, Marc Gregel wrote: >> >>> Hi :-) >>> >>> These days where the NSA is watching us I decided to make >>> my server as secure as possible. >>> For qmail it means to use TLS with strong encryption - >>> openssl with "- ciphers "EDHS:DE" for example. >>> >>> The original QMAIL without spamdyke works fine: >>> openssl s_client -starttls smtp -connect localhost:25 >>> shows me this: >>> Protocol : TLSv1.2 >>> Cipher : DHE-RSA-AES256-GCM-SHA384 >>> Great! >>> >>> Now I enable spamdyke and test it again... >>> Protocol : TLSv1.2 >>> Cipher : AES256-GCM-SHA384 >>> >>> Ok, not that good... maybe just a wrong cipher list? So I >>> specified it a little bit more (works fine with qmail only): >>> openssl s_client -starttls smtp -connect localhost:25 >>> -cipher 'DH' >>> >>> Ups, an error: >>> CONNECTED(00000003) >>> 139820346807976:error:14077410:SSL >>> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake >>> failure:s23_clnt.c:741: >>> >>> I already tried to add "dhparam" to the qmail servercert >>> (mentioned here >>> http://permalink.gmane.org/gmane.mail.spam.spamdyke.user/3226 ) >>> but that didnt't change anything... >>> >>> >>> I also tested with "tls-cipher-list" param at the conf >>> file - same error. >>> And at the maillog this: >>> A protocol or library failure occurred, >>> error:140E6118:lib(20):func(230):reason(280) >>> >>> Is it possible that there's a bug in spamdyke with strong >>> encryption? >>> >>> Thanks for your help, >>> Marc >>> _______________________________________________ >>> spamdyke-users mailing list >>> [email protected] >>> <mailto:[email protected]> >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> >> >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> <mailto:[email protected]> >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> >> >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> <mailto:[email protected]> >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > _______________________________________________ > spamdyke-users mailing list > [email protected] > <mailto:[email protected]> > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
