Re: [HACKERS] SSL: better default ciphersuite

2014-02-24 Thread Peter Eisentraut
committed


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


Re: [HACKERS] SSL: better default ciphersuite

2014-02-23 Thread Marko Kreen
On Sat, Feb 22, 2014 at 08:31:14PM -0500, Peter Eisentraut wrote:
 On 2/2/14, 7:16 AM, Marko Kreen wrote:
  On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
  Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
  and also adds documentation about reasoning for it.
  
  This is the last pending SSL cleanup related patch:
  
https://commitfest.postgresql.org/action/patch_view?id=1310
  
  Peter, you have claimed it as committer, do you see any remaining
  issues with it?
 
 I'm OK with this change on the principle of clarifying and refining the
 existing default.  But after inspecting the expanded cipher list with
 the openssl cipher tool, I noticed that the new default re-enabled MD5
 ciphers.  Was that intentional?

Yes, kind of.  First note that only RC4-MD5 is SSLv3+,
rest are SSLv2-only suites.

There are 2 points relevant about RC4-MD5:

* Main reason MEDIUM was added is to get RC4, for compatibility.

* ALthough MD5 is broken, TLS protocol uses HMAC-MD5 which is not.
  So RC4-MD5 is weak suite not because of MD5 but because of RC4.

My conclusion is it's unnecessary to add '!MD5' to MEDIUM as
that would not actually make things more secure.   Instead
'MEDIUM' alone is enough to show that user will not get
state-of-the-art-only suites.

-- 
marko



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


Re: [HACKERS] SSL: better default ciphersuite

2014-02-22 Thread Peter Eisentraut
On 2/2/14, 7:16 AM, Marko Kreen wrote:
 On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
 Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
 and also adds documentation about reasoning for it.
 
 This is the last pending SSL cleanup related patch:
 
   https://commitfest.postgresql.org/action/patch_view?id=1310
 
 Peter, you have claimed it as committer, do you see any remaining
 issues with it?

I'm OK with this change on the principle of clarifying and refining the
existing default.  But after inspecting the expanded cipher list with
the openssl cipher tool, I noticed that the new default re-enabled MD5
ciphers.  Was that intentional?




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


Re: [HACKERS] SSL: better default ciphersuite

2014-02-02 Thread Marko Kreen
On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
 Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
 and also adds documentation about reasoning for it.

This is the last pending SSL cleanup related patch:

  https://commitfest.postgresql.org/action/patch_view?id=1310

Peter, you have claimed it as committer, do you see any remaining
issues with it?

-- 
marko



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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-17 Thread Robert Haas
On Sun, Dec 15, 2013 at 5:10 PM, James Cloos cl...@jhcloos.com wrote:
 For reference, see:

   https://wiki.mozilla.org/Security/Server_Side_TLS

 for the currently suggested suite for TLS servers.
...
 But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
 for some.  And RC4, perhaps, also should be !ed.

 And if anyone wants Kerberos tls-authentication, one could add
 KRB5-DES-CBC3-SHA, but that is ssl3-only.

 Once salsa20-poly1305 lands in openssl, that should be added to the
 start of the list.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-17 Thread Bruce Momjian
On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote:
 On Sun, Dec 15, 2013 at 5:10 PM, James Cloos cl...@jhcloos.com wrote:
  For reference, see:
 
https://wiki.mozilla.org/Security/Server_Side_TLS
 
  for the currently suggested suite for TLS servers.
 ...
  But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
  for some.  And RC4, perhaps, also should be !ed.
 
  And if anyone wants Kerberos tls-authentication, one could add
  KRB5-DES-CBC3-SHA, but that is ssl3-only.
 
  Once salsa20-poly1305 lands in openssl, that should be added to the
  start of the list.
 
 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?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + Everyone has their own god. +


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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-17 Thread Adrian Klaver

On 12/17/2013 08:26 AM, Bruce Momjian wrote:

On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote:

On Sun, Dec 15, 2013 at 5:10 PM, James Cloos cl...@jhcloos.com wrote:

For reference, see:

   https://wiki.mozilla.org/Security/Server_Side_TLS

for the currently suggested suite for TLS servers.

...

But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
for some.  And RC4, perhaps, also should be !ed.

