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