Can you use both ssl_protocols *and* ssl_cipher_list in the same config (in a way that's sane)?
ssl_protocols (>= 2.1) and ssl_cipher_list co-exist, or are they mutually exclusive?
I have a Dovecot 2.2.13 system, and I tried setting:
I also tried things like ssl_cipher_list = HIGH or ssl_cipher_list = HIGH:!MEDIUM:!LOW
however, doing this seems to make v3 still work unless I explicitly do !SSLv3 in ssl_cipher_list in addition to disabling it in $ssl_protocols. This is different from Apache, which has similar parameters, but where disabling the protocol takes precedence.
If I just do: ssl_protocols = !SSLv2 !SSLv3
I still get some ciphers that show up as "weak", e.g., | SSLv3: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_DHE_RSA_WITH_DES_CBC_SHA - weak [....] | TLS_RSA_WITH_DES_CBC_SHA - weak
Is there a way to exclude these ciphers, while still keeping my config easy to parse and avoiding duplicative or deprecated configs?
The behavior is also pretty strange; if I have something like one of the following, with or without $ssl_protocols set to exclude SSLv2 and SSLv3:
ssl_cipher_list = HIGH:!MEDIUM:!LOW:!SSLv3 ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:+HIGH:!MEDIUM
TLS v1.0 and v1.1 get disabled as well. I also can't seem to explicitly enable TLS 1.0 or 1.1 in $ssl_cipher_list.
w
On 12/1/2014 4:43 PM, Will Yardley wrote:
Can you use both ssl_protocols *and* ssl_cipher_list in the same config (in a way that's sane)?
Is there a way to exclude these ciphers, while still keeping my config easy to parse and avoiding duplicative or deprecated configs?
Yes to both. If you need to support older clients:
ssl_cipher_list = HIGH:!RC4:!MD5:!SRP:!PSK:!aNULL:@STRENGTH ssl_dh_parameters_length = 2048 ssl_parameters_regenerate = 0 ssl_protocols = !SSLv2 !SSLv3 TLSv1 TLSv1.1 TLSv1.2
If your userbase is limited to current clients and OSes, you can take it a bit further:
ssl_cipher_list = HIGH+kEECDH:HIGH+kEDH:!3DES:!aNULL:@STRENGTH ssl_dh_parameters_length = 4096 ssl_parameters_regenerate = 0 ssl_protocols = !SSLv2 !SSLv3 TLSv1 TLSv1.1 TLSv1.2
This drops 3DES support and makes forward secrecy mandatory.
On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote:
But why does ssl_protocols behave differently depending on if $ssl_cipher_list is defined? Shouldn't !SSLv2 and !SSLv3 be sufficient?
It seems that if ssl_cipher_list is defined, ssl_protocols = !SSLv2 !SSLv3
results in TLS1.2 being the only one active, but if it is defined, 1.0, 1.1, and 1.2 are all active?
w
On 12/2/2014 1:32 AM, Reindl Harald wrote:
Configuration management. :)
Also, no, you need to do more than just disable SSLv3. You need to disable several cipher groups allowed in TLSv1.0 and TLSv1.1, bump up the DH parameter size, and, if your client base allows it, only allow ciphers with forward secrecy.
Am 02.12.2014 um 17:33 schrieb Darren Pilgrim:
mis-management is the right word for disable future procotols
i *only* referred to "ssl_protocols" and not to ciphers
that below are sane settings supporting older Outlooks only talking RC4/DES but prefer a specific order for other clients
ssl_protocols = !SSLv2 !SSLv3 ssl_prefer_server_ciphers = yes ssl_options = no_compression ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA
On 12/2/2014 8:38 AM, Reindl Harald wrote:
It wouldn't. As you've pointed out, you don't have to explicitly enable TLSv1.0+. That's because they're (now) enabled by default. There was a period of time when TLSv1.1 and TLSv1.2 weren't enabled by default. There are also some softwares that don't do the SSL setup correctly without explicit protocol lists. It's easier to be uniformly explicit everywhere. I'd rather be needlessly explicit than have a security failure due to incorrectly assuming an implicit behaviour.
Sorry, that wasn't obvious to me.
A student of Mozilla's security policies, I see. ;)
You really only need TLSv1 3DES without PFS for Outlook on Windows XP/2003. Outlook on later Windows will do TLSv1 DHE-AES. Older Android devices will need TLSv1 AES128 without PFS. The minimum would therefore be:
HIGH+kEECDH:HIGH+kEDH:-3DES:AES128-SHA:DES-CBC3-SHA:!aNULL:@STRENGTH
Supporting other older ciphers may support ancient Android, IOS, MacOS and Thunderbird clients, but IME AES128-SHA and DES-CBC3-SHA are all you need for a realistic userbase of old software.
On Tue, Dec 02, 2014 at 08:34:50AM -0800, Darren Pilgrim wrote:
I have mostly been testing with nmap, e.g., nmap -p 993 --script ssl-enum-ciphers [target]
This then breaks down the ciphers by protocol suite. I'll test with your ssl_cipher_list example and see if it's reproducible.
w
I had some problems the first few times I restarted with ssl-params seeming to hang, but it finally works.
I am able to get it to work with just: ssl = required ssl_dh_parameters_length = 4096 ssl_parameters_regenerate = 0 ssl_prefer_server_ciphers = yes ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = HIGH+kEECDH:HIGH+kEDH:!3DES:!aNULL:@STRENGTH
Thanks for your help!
w
On 12/2/2014 10:05 AM, Will Yardley wrote:
I had some problems the first few times I restarted with ssl-params seeming to hang, but it finally works.
That would have been dovecot generating the 4096-bit DH parameters. It can take a bit, but Dovecot is quite fast at it. If Dovecot supported it, you could use OpenSSL to generate tested-safe DH parameters and supply them by file the same way you do for Postfix, nginx, etc.
On Tue, Dec 02, 2014 at 10:12:22AM -0800, Darren Pilgrim wrote:
In this case, it was consuming a lot of CPU for 5+ minutes, and the .dat.tmp file hadn't been updated since the process started, so I'm not sure if something went wrong. strace on the ssl-params process itself (without following child procs, anyway) didn't seem to show anything happening. This happened for a couple of restarts.
I enabled verbose ssl logging, restarted, and it seemed to work, then disabled verbose logging again, and it still works.
w
participants (3)
-
Darren Pilgrim
-
Reindl Harald
-
Will Yardley