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 <[email protected]> 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 (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
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
