Thread: SSL: better default ciphersuite

Attached patch changes the default ciphersuite to

    HIGH:!aNULL

instead of old

    DEFAULT:!LOW:!EXP:!MD5:@STRENGTH

where DEFAULT is a shortcut for "ALL:!aNULL:!eNULL".


Main goal is to leave low-level ciphersuite details to OpenSSL guys
and give clear impression to Postgres admins what it is about.

Compared to old value, new value will remove all suites with RC4 and SEED
from ciphersuite list.  If OpenSSL is compiled with support for SSL2,
it will include following suite: DES-CBC3-MD5, usable only for SSL2
connections.

Tested with OpenSSL 0.9.7 - 1.0.1, using "openssl ciphers -v ..." command.


Values used
-----------

HIGH:
  Contains only secure and well-researched algorithms.

!aNULL
  Needed to disable suites that do not authenticate server.
  DEFAULT includes !aNULL by default.


Values not used
---------------

!MD5
  This affects only one suite: DES-CBC3-MD5, which is available only
  for SSL2 connections.  So it would only pollute the default value.

@STRENGTH
  The OpenSSL cipher list is already sorted by humans,
  it's unlikely that mechanical sort would improve things.
  Also the existence of this value in old list is rather
  dubious, as server cipher order was never respected anyway.

--
marko

On Fri, 2013-11-15 at 01:11 +0200, Marko Kreen wrote:
> Attached patch changes the default ciphersuite to
> 
>     HIGH:!aNULL
> 
> instead of old
> 
>     DEFAULT:!LOW:!EXP:!MD5:@STRENGTH
> 
> where DEFAULT is a shortcut for "ALL:!aNULL:!eNULL".

> Main goal is to leave low-level ciphersuite details to OpenSSL guys
> and give clear impression to Postgres admins what it is about.

If we want to leave the details of the ciphers to OpenSSL, I think we
shouldn't be second-guessing their judgement of what a reasonable
default is.

I checked Apache mod_ssl and Postfix, and even though they are
configuring this slightly differently, I think their defaults end up
being about the same as what PostgreSQL currently has.

https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite
http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers

> HIGH:
>   Contains only secure and well-researched algorithms.
> 
> !aNULL
>   Needed to disable suites that do not authenticate server.
>   DEFAULT includes !aNULL by default.

Wouldn't HIGH exclude aNULL also?  (If not, what about eNULL?)

> !MD5
>   This affects only one suite: DES-CBC3-MD5, which is available only
>   for SSL2 connections.  So it would only pollute the default value.

I think this is only there for political correctness.

> @STRENGTH
>   The OpenSSL cipher list is already sorted by humans,
>   it's unlikely that mechanical sort would improve things.
>   Also the existence of this value in old list is rather
>   dubious, as server cipher order was never respected anyway.

Aren't you proposing to change that?

On Fri, Nov 29, 2013 at 09:18:49AM -0500, Peter Eisentraut wrote:
> On Fri, 2013-11-15 at 01:11 +0200, Marko Kreen wrote:
> > Attached patch changes the default ciphersuite to
> > 
> >     HIGH:!aNULL
> > 
> > instead of old
> > 
> >     DEFAULT:!LOW:!EXP:!MD5:@STRENGTH
> > 
> > where DEFAULT is a shortcut for "ALL:!aNULL:!eNULL".
> 
> > Main goal is to leave low-level ciphersuite details to OpenSSL guys
> > and give clear impression to Postgres admins what it is about.
> 
> If we want to leave the details of the ciphers to OpenSSL, I think we
> shouldn't be second-guessing their judgement of what a reasonable
> default is.

Well, we should - the DEFAULT is clearly a client-side default
for compatibility only.  No server should ever run with it.

OTOH, the whole point of "HIGH:!aNULL" is to leave low-level
ciphersuite details to OpenSSL guys - as a Postgres admin
is not clear to me that
  DEFAULT:!LOW:!EXP:!MD5:@STRENGTH

is actually good suite.  It contains "DEFAULT" plus several
fixes which show that DEFAULT is not good enough.  Why all that?