And if anyone wants Kerberos tls-authentication, one could add
KRB5-DES-CBC3-SHA, but that is ssl3-only.

Once salsa20-poly1305 lands in openssl, that should be added to the
start of the list.


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?



Agreed. I would note that what is being proposed is a default that helps 
those of us (myself included) that do not know ciphers in and out, start 
with reasonable expectation of protection. This is a GUC so it can be 
modified to suite personal taste.


--
Adrian Klaver
adrian.kla...@gmail.com


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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-17 Thread Marko Kreen
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



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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-17 Thread Gavin Flower

On 18/12/13 05:26, Bruce Momjian wrote:

On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote:

On Sun, Dec 15, 2013 at 5:10 PM, James Cloos cl...@jhcloos.com wrote:

For reference, see:

   https://wiki.mozilla.org/Security/Server_Side_TLS

for the currently suggested suite for TLS servers.

...

But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
for some.  And RC4, perhaps, also should be !ed.

And if anyone wants Kerberos tls-authentication, one could add
KRB5-DES-CBC3-SHA, but that is ssl3-only.

Once salsa20-poly1305 lands in openssl, that should be added to the
start of the list.

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?

Because various security agencies probably have people trying to confuse 
the issue, and acting to discourage strong encryption...


Possibly choose the one computationally most difficult to crack - but 
even then, we don't know what algorithms they are using, which are bound 
to be very sophisticated.


I've a horrible feeling, that I'm not paranoid enough!


Cheers,
Gavin


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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-17 Thread Marko Kreen
On Sun, Dec 15, 2013 at 05:10:38PM -0500, James Cloos wrote:
  MK == Marko Kreen mark...@gmail.com writes:
  PE == Peter Eisentraut pete...@gmx.net writes:

 PE Any other opinions on this out there?
 
 For reference, see:
 
   https://wiki.mozilla.org/Security/Server_Side_TLS
 
 for the currently suggested suite for TLS servers.
 
 That is:
 
 ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:
 ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:
 DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:
 ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:
 ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:
 ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:
 DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:
 DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:
 AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:
 AES128:AES256:RC4-SHA:HIGH:
 !aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

This is example of ciphersuite list for people who have special
requirements and care about tracking yearly changes in SSL landscape.
And can deploy config changes relatively fast.

This discussion is about Postgres default suite which cannot and should
not be periodically changed, for people who leave Postgres settings
to defaults and expect setup work well.

We would like to leave as much as possible to OpenSSL, but not more.

Looking at the history of OpenSSL, their default order has been
good, except the 3DES vs. AES128 priority.

Looking into future, I guess following events are likely:

- RC4 gets practially broken and/or removed from TLS
  (draft-popov-tls-prohibiting-rc4-01).

- New ciphersuites: Salsa/Chacha (256-bit key).

- New modes: CCM (RFC6655, draft-mcgrew-tls-aes-ccm-ecc-07),
  other ciphers with GCM, new AEAD constructs.

- CBC mode fixes: pad-mac-encrypt, pad-encrypt-mac.  Those may
  be implemented with TLS extensions, so no new ciphersuites.

RC4 situation - the 'MEDIUM' in my proposal communicates
that not all ciphers are best, and prefer-server-order
makes sure it is selected as last resort.  So that is solved.

New ciphersuites - if we want to select fastest from secure
suites we need to change configuration periodically
(RC4-AES128-CBC-AES128-GCM-SALSA) and I don't think Postgres
should bother we that.  So I think it's better to leave ordering
new ciphers to OpenSSL, and people who have special requirements
can worry about best configuration for specific stack they are running.

-- 
marko



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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-15 Thread James Cloos
 MK == Marko Kreen mark...@gmail.com writes:
 PE == Peter Eisentraut pete...@gmx.net writes:

MK Well, we should - the DEFAULT is clearly a client-side default
MK for compatibility only.  No server should ever run with it.

PE Any other opinions on this out there?

For reference, see:

  https://wiki.mozilla.org/Security/Server_Side_TLS

for the currently suggested suite for TLS servers.

That is:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:
ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:
ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:
DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:
DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:
AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:
AES128:AES256:RC4-SHA:HIGH:
!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

The page explains why.

