Re: disabling certain ciphers

2014-12-02 Thread Reindl Harald


Am 02.12.2014 um 06:44 schrieb Will Yardley:

On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote:

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


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?


ssl_protocols = !SSLv2 !SSLv3

and you are fine, aynthing else is nonsense because when TLSv1.3 will be 
released you go to each and every server to add it to the config? likely 
not!




signature.asc
Description: OpenPGP digital signature


Re: disabling certain ciphers

2014-12-02 Thread Darren Pilgrim

On 12/2/2014 1:32 AM, Reindl Harald wrote:


Am 02.12.2014 um 06:44 schrieb Will Yardley:

On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote:

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


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?


ssl_protocols = !SSLv2 !SSLv3

and you are fine, aynthing else is nonsense because when TLSv1.3 will be
released you go to each and every server to add it to the config? likely
not!


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.


Re: disabling certain ciphers

2014-12-02 Thread Darren Pilgrim

On 12/1/2014 9:44 PM, Will Yardley wrote:

On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote:

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


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?


Where are you see this behaviour?  What tool is reporting this?


Re: disabling certain ciphers

2014-12-02 Thread Reindl Harald



Am 02.12.2014 um 17:33 schrieb Darren Pilgrim:

On 12/2/2014 1:32 AM, Reindl Harald wrote:

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


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?


ssl_protocols = !SSLv2 !SSLv3

and you are fine, aynthing else is nonsense because when TLSv1.3 will be
released you go to each and every server to add it to the config? likely
not!


Configuration management. :)


mis-management is the right word for disable future procotols


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


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





signature.asc
Description: OpenPGP digital signature


Re: disabling certain ciphers

2014-12-02 Thread Darren Pilgrim

On 12/2/2014 8:38 AM, Reindl Harald wrote:



Am 02.12.2014 um 17:33 schrieb Darren Pilgrim:

On 12/2/2014 1:32 AM, Reindl Harald wrote:

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


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?


ssl_protocols = !SSLv2 !SSLv3

and you are fine, aynthing else is nonsense because when TLSv1.3 will be
released you go to each and every server to add it to the config? likely
not!


Configuration management. :)


mis-management is the right word for disable future procotols


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.



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


i *only* referred to ssl_protocols and not to ciphers


Sorry, that wasn't obvious to me.


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 =

[really long cipherspec snipped]

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.


Re: disabling certain ciphers

2014-12-02 Thread Will Yardley
On Tue, Dec 02, 2014 at 08:34:50AM -0800, Darren Pilgrim wrote:
 On 12/1/2014 9:44 PM, Will Yardley wrote:
  On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote:
  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)?
 
  Yes to both.  If you need to support older clients:

  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?
 
 Where are you see this behaviour?  What tool is reporting this?

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


Re: disabling certain ciphers

2014-12-02 Thread Darren Pilgrim

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.


Re: disabling certain ciphers

2014-12-02 Thread Will Yardley
On Tue, Dec 02, 2014 at 10:12:22AM -0800, Darren Pilgrim wrote:
 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.

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


Re: disabling certain ciphers

2014-12-02 Thread Darren Pilgrim

On 12/2/2014 10:26 AM, Will Yardley 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.


Yes, large DH parameters take time to generate, hence turning off 
regeneration.  5 minutes is pretty reasonable.


disabling certain ciphers

2014-12-01 Thread Will Yardley
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


Re: disabling certain ciphers

2014-12-01 Thread Darren Pilgrim

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.


Re: disabling certain ciphers

2014-12-01 Thread Will Yardley
On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote:
 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

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