Admin would need to do lot research to see what it is about.
Another aspect is that the "HIGH:!aNULL" is more futureproof
as default, current default has needed fixes (!LOW:!EXP:!MD5)
and would need more fixes in the future (RC4).

Also note that OpenSSL has only one ordered cipher list - ALL.
All other tokens simply walk that list while keeping the order.
So it's not like not using DEFAULT would somehow lose important
details about order.

> I checked Apache mod_ssl and Postfix, and even though they are
> configuring this slightly differently, I think their defaults end up
> being about the same as what PostgreSQL currently has.
> 
> https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite
> http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers

My proposal is inspired by nginx default:
 http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers

> > HIGH:
> >   Contains only secure and well-researched algorithms.
> > 
> > !aNULL
> >   Needed to disable suites that do not authenticate server.
> >   DEFAULT includes !aNULL by default.
> 
> Wouldn't HIGH exclude aNULL also?  (If not, what about eNULL?)

HIGH/MEDIUM/LOW/ALL are only about cipher strength so they don't
exclude aNULL.  HIGH does exclude eNULL because eNULL ciphers
are not strong enough...

> > !MD5
> >   This affects only one suite: DES-CBC3-MD5, which is available only
> >   for SSL2 connections.  So it would only pollute the default value.
> 
> I think this is only there for political correctness.

But it's noise so should be removed.

> > @STRENGTH
> >   The OpenSSL cipher list is already sorted by humans,
> >   it's unlikely that mechanical sort would improve things.
> >   Also the existence of this value in old list is rather
> >   dubious, as server cipher order was never respected anyway.
> 
> Aren't you proposing to change that?

No, ALL and subsets of it (HIGH) are already ordered by @STRENGTH.
@STRENGTH as token is only useful if admin does complex filtering by
other parameters then wants to reorder it again by cipher strength.

Eg. an other default I've considered is:
 EECDH+HIGH:EDH+HIGH:@STRENGTH

which enforces ephemeral key use.  @STRENGTH is actually useful there,
as without it ECDHE-AES128 would be preferred to DHE-AES256.

But it exposes unnecessary complexity to database admins who
are not particularly familiar with TLS and OpenSSL internals.
So I think the HIGH:!aNULL is better default as it's simpler.
And ephemeral keys are preferred anyway.

-- 
marko


PS. @STRENGTH and OpenSSL default order in general has problem
that it orders 3DES (168-bit key) before AES128, but 3DES
strength is around 112-bit only.  So crypto-wise, the
"perfect" default, while keeping compatibility, would be:
 EECDH+HIGH:EDH+HIGH:@STRENGTH:+3DES

but it's getting messier and messier...

PS2.  And more fragile too - admin could change +3DES to -3DES
and that would be fine, but plain '3DES' would enable aNULL suite.
So keeping '!aNULL' visible might not be bad idea.

On Fri, 2013-11-29 at 18:43 +0200, Marko Kreen wrote:
> Well, we should - the DEFAULT is clearly a client-side default
> for compatibility only.  No server should ever run with it.

Any other opinions on this out there?  All instances of other
SSL-enabled servers out there, except nginx, default to some variant of
DEFAULT:!LOW:... or HIGH:MEDIUM:....  The proposal here is essentially
to disable MEDIUM ciphers by default, which is explicitly advised
against in the Postfix and Dovecot documentation, for example.

Peter Eisentraut <peter_e@gmx.net> writes:
> Any other opinions on this out there?  All instances of other
> SSL-enabled servers out there, except nginx, default to some variant of
> DEFAULT:!LOW:... or HIGH:MEDIUM:....  The proposal here is essentially
> to disable MEDIUM ciphers by default, which is explicitly advised
> against in the Postfix and Dovecot documentation, for example.

Doesn't seem like a great idea then.  I assume that if left to its own
devices, PG presently selects some MEDIUM-level cipher by default?  If so,
it sounds like this change amounts to imposing a performance penalty for
SSL connections by fiat.  On the other hand, if we select a HIGH cipher by
default, then aren't we just refusing to let clients who explicitly ask
for a MEDIUM cipher have one?  Either way, I'd want to see a pretty darn
airtight rationale for that, and there sure isn't one in this thread
so far.