But for pgsql, I'd leave off the !PSK; pre-shared keys may prove useful
for some.  And RC4, perhaps, also should be !ed.

And if anyone wants Kerberos tls-authentication, one could add
KRB5-DES-CBC3-SHA, but that is ssl3-only.

Once salsa20-poly1305 lands in openssl, that should be added to the
start of the list.

-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6


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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-13 Thread Marko Kreen
On Thu, Dec 12, 2013 at 09:18:03PM -0500, Peter Eisentraut wrote:
 On Thu, 2013-12-12 at 12:30 +0200, Marko Kreen wrote:
  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.
 
 If we have to make a change, I'd go for that, but I'm not convinced that
 this is necessarily clearer.

Yeah, the clarity argument is getting thinner...

And my latest patch was for HIGH:MEDIUM:+3DES:!aNULL.

I still think it's better to have positive statements there -
gimme this and that - instad badly-named 'DEFAULT' and then
lot's of negatives applied to it.  But it's not that straightforward
anymore - the +3DES breaks the leave everything to OpenSSL angle.

But we do need to change default suite list to have one that works
well with prefer-server-ciphers option, which means it should contain
at least the +3DES workaround.  Client that don't want AES256 are
reasonable as AES256 does not have any practical advantages over AES128.

I don't think just reverting the default is good idea - we should then
add documentation to option that if you flip this, add such fixes
to cipher list.  Which seems silly.

And not documenting anything and just leaving matters to admins
seems bad idea too - they are not in better position to do such
research than we are now.

So I think we can pick good default, now, and everybody will benefit.


For fun, how to go overboard on the issue - Mozilla recommendations
for TLS setup on their infrastructure:

  https://wiki.mozilla.org/Security/Server_Side_TLS

It also discusses various issues with TLS, so it's good read.

-- 
marko



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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-12 Thread Marko Kreen
On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote:
 Peter Eisentraut pete...@gmx.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.



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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-12 Thread Magnus Hagander
On Thu, Dec 12, 2013 at 11:30 AM, Marko Kreen mark...@gmail.com wrote:

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


Yeah, aNULL is definitely pointless.


 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.


I don't know, but I would assume that npgsql which sit on top of dotnet,
would sit on top of schannel in the end.

That said, this is XP and earlier, right? Newer versions of Windows have
better defaults?


 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. :(


We definitely want to explain in a comment next to the default value the
exact reasoning behind the default value, I think. That doesn't mean people
will understand it, but it means they at least have a chance.

That said, #2 seems reasonable I think, but I wouldn't object to #1 either
:)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


Re: [HACKERS] SSL: better default ciphersuite

2013-12-12 Thread Marko Kreen
On Thu, Dec 12, 2013 at 01:33:57PM +0100, Magnus Hagander wrote:
 On Thu, Dec 12, 2013 at 11:30 AM, Marko Kreen mark...@gmail.com wrote:
  On Wed, Dec 11, 2013 at 10:08:44PM -0500, Tom Lane wrote:
  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.
 
 
 I don't know, but I would assume that npgsql which sit on top of dotnet,
 would sit on top of schannel in the end.

Probably yes.

 That said, this is XP and earlier, right? Newer versions of Windows have
 better defaults?

Yes, since Vista it supports AES:

  
http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx

  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. :(
 
 
 We definitely want to explain in a comment next to the default value the
 exact reasoning behind the default value, I think. That doesn't mean people
 will understand it, but it means they at least have a chance.
 
 That said, #2 seems reasonable I think, but I wouldn't object to #1 either
 :)

Although I don't think that making .NET users on XP use 3DES is a big
problem, there is also no urgent need to drop RC4, as long as all
reasonable alternatives are used first.

Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
and also adds documentation about reasoning for it.  (I tried to be
consistent there about cipher vs. cipher suite, not sure whether
I succeeded.)

Summary: this default with previous server-order-first patch make sure
that MEDIUM ciphers are never picked accidentally (eg. the bad default
in Java 6), but only when explicitly requested or when only alternative
is 3DES.

-- 
marko

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 8896988..2755f55 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -876,12 +876,62 @@ include 'filename'
   /indexterm
   listitem
