Re: SSL: better default ciphersuite

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 connect
still.

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

- Fixes the 3DES ordering. OpenSSL default list is ordered roughly
by (key-bits, ECDHE, DHE, plain RSA). 3DES has 168-bit key so
it appears before 128-bit ciphers, although it offers around 112-bit
actual security. This problem exists already 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 client did 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