The part of the patch that removes @STRENGTH seems plausible, though,
if Marko is correct that that's effectively overriding a hand-tailored
ordering.

In the end I wonder why our default isn't just "DEFAULT".  Anybody who
thinks that's an inappropriate default should be lobbying the OpenSSL
folk, not us, I should think.
        regards, tom lane

On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Any other opinions on this out there?  All instances of other
> > SSL-enabled servers out there, except nginx, default to some variant of
> > DEFAULT:!LOW:... or HIGH:MEDIUM:....  The proposal here is essentially
> > to disable MEDIUM ciphers by default, which is explicitly advised
> > against in the Postfix and Dovecot documentation, for example.
> 
> Doesn't seem like a great idea then.

First, if there is explicit wish to keep RC4/SEED in play, I'm fine
with "HIGH:MEDIUM:!aNULL" as new default.  Clarity-wise, it's still
much better than current value.  And this value will result *exactly*
same list in same order as current value.


But please don't look into SMTP/IMAP world for sane defaults,
their situation is quite different:

* Lot's of old and crap mail clients around (usually named Outlook).
* They use aNULL ciphers for "opportunistic" SSL.
* They use aNULL ciphers because CA-less certs.

If you need aNULL enabled anyway, there is no point in "secure" ciphers.

> I assume that if left to its own
> devices, PG presently selects some MEDIUM-level cipher by default?  If so,
> it sounds like this change amounts to imposing a performance penalty for
> SSL connections by fiat.  On the other hand, if we select a HIGH cipher by
> default, then aren't we just refusing to let clients who explicitly ask
> for a MEDIUM cipher have one?  Either way, I'd want to see a pretty darn
> airtight rationale for that, and there sure isn't one in this thread
> so far.

Performance penalty can happen for clients that support only RC4 and 3DES,
and prefer RC4 currently.  3DES is slow cipher, so falling back to it
would be noticeable.

According to ssllabs.com, Java 6 does prefer RC4, but it would fall back
to AES, which is fast cipher.  Java 7 prefers AES.

OpenSSL has always used AES, so no change there.

I know that SChannel SSL library in Windows XP (and earlier) is such
RC4+3DES only implementation, but I have not heard about anything
using it to connect to Postgres.

Also I have not heard about any Postgres clients actually allowing
to configure ciphers, so my impression all client libraries
use defaults, which usually prefer AES anyway.

> The part of the patch that removes @STRENGTH seems plausible, though,
> if Marko is correct that that's effectively overriding a hand-tailored
> ordering.
> 
> In the end I wonder why our default isn't just "DEFAULT".  Anybody who
> thinks that's an inappropriate default should be lobbying the OpenSSL
> folk, not us, I should think.

It's easy to see why - then every Postgres admin who wants SSL *must*
configure the suite.  The "ALL:!aNULL:!eNULL" default is clearly
a library default, which does not know in what situation it is used,
geared at max compatibility.

It's especially bad choice because it will look fine to people
unfamiliar with OpenSSL internal nuances.  As seen in this thread.

My goal is to have default which will be secure by default,
and give rough impression what it is about.

-----------------------------------------------------

Hm, looking at Java suites, I notice a problem that is due to bug
in OpenSSL default cipher order - it orders 3DES before AES128.

So if we give priority to server cipher order and client does
not accept AES256 (like Java 6/7), 3DES will be picked.

This is indeed bug that should be fixed on OpenSSL side, but seems
we cannot wait for their fix...

So my new proposal would be to pick one from following defaults:

1) HIGH:+3DES:!aNULL - disables RC4, orders 3DES last.

2) HIGH:MEDIUM:+3DES:!aNULL - no suite changes from current one,  except 3DES is ordered last.

+3DES reorders already picked 3DES suites to the end.  As my
impression is that no clients ever have actually used 3DES,
it's fine to use !3DES there.  It's clearer too.  But if max
compatibility is goal, then +3DES is better.

It's not as nice and simple as I hoped though. :(

-- 
marko