para
-Specifies a list of acronymSSL/ ciphers that are allowed to be
+Specifies a list of acronymSSL/ cipher suites that are allowed to be
 used on secure connections.  See
 the citerefentryrefentrytitleciphers//citerefentry manual page
 in the applicationOpenSSL/ package for the syntax of this setting
-and a list of supported values.  The default value is usually
-reasonable, unless you have specific security requirements.
+and a list of supported values.  The default value is
+literalHIGH:MEDIUM:+3DES:!aNULL/.  It is usually reasonable,
+unless you have specific security requirements.
+   /para
+   para
+Explanation for default value:
+variablelist
+ varlistentry
+  termliteralHIGH/literal/term
+  listitem
+   para
+Cipher suites that use ciphers from literalHIGH/ section.
+(AES, Camellia, 3DES)
+   /para
+  /listitem
+ /varlistentry
+ varlistentry
+  termliteralMEDIUM/literal/term
+  listitem
+   para
+Cipher suites that use ciphers from literalMEDIUM/ section.
+(RC4, SEED)
+   /para
+  /listitem
+ /varlistentry
+ varlistentry
+  termliteral+3DES/literal/term
+  listitem
+   para
+OpenSSL default order for literalHIGH/ is problematic as it orders 3DES
+higher than AES128.  This is wrong as 3DES offers less security than AES128
+and it is also much slower.  literal+3DES/ reorders it after all other
+literalHIGH/ and literalMEDIUM/ ciphers.
+   /para
+  /listitem
+ /varlistentry
+ varlistentry
+  termliteral!aNULL/literal/term
+  listitem
+   para
+Disables anonymous cipher suites that do no authentication.
+Such cipher suites are vulnerable to a man in the middle
+attack and so should not be used.
+   /para
+  /listitem
+ /varlistentry
+/variablelist
+Available cipher suite details will vary across OpenSSL versions, these values
+are taken from applicationOpenSSL/ 1.0.1.  Use command
+literalopenssl ciphers -v 'HIGH:MEDIUM:+3DES:!aNULL'/literal
+to see actual details 

Re: [HACKERS] SSL: better default ciphersuite

2013-12-12 Thread Peter Eisentraut
On Thu, 2013-12-12 at 12:30 +0200, Marko Kreen wrote:
 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.

If we have to make a change, I'd go for that, but I'm not convinced that
this is necessarily clearer.



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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-11 Thread Peter Eisentraut
On Fri, 2013-11-29 at 18:43 +0200, Marko Kreen wrote:
 Well, we should - the DEFAULT is clearly a client-side default
 for compatibility only.  No server should ever run with it.

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.



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


Re: [HACKERS] SSL: better default ciphersuite

2013-12-11 Thread Tom Lane
Peter Eisentraut pete...@gmx.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.  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.

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.

regards, tom lane


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


Re: [HACKERS] SSL: better default ciphersuite

2013-11-29 Thread Peter Eisentraut
On Fri, 2013-11-15 at 01:11 +0200, Marko Kreen wrote:
 Attached patch changes the default ciphersuite to
 
 HIGH:!aNULL
 
 instead of old
 
 DEFAULT:!LOW:!EXP:!MD5:@STRENGTH
 
 where DEFAULT is a shortcut for ALL:!aNULL:!eNULL.

 Main goal is to leave low-level ciphersuite details to OpenSSL guys
 and give clear impression to Postgres admins what it is about.

If we want to leave the details of the ciphers to OpenSSL, I think we
shouldn't be second-guessing their judgement of what a reasonable
default is.

I checked Apache mod_ssl and Postfix, and even though they are
configuring this slightly differently, I think their defaults end up
being about the same as what PostgreSQL currently has.

https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite
http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers

 HIGH:
   Contains only secure and well-researched algorithms.
 
 !aNULL
   Needed to disable suites that do not authenticate server.
   DEFAULT includes !aNULL by default.

Wouldn't HIGH exclude aNULL also?  (If not, what about eNULL?)

 !MD5
   This affects only one suite: DES-CBC3-MD5, which is available only
   for SSL2 connections.  So it would only pollute the default value.

I think this is only there for political correctness.

 @STRENGTH
   The OpenSSL cipher list is already sorted by humans,
   it's unlikely that mechanical sort would improve things.
   Also the existence of this value in old list is rather
   dubious, as server cipher order was never respected anyway.

