Re: SSL: better default ciphersuite

On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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.