PS.  Use "openssl ciphers -v 'HIGH:...' > file" and "diff -u"
on files to see changes in different values.

On Thu, Dec 12, 2013 at 01:33:57PM +0100, Magnus Hagander wrote:
> On Thu, Dec 12, 2013 at 11:30 AM, Marko Kreen <markokr@gmail.com> wrote:
> > On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote:
> > I know that SChannel SSL library in Windows XP (and earlier) is such
> > RC4+3DES only implementation, but I have not heard about anything
> > using it to connect to Postgres.
> >
> > Also I have not heard about any Postgres clients actually allowing
> > to configure ciphers, so my impression all client libraries
> > use defaults, which usually prefer AES anyway.
> >
>
> I don't know, but I would assume that npgsql which sit on top of dotnet,
> would sit on top of schannel in the end.

Probably yes.

> That said, this is XP and earlier, right? Newer versions of Windows have
> better defaults?

Yes, since Vista it supports AES:

  http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx

> > So my new proposal would be to pick one from following defaults:
> >
> > 1) HIGH:+3DES:!aNULL - disables RC4, orders 3DES last.
> >
> > 2) HIGH:MEDIUM:+3DES:!aNULL - no suite changes from current one,
> >    except 3DES is ordered last.
> >
> > +3DES reorders already picked 3DES suites to the end.  As my
> > impression is that no clients ever have actually used 3DES,
> > it's fine to use !3DES there.  It's clearer too.  But if max
> > compatibility is goal, then +3DES is better.
> >
> > It's not as nice and simple as I hoped though. :(
> >
>
> We definitely want to explain in a comment next to the default value the
> exact reasoning behind the default value, I think. That doesn't mean people
> will understand it, but it means they at least have a chance.
>
> That said, #2 seems reasonable I think, but I wouldn't object to #1 either
> :)

Although I don't think that making .NET users on XP use 3DES is a big
problem, there is also no urgent need to drop RC4, as long as all
reasonable alternatives are used first.

Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
and also adds documentation about reasoning for it.  (I tried to be
consistent there about "cipher" vs. "cipher suite", not sure whether
I succeeded.)

Summary: this default with previous server-order-first patch make sure
that MEDIUM ciphers are never picked accidentally (eg. the bad default
in Java 6), but only when explicitly requested or when only alternative
is 3DES.

--
marko

On Thu, 2013-12-12 at 12:30 +0200, Marko Kreen wrote:
> First, if there is explicit wish to keep RC4/SEED in play, I'm fine
> with "HIGH:MEDIUM:!aNULL" as new default.  Clarity-wise, it's still
> much better than current value.  And this value will result *exactly*
> same list in same order as current value.

If we have to make a change, I'd go for that, but I'm not convinced that
this is necessarily clearer.

On Thu, Dec 12, 2013 at 09:18:03PM -0500, Peter Eisentraut wrote:
> On Thu, 2013-12-12 at 12:30 +0200, Marko Kreen wrote:
> > First, if there is explicit wish to keep RC4/SEED in play, I'm fine
> > with "HIGH:MEDIUM:!aNULL" as new default.  Clarity-wise, it's still
> > much better than current value.  And this value will result *exactly*
> > same list in same order as current value.
> 
> If we have to make a change, I'd go for that, but I'm not convinced that
> this is necessarily clearer.

Yeah, the clarity argument is getting thinner...

And my latest patch was for HIGH:MEDIUM:+3DES:!aNULL.

I still think it's better to have positive statements there -
"gimme this and that" - instad badly-named 'DEFAULT' and then
lot's of negatives applied to it.  But it's not that straightforward
anymore - the "+3DES" breaks the "leave everything to OpenSSL" angle.

But we do need to change default suite list to have one that works
well with prefer-server-ciphers option, which means it should contain
at least the +3DES workaround.  Client that don't want AES256 are
reasonable as AES256 does not have any practical advantages over AES128.

I don't think just reverting the default is good idea - we should then
add documentation to option that "if you flip this, add such fixes
to cipher list".  Which seems silly.

And not documenting anything and just leaving matters to admins
seems bad idea too - they are not in better position to do such
research than we are now.