Aren't you proposing to change that?




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


Re: [HACKERS] SSL: better default ciphersuite

2013-11-29 Thread Marko Kreen
On Fri, Nov 29, 2013 at 09:18:49AM -0500, Peter Eisentraut wrote:
 On Fri, 2013-11-15 at 01:11 +0200, Marko Kreen wrote:
  Attached patch changes the default ciphersuite to
  
  HIGH:!aNULL
  
  instead of old
  
  DEFAULT:!LOW:!EXP:!MD5:@STRENGTH
  
  where DEFAULT is a shortcut for ALL:!aNULL:!eNULL.
 
  Main goal is to leave low-level ciphersuite details to OpenSSL guys
  and give clear impression to Postgres admins what it is about.
 
 If we want to leave the details of the ciphers to OpenSSL, I think we
 shouldn't be second-guessing their judgement of what a reasonable
 default is.

Well, we should - the DEFAULT is clearly a client-side default
for compatibility only.  No server should ever run with it.

OTOH, the whole point of HIGH:!aNULL is to leave low-level
ciphersuite details to OpenSSL guys - as a Postgres admin
is not clear to me that

   DEFAULT:!LOW:!EXP:!MD5:@STRENGTH

is actually good suite.  It contains DEFAULT plus several
fixes which show that DEFAULT is not good enough.  Why all that?

Admin would need to do lot research to see what it is about.
Another aspect is that the HIGH:!aNULL is more futureproof
as default, current default has needed fixes (!LOW:!EXP:!MD5)
and would need more fixes in the future (RC4).

Also note that OpenSSL has only one ordered cipher list - ALL.
All other tokens simply walk that list while keeping the order.
So it's not like not using DEFAULT would somehow lose important
details about order.

 I checked Apache mod_ssl and Postfix, and even though they are
 configuring this slightly differently, I think their defaults end up
 being about the same as what PostgreSQL currently has.
 
 https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite
 http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers

My proposal is inspired by nginx default:

  http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers

  HIGH:
Contains only secure and well-researched algorithms.
  
  !aNULL
Needed to disable suites that do not authenticate server.
DEFAULT includes !aNULL by default.
 
 Wouldn't HIGH exclude aNULL also?  (If not, what about eNULL?)

HIGH/MEDIUM/LOW/ALL are only about cipher strength so they don't
exclude aNULL.  HIGH does exclude eNULL because eNULL ciphers
are not strong enough...

  !MD5
This affects only one suite: DES-CBC3-MD5, which is available only
for SSL2 connections.  So it would only pollute the default value.
 
 I think this is only there for political correctness.

But it's noise so should be removed.

  @STRENGTH
The OpenSSL cipher list is already sorted by humans,
it's unlikely that mechanical sort would improve things.
Also the existence of this value in old list is rather
dubious, as server cipher order was never respected anyway.
 
 Aren't you proposing to change that?

No, ALL and subsets of it (HIGH) are already ordered by @STRENGTH.
@STRENGTH as token is only useful if admin does complex filtering by
other parameters then wants to reorder it again by cipher strength.

Eg. an other default I've considered is:

  EECDH+HIGH:EDH+HIGH:@STRENGTH

which enforces ephemeral key use.  @STRENGTH is actually useful there,
as without it ECDHE-AES128 would be preferred to DHE-AES256.

But it exposes unnecessary complexity to database admins who
are not particularly familiar with TLS and OpenSSL internals.
So I think the HIGH:!aNULL is better default as it's simpler.
And ephemeral keys are preferred anyway.

-- 
marko


PS. @STRENGTH and OpenSSL default order in general has problem
that it orders 3DES (168-bit key) before AES128, but 3DES
strength is around 112-bit only.  So crypto-wise, the
perfect default, while keeping compatibility, would be:

  EECDH+HIGH:EDH+HIGH:@STRENGTH:+3DES

but it's getting messier and messier...

PS2.  And more fragile too - admin could change +3DES to -3DES
and that would be fine, but plain '3DES' would enable aNULL suite.
So keeping '!aNULL' visible might not be bad idea.



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