Re: SSL: better default ciphersuite - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: SSL: better default ciphersuite
Date
Msg-id 20131217202648.GB3297@gmail.com
Whole thread Raw
In response to Re: SSL: better default ciphersuite  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: pg_rewarm status
Next
From: "MauMau"
Date:
Subject: Re: pg_rewarm status