So I think we can pick good default, now, and everybody will benefit.


For fun, how to go overboard on the issue - Mozilla recommendations
for TLS setup on their infrastructure:
 https://wiki.mozilla.org/Security/Server_Side_TLS

It also discusses various issues with TLS, so it's good read.

-- 
marko

>>>>> "MK" == Marko Kreen <markokr@gmail.com> writes:
>>>>> "PE" == Peter Eisentraut <peter_e@gmx.net> writes:

MK>> Well, we should - the DEFAULT is clearly a client-side default
MK>> for compatibility only.  No server should ever run with it.

PE> Any other opinions on this out there?

For reference, see:
 https://wiki.mozilla.org/Security/Server_Side_TLS

for the currently suggested suite for TLS servers.

That is:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:
ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:
ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:
DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:
DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:
AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:
AES128:AES256:RC4-SHA:HIGH:
!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

The page explains why.

But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
for some.  And RC4, perhaps, also should be !ed.

And if anyone wants Kerberos tls-authentication, one could add
KRB5-DES-CBC3-SHA, but that is ssl3-only.

Once salsa20-poly1305 lands in openssl, that should be added to the
start of the list.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

On Sun, Dec 15, 2013 at 5:10 PM, James Cloos <cloos@jhcloos.com> wrote:
> For reference, see:
>
>   https://wiki.mozilla.org/Security/Server_Side_TLS
>
> for the currently suggested suite for TLS servers.
...
> But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
> for some.  And RC4, perhaps, also should be !ed.
>
> And if anyone wants Kerberos tls-authentication, one could add
> KRB5-DES-CBC3-SHA, but that is ssl3-only.
>
> Once salsa20-poly1305 lands in openssl, that should be added to the
> start of the list.

I'm starting to think we should just leave this well enough alone.  We
can't seem to find two people with the same idea of what would be
better than what we have now.  And of course the point of making it a
setting in the first place is that each person can set it to whatever
they deem best.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote:
> On Sun, Dec 15, 2013 at 5:10 PM, James Cloos <cloos@jhcloos.com> wrote:
> > For reference, see:
> >
> >   https://wiki.mozilla.org/Security/Server_Side_TLS
> >
> > for the currently suggested suite for TLS servers.
> ...
> > But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
> > for some.  And RC4, perhaps, also should be !ed.
> >
> > And if anyone wants Kerberos tls-authentication, one could add
> > KRB5-DES-CBC3-SHA, but that is ssl3-only.
> >
> > Once salsa20-poly1305 lands in openssl, that should be added to the
> > start of the list.
> 
> I'm starting to think we should just leave this well enough alone.  We
> can't seem to find two people with the same idea of what would be
> better than what we have now.  And of course the point of making it a
> setting in the first place is that each person can set it to whatever
> they deem best.

Yes, I am seeing that too.  Can we agree on one that is _better_ than
what we have now, even if we can't agree on a _best_ one?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On 18/12/13 05:26, Bruce Momjian wrote:
> On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote:
>> On Sun, Dec 15, 2013 at 5:10 PM, James Cloos <cloos@jhcloos.com> wrote:
>>> For reference, see:
>>>
>>>    https://wiki.mozilla.org/Security/Server_Side_TLS
>>>
>>> for the currently suggested suite for TLS servers.
>> ...
>>> But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
>>> for some.  And RC4, perhaps, also should be !ed.
>>>
>>> And if anyone wants Kerberos tls-authentication, one could add
>>> KRB5-DES-CBC3-SHA, but that is ssl3-only.
>>>
>>> Once salsa20-poly1305 lands in openssl, that should be added to the
>>> start of the list.
>> I'm starting to think we should just leave this well enough alone.  We
>> can't seem to find two people with the same idea of what would be
>> better than what we have now.  And of course the point of making it a
>> setting in the first place is that each person can set it to whatever
>> they deem best.
> Yes, I am seeing that too.  Can we agree on one that is _better_ than
> what we have now, even if we can't agree on a _best_ one?
>
Because various security agencies probably have people trying to confuse 
the issue, and acting to discourage strong encryption...

