[Dovecot] patch for ssl_prefer_server_ciphers in dovecot 2.1
Dear all,
I tried to do a backport of 'ssl_prefer_server_ciphers' (http://hg.dovecot.org/dovecot-2.2/rev/897484f45a87/) to Dovecot 2.1 (namely the Debian version of Dovecot) and wanted to ask if there is any chance to integrate this feature into Dovecot 2.1 'upstream' as well. As the code structure changed quite a bit, I am not sure if my patch is complete. I tested it with pop3s and imaps in my test environment and it works just as expected and seemed to not have any unwanted effects. (Dovecot code is probably the most beautiful and easy to read C code I've seen, but there might also be some pitfalls I missed.)
best regards, Adi Kriegisch
PS: I need that feature to enable PFS while allowing Outlook to still connect and the others not to fall back to a different cipher; I was unable to find a PFS cipher that is supported by Outlook and OpenSSL.
Am 18.10.2013 13:57, schrieb Adi Kriegisch:
I tried to do a backport of 'ssl_prefer_server_ciphers' (http://hg.dovecot.org/dovecot-2.2/rev/897484f45a87/) to Dovecot 2.1 (namely the Debian version of Dovecot) and wanted to ask if there is any chance to integrate this feature into Dovecot 2.1 'upstream' as well. As the code structure changed quite a bit, I am not sure if my patch is complete. I tested it with pop3s and imaps in my test environment and it works just as expected and seemed to not have any unwanted effects. (Dovecot code is probably the most beautiful and easy to read C code I've seen, but there might also be some pitfalls I missed.)
best regards, Adi Kriegisch
PS: I need that feature to enable PFS while allowing Outlook to still connect and the others not to fall back to a different cipher; I was unable to find a PFS cipher that is supported by Outlook and OpenSSL
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:@STRENGTH ssl_prefer_server_ciphers = yes
Outlook, at least on WinXP any version, continues to use RC4 ciphers but any sane mail client is using PFS ciphers
Hi!
PS: I need that feature to enable PFS while allowing Outlook to still connect and the others not to fall back to a different cipher; I was unable to find a PFS cipher that is supported by Outlook and OpenSSL
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:@STRENGTH ssl_prefer_server_ciphers = yes
Outlook, at least on WinXP any version, continues to use RC4 ciphers but any sane mail client is using PFS ciphers Thanks for sharing; I opted for disabling RC4 completely and came up with the following (formatted for readability): HIGH:EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256: EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:ECDHE-RSA-AES256-SHA: +DHE-RSA-AES256-SHA:!AES256-SHA256:!AES256-GCM-SHA384:!CAMELLIA256-SHA: !AES128:!CAMELLIA128: !aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:!RC4:!SEED: +AES256-SHA which disables every cipher with less than 256bit and leaves AES256-SHA as a last resort for Outlook... (and is except for that pretty similar to your cipher string). This gives (openssl ciphers -V 'theabovestring'): 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x0A - ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 0xC0,0x32 - ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD 0xC0,0x2E - ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD 0xC0,0x2A - ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 0xC0,0x26 - ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 0xC0,0x0F - ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 0xC0,0x05 - ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
...and as I have no DSA keys (aka | grep -v DSA): 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 0xC0,0x32 - ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD 0xC0,0x2A - ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 0xC0,0x0F - ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
There is probably still room for improvement, but Android devices now use some DHE key exchange, Thunderbird uses the CAMELLIA cipher and so on; only Outlook -- which should have mitigated the BEAST attack uses AES256-SHA. I hope -- here too -- I didn't miss a thing. Probably the ordering should be changed a little...
all the best! -- Adi
Am 18.10.2013 14:22, schrieb Adi Kriegisch:
PS: I need that feature to enable PFS while allowing Outlook to still connect and the others not to fall back to a different cipher; I was unable to find a PFS cipher that is supported by Outlook and OpenSSL
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:@STRENGTH ssl_prefer_server_ciphers = yes
Outlook, at least on WinXP any version, continues to use RC4 ciphers but any sane mail client is using PFS ciphers Thanks for sharing; I opted for disabling RC4 completely and came up with the following (formatted for readability) HIGH:EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256: EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:ECDHE-RSA-AES256-SHA: +DHE-RSA-AES256-SHA:!AES256-SHA256:!AES256-GCM-SHA384:!CAMELLIA256-SHA: !AES128:!CAMELLIA128: !aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:!RC4:!SEED: +AES256-SHA which disables every cipher with less than 256bit and leaves AES256-SHA as a last resort for Outlook...
this does *not work* with Outlook 2003-2010 on Windows XP
it is also not a good idea to disable 128 Bit completly the idea behind ECDHE is that 128 Bit is as secure as non-EC with 256 Bit
and is except for that pretty similar to your cipher string
and likely results in not using PFS for several clients my string is from https://www.ssllabs.com/ articles and *verified* to provide PFS for any client except WinXP
a slightly different one in case of HTTP resulted in only very few clients using PFS, most likely your changes are resulting for a lot of clients in fall back to AES-256 without PFS
On 10/18/2013 5:32 AM, Reindl Harald wrote:
Am 18.10.2013 14:22, schrieb Adi Kriegisch:
PS: I need that feature to enable PFS while allowing Outlook to still connect and the others not to fall back to a different cipher; I was unable to find a PFS cipher that is supported by Outlook and OpenSSL
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:@STRENGTH ssl_prefer_server_ciphers = yes
Outlook, at least on WinXP any version, continues to use RC4 ciphers but any sane mail client is using PFS ciphers Thanks for sharing; I opted for disabling RC4 completely and came up with the following (formatted for readability) HIGH:EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256: EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:ECDHE-RSA-AES256-SHA: +DHE-RSA-AES256-SHA:!AES256-SHA256:!AES256-GCM-SHA384:!CAMELLIA256-SHA: !AES128:!CAMELLIA128: !aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:!RC4:!SEED: +AES256-SHA which disables every cipher with less than 256bit and leaves AES256-SHA as a last resort for Outlook...
this does *not work* with Outlook 2003-2010 on Windows XP
It's not Outlook's fault. Office, IE, etc. all use stunnel which, on XP/2003, is as outdated as OpenSSL 0.9.8.
Enable 3DES to support XP clients.
Am 20.10.2013 01:58, schrieb Darren Pilgrim:
On 10/18/2013 5:32 AM, Reindl Harald wrote:
Am 18.10.2013 14:22, schrieb Adi Kriegisch:
PS: I need that feature to enable PFS while allowing Outlook to still connect and the others not to fall back to a different cipher; I was unable to find a PFS cipher that is supported by Outlook and OpenSSL
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:@STRENGTH
ssl_prefer_server_ciphers = yes
Outlook, at least on WinXP any version, continues to use RC4 ciphers but any sane mail client is using PFS ciphers Thanks for sharing; I opted for disabling RC4 completely and came up with the following (formatted for readability) HIGH:EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256: EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:ECDHE-RSA-AES256-SHA: +DHE-RSA-AES256-SHA:!AES256-SHA256:!AES256-GCM-SHA384:!CAMELLIA256-SHA: !AES128:!CAMELLIA128: !aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SSLv2:!RC4:!SEED: +AES256-SHA which disables every cipher with less than 256bit and leaves AES256-SHA as a last resort for Outlook...
this does *not work* with Outlook 2003-2010 on Windows XP
It's not Outlook's fault. Office, IE, etc. all use stunnel which, on XP/2003, is as outdated as OpenSSL 0.9.8.
Enable 3DES to support XP clients
and how does that give you any gain over RC4?
http://en.wikipedia.org/wiki/Triple_DES#Security http://en.wikipedia.org/wiki/RC4#Security
It is noteworthy, however, that RC4, being a stream cipher, is the only common cipher which is immune[9] to the 2011 BEAST attack on TLS 1.0, which exploits a known weakness in the way cipher block chaining mode is used with all of the other ciphers supported by TLS 1.0, which are all block ciphers
why do you waste that much time?
sane clients with the ciphers i provided use secure encryption without break XP users and more you can't do - period
On 10/19/2013 5:24 PM, Reindl Harald wrote:
Am 20.10.2013 01:58, schrieb Darren Pilgrim:
On 10/18/2013 5:32 AM, Reindl Harald wrote:
this does *not work* with Outlook 2003-2010 on Windows XP
It's not Outlook's fault. Office, IE, etc. all use stunnel which, on XP/2003, is as outdated as OpenSSL 0.9.8.
Enable 3DES to support XP clients
and how does that give you any gain over RC4?s
The cipherspec given disables both. Given a choice, I'd rather have 3DES than RC4.
http://en.wikipedia.org/wiki/Triple_DES#Security http://en.wikipedia.org/wiki/RC4#Security
Umm... did you actually read those? That's a long, varied list of attacks on RC4, whereas 3DES is only vulnerable to the same attacks as all other CBC-mode ciphers. 112-bit encryption is still generally safe for at least a few more years. Well past the point where we don't have to worry about XP anymore.
-- Please reply on list.
Dear all,
I tried to do a backport of 'ssl_prefer_server_ciphers' (http://hg.dovecot.org/dovecot-2.2/rev/897484f45a87/) to Dovecot 2.1 [...] (Dovecot code is probably the most beautiful and easy to read C code I've seen, but there might also be some pitfalls I missed.) I'd be very grateful, if someone could have a closer look at the patch and see wether I missed something.
best regards, Adi Kriegisch
participants (3)
-
Adi Kriegisch
-
Darren Pilgrim
-
Reindl Harald