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:


new proposal is:


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

- 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?


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to