Possibly choose the one computationally most difficult to crack - but 
even then, we don't know what algorithms they are using, which are bound 
to be very sophisticated.

I've a horrible feeling, that I'm not paranoid enough!


Cheers,
Gavin

On 12/17/2013 08:26 AM, Bruce Momjian wrote:
> On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote:
>> On Sun, Dec 15, 2013 at 5:10 PM, James Cloos <cloos@jhcloos.com> wrote:
>>> For reference, see:
>>>
>>>    https://wiki.mozilla.org/Security/Server_Side_TLS
>>>
>>> for the currently suggested suite for TLS servers.
>> ...
>>> But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
>>> for some.  And RC4, perhaps, also should be !ed.
>>>
>>> And if anyone wants Kerberos tls-authentication, one could add
>>> KRB5-DES-CBC3-SHA, but that is ssl3-only.
>>>
>>> Once salsa20-poly1305 lands in openssl, that should be added to the
>>> start of the list.
>>
>> I'm starting to think we should just leave this well enough alone.  We
>> can't seem to find two people with the same idea of what would be
>> better than what we have now.  And of course the point of making it a
>> setting in the first place is that each person can set it to whatever
>> they deem best.
>
> Yes, I am seeing that too.  Can we agree on one that is _better_ than
> what we have now, even if we can't agree on a _best_ one?
>

Agreed. I would note that what is being proposed is a default that helps 
those of us (myself included) that do not know ciphers in and out, start 
with reasonable expectation of protection. This is a GUC so it can be 
modified to suite personal taste.

-- 
Adrian Klaver
adrian.klaver@gmail.com

On Sun, Dec 15, 2013 at 05:10:38PM -0500, James Cloos wrote:
> >>>>> "MK" == Marko Kreen <markokr@gmail.com> writes:
> >>>>> "PE" == Peter Eisentraut <peter_e@gmx.net> writes:

> PE> Any other opinions on this out there?
> 
> For reference, see:
> 
>   https://wiki.mozilla.org/Security/Server_Side_TLS
> 
> for the currently suggested suite for TLS servers.
> 
> That is:
> 
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:
> DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:
> ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:
> ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:
> ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:
> DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:
> DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:
> AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:
> AES128:AES256:RC4-SHA:HIGH:
> !aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

This is example of ciphersuite list for people who have special
requirements and care about tracking yearly changes in SSL landscape.
And can deploy config changes relatively fast.

This discussion is about Postgres default suite which cannot and should
not be periodically changed, for people who leave Postgres settings
to defaults and expect setup work well.

We would like to leave as much as possible to OpenSSL, but not more.

Looking at the history of OpenSSL, their default order has been
good, except the 3DES vs. AES128 priority.

Looking into future, I guess following events are likely:

- RC4 gets practially broken and/or removed from TLS (draft-popov-tls-prohibiting-rc4-01).

- New ciphersuites: Salsa/Chacha (256-bit key).

- New modes: CCM (RFC6655, draft-mcgrew-tls-aes-ccm-ecc-07), other ciphers with GCM, new AEAD constructs.

- CBC mode fixes: pad-mac-encrypt, pad-encrypt-mac.  Those may be implemented with TLS extensions, so no new
ciphersuites.

RC4 situation - the 'MEDIUM' in my proposal communicates
that not all ciphers are best, and prefer-server-order
makes sure it is selected as last resort.  So that is solved.

New ciphersuites - if we want to select fastest from "secure"
suites we need to change configuration periodically
(RC4->AES128-CBC->AES128-GCM->SALSA) and I don't think Postgres
should bother we that.  So I think it's better to leave ordering
new ciphers to OpenSSL, and people who have special requirements
can worry about best configuration for specific stack they are running.

-- 
marko

On Tue, Dec 17, 2013 at 11:26:13AM -0500, Bruce Momjian wrote:
> On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote:
> > I'm starting to think we should just leave this well enough alone.  We
> > can't seem to find two people with the same idea of what would be
> > better than what we have now.  And of course the point of making it a
> > setting in the first place is that each person can set it to whatever
> > they deem best.
> 
> Yes, I am seeing that too.  Can we agree on one that is _better_ than
> what we have now, even if we can't agree on a _best_ one?

