Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
I'm really sorry I haven't been able to get to spamdyke issues lately, let me
see if I can catch up...
I'll update the docs, thanks for the tip!
As for how the key size of the DH key relates to well, anything at all, I
honestly have no idea. The OpenSSL documentation is extremely frustrating to
use -- I suspect it was only written because someone was told you can't go
home until you write some docs, not because they actually intended to convey
any useful information (or confidence in their product). The only man page I
found even slightly helpful was this one:
https://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
Anyway, the key length parameter you're seeing in the qmail patch is used when
the callback function is used (SSL_CTX_set_tmp_dh_callback()). When OpenSSL
uses the supplied callback, it provides the key length as a parameter. The
examples on the OpenSSL site (and the qmail patch) use the key length to choose
a PEM file. spamdyke doesn't use that function, it uses SSL_CTX_set_tmp_dh()
instead, which allows it to provide a DH key when the TLS session is created.
Avoiding the callback is (very slightly) less efficient but simplifies
spamdyke's code (and configuration) quite a bit. But from what I can grok from
the OpenSSL docs, the key spamdyke loads is not used directly for securing the
connection; it's used for creating the key that actually does secure the
connection (through a magical, completely unexplained process). I'm not sure
the client ever sees the DH key used by spamdyke, I think it's used as a seed
for the ephemeral key. Or maybe for signing the ephemeral key. Or something
else only OpenSSL coders understand. If you can figure it out, I'd love to
know how it works.
In my testing, running openssl from the command will connect to spamdyke using
DH ephemeral keys when spamdyke's DH key is 2048 bits. Of course, most of my
testing has been done by connecting to/from the same box, obviously running the
same version of OpenSSL. It would be interesting to try running spamdyke with
different sizes of DH keys to/from different hosts to see if/when the
connections fail. It may also be possible to provide a bunch of different keys
in the same file by simply concatenating them -- the PEM format allows that.
As for the list of default ciphers, my understanding is that the list is
created when OpenSSL is compiled, so it can be different for each
distro/update/host. So there is no standard list, though there are some very
common ciphers that are probably in everyone's default list. The only way to
find your server's default list is to run openssl ciphers from the command
line.
-- Sam Clippinger
On Mar 28, 2014, at 1:47 PM, Eric Shubert e...@shubes.net wrote:
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
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
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 m...@gregel.net
mailto:m...@gregel.net:
Looking forward to the Update :-)
2013/9/10 Sam Clippinger
s...@silence.org
mailto:s...@silence.org
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
s...@silence.org
mailto:s...@silence.org
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
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
I posted that just a *little* too early. Here the answer to my previous questions: http://openssl.6102.n7.nabble.com/Size-of-ephemeral-DH-keys-td15181.html Sam, the post scripts still apply. On 03/28/2014 11:47 AM, Eric Shubert wrote: 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. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
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 :-) Marc, What key length are you using in your dhparams file? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
On 3/28/2014 12:47 PM, Eric Shubert wrote: I'm also wondering, should 2048 and 4096 key lengths also be included? As of January 1, 2014 key lengths of 1024 are not to be allowed for new installations going forward. Newly issued certs have to be for a minimum of 2048 bit keys. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
Eric, at the moment I use the same file the normal qmail installation use. spamdyke.conf: tls-dhparams-file=/var/qmail/control/dh1024.pem 2014-03-28 20:08 GMT+01:00 Eric Shubert e...@shubes.net: 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 :-) Marc, What key length are you using in your dhparams file? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
That should no doubt work, but it doesn't appear to be ideal for current use. While I think BC is referring to signed certs, what we're referring to here is the key exchange portion of the ciphers used with SSL. My (somewhat limited) understanding is that they use related technology, but their application here is different. Sam's implementation of tls-dhparams-file appears appropriate for this day and age. It's up to the admin to generate this file with whatever key length is deemed appropriate for the application. The former various key lengths are a relic left over from when export rules were restrictive according to key lengths. My only concern with using 2048 bit dh params is something I saw warning that some servers might not be able to handle keys that big. I doubt that's any longer the case. I just changed my dh1024.pem file to contain 2048 key length dh params. We'll see what happens. Thanks. -- -Eric 'shubes' On 03/28/2014 01:12 PM, Marc Gregel wrote: Eric, at the moment I use the same file the normal qmail installation use. spamdyke.conf: tls-dhparams-file=/var/qmail/control/dh1024.pem 2014-03-28 20:08 GMT+01:00 Eric Shubert e...@shubes.net mailto:e...@shubes.net: 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 :-) Marc, What key length are you using in your dhparams file? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org mailto:spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
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 m...@gregel.net: Looking forward to the Update :-) 2013/9/10 Sam Clippinger s...@silence.org 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 s...@silence.org 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(0003) 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 spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
Looking forward to the Update :-) 2013/9/10 Sam Clippinger s...@silence.org 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 s...@silence.org 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(0003) 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 spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
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 s...@silence.org 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(0003) 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 spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
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 s...@silence.org 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(0003) 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 spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
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(0003) 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 spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