To recap - old settings are:
 DEFAULT:!LOW:!EXP:!MD5:@STRENGTH prefer-client-order

new proposal is:
 HIGH:MEDIUM:+3DES:!aNULL prefer-server-order

This is better than old state in following aspects:

- First, it does not remove any ciphers compared to current list.  So anything that could connect previously can
connectstill.
 

- Clearer to people not intimately familiar with OpenSSL and TLS. In particular, the 'MEDIUM' communicates that some
lesssecure ciphers are enabled (RC4).
 

- Fixes the 3DES ordering.  OpenSSL default list is ordered roughly by (key-bits, ECDHE, DHE, plain RSA).  3DES has
168-bitkey so it appears before 128-bit ciphers, although it offers around 112-bit actual security.  This problem
existsalready with existing Postgres versions: if you set suite to "AES128:3DES", then libpq-based clients will use
3DES.

When combined with prefer-server-order, it has following benefits:

- Clarity: admin can look at configured cipher order and make reasonable guesses what will be used.

- Actually activates the 3DES fix.  Although non-libpq/OpenSSL based clients did used their own order, OpenSSL-based
clientdid have same order problem in client-side.
 

- Old clients that did prefer RC4 will use it as last resort only, when only alternative is 3DES.

- Old clients that did prefer non-DHE ciphers will use DHE ciphers if available.


One goal the new settings *do not* try to achieve is to pick the absolutely
fastest cipher from the secure ones.  Old settings did not it either,
when speaking of libpq clients.  Java did try from client-side, but
as a result old deployed versions use now insecure settings.  I think
it's best when the default settings prefer security over speed,
everyone who is has special requirements speed-wise - "AES is slow" -
can tune list themselves.


So, does anyone have reasons not to use proposed new default?

-- 
marko

On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
> Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
> and also adds documentation about reasoning for it.

This is the last pending SSL cleanup related patch:
 https://commitfest.postgresql.org/action/patch_view?id=1310

Peter, you have claimed it as committer, do you see any remaining
issues with it?

-- 
marko

On 2/2/14, 7:16 AM, Marko Kreen wrote:
> On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
>> Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
>> and also adds documentation about reasoning for it.
> 
> This is the last pending SSL cleanup related patch:
> 
>   https://commitfest.postgresql.org/action/patch_view?id=1310
> 
> Peter, you have claimed it as committer, do you see any remaining
> issues with it?

I'm OK with this change on the principle of clarifying and refining the
existing default.  But after inspecting the expanded cipher list with
the "openssl cipher" tool, I noticed that the new default re-enabled MD5
ciphers.  Was that intentional?

On Sat, Feb 22, 2014 at 08:31:14PM -0500, Peter Eisentraut wrote:
> On 2/2/14, 7:16 AM, Marko Kreen wrote:
> > On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
> >> Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
> >> and also adds documentation about reasoning for it.
> > 
> > This is the last pending SSL cleanup related patch:
> > 
> >   https://commitfest.postgresql.org/action/patch_view?id=1310
> > 
> > Peter, you have claimed it as committer, do you see any remaining
> > issues with it?
> 
> I'm OK with this change on the principle of clarifying and refining the
> existing default.  But after inspecting the expanded cipher list with
> the "openssl cipher" tool, I noticed that the new default re-enabled MD5
> ciphers.  Was that intentional?

Yes, kind of.  First note that only RC4-MD5 is SSLv3+,
rest are SSLv2-only suites.

There are 2 points relevant about RC4-MD5:

* Main reason MEDIUM was added is to get RC4, for compatibility.

* ALthough MD5 is broken, TLS protocol uses HMAC-MD5 which is not. So RC4-MD5 is weak suite not because of MD5 but
becauseof RC4.
 

My conclusion is it's unnecessary to add '!MD5' to MEDIUM as
that would not actually make things more secure.   Instead
'MEDIUM' alone is enough to show that user will not get
state-of-the-art-only suites.

-- 
marko

committed