Обсуждение: [PATCH 1/2] SSL: GUC option to prefer server cipher order

By default OpenSSL (and SSL/TLS in general) lets client cipher
order take priority.  This is OK for browsers where the ciphers
were tuned, but few Postgres client libraries make cipher order
configurable.  So it makes sense to make cipher order in
postgresql.conf take priority over client defaults.

This patch adds setting 'ssl_prefer_server_ciphers' which can be
turned on so that server cipher order is preferred.

The setting SSL_OP_CIPHER_SERVER_PREFERENCE appeared in
OpenSSL 0.9.7 (31 Dec 2002), not sure if #ifdef is required
for conditional compilation.
---
 doc/src/sgml/config.sgml      | 12 ++++++++++++
 src/backend/libpq/be-secure.c |  7 +++++++
 src/backend/utils/misc/guc.c  | 10 ++++++++++
 3 files changed, 29 insertions(+)

This sets up ECDH key exchange, when compiling against OpenSSL
that supports EC.  Then ECDHE-RSA and ECDHE-ECDSA ciphersuites
can be used for SSL connections.  Latter one means that EC keys
are now usable.

The reason for EC key exchange is that it's faster than DHE
and it allows to go to higher security levels where RSA will
be horribly slow.

Quick test with single-threaded client connecting repeatedly
to server on same machine, then closes connection.  Measured
is connections-per-second.

  Key             DHE     ECDHE
  RSA-1024        177.5   278.1   (x 1.56)
  RSA-2048        140.5   191.1   (x 1.36)
  RSA-4096        59.5    67.3    (x 1.13)
  ECDSA-256               280.7   (~ RSA-3072)
  ECDSA-384               128.9   (~ RSA-7680)

There is also new GUC option - ssl_ecdh_curve - that specifies
curve name used for ECDH.  It defaults to "prime256v1", which
is the most common curve in use in HTTPS.  According to NIST
should be securitywise similar to ~3072 bit RSA/DH.
(http://www.keylength.com / NIST Recommendations).

Other commonly-implemented curves are secp384r1 and secp521r1
(OpenSSL names).  The rest are not recommended as EC curves
needed to be exchanged by name and need to be explicitly
supprted by both client and server.  TLS does have free-form
curve exchange, but few client libraries implement that,
at least OpenSSL does not.

Full list can be seen with "openssl ecparam -list_curves".

It does not tune ECDH curve with key size automatically,
like DHE does.  The reason is the curve naming situation.
---
 doc/src/sgml/config.sgml      | 13 +++++++++++++
 src/backend/libpq/be-secure.c | 32 ++++++++++++++++++++++++++++++++
 src/backend/utils/misc/guc.c  | 16 ++++++++++++++++
 3 files changed, 61 insertions(+)

Marko Kreen escribió:

> By default OpenSSL (and SSL/TLS in general) lets client cipher
> order take priority.  This is OK for browsers where the ciphers
> were tuned, but few Postgres client libraries make cipher order
> configurable.  So it makes sense to make cipher order in
> postgresql.conf take priority over client defaults.
> 
> This patch adds setting 'ssl_prefer_server_ciphers' which can be
> turned on so that server cipher order is preferred.

Wouldn't it make more sense to have this enabled by default?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Wed, Nov 06, 2013 at 09:57:32PM -0300, Alvaro Herrera wrote:
> Marko Kreen escribió:
> 
> > By default OpenSSL (and SSL/TLS in general) lets client cipher
> > order take priority.  This is OK for browsers where the ciphers
> > were tuned, but few Postgres client libraries make cipher order
> > configurable.  So it makes sense to make cipher order in
> > postgresql.conf take priority over client defaults.
> > 
> > This patch adds setting 'ssl_prefer_server_ciphers' which can be
> > turned on so that server cipher order is preferred.
> 
> Wouldn't it make more sense to have this enabled by default?

Well, yes.  :)

I would even drop the GUC setting, but hypothetically there could
be some sort of backwards compatiblity concerns, so I added it
to patch and kept old default.  But if noone has strong need for it,
the setting can be removed.

-- 
marko

On Wed, Nov 06, 2013 at 09:57:32PM -0300, Alvaro Herrera wrote:
> Marko Kreen escribió:
>
> > By default OpenSSL (and SSL/TLS in general) lets client cipher
> > order take priority.  This is OK for browsers where the ciphers
> > were tuned, but few Postgres client libraries make cipher order
> > configurable.  So it makes sense to make cipher order in
> > postgresql.conf take priority over client defaults.
> >
> > This patch adds setting 'ssl_prefer_server_ciphers' which can be
> > turned on so that server cipher order is preferred.
>
> Wouldn't it make more sense to have this enabled by default?

Well, yes.  :)

I would even drop the GUC setting, but hypothetically there could
be some sort of backwards compatiblity concerns, so I added it
to patch and kept old default.  But if noone has strong need for it,
the setting can be removed.

On Thu, 2013-11-14 at 11:45 +0100, Magnus Hagander wrote:
> I think the default behaviour should be the one we recommend (which
> would be to have the server one be preferred). But I do agree with the
> requirement to have a GUC to be able to  remove it

Is there a reason why you would want to turn it off?

On Fri, Nov 29, 2013 at 09:25:02AM -0500, Peter Eisentraut wrote:
> On Thu, 2013-11-14 at 11:45 +0100, Magnus Hagander wrote:
> > I think the default behaviour should be the one we recommend (which
> > would be to have the server one be preferred). But I do agree with the
> > requirement to have a GUC to be able to  remove it
> 
> Is there a reason why you would want to turn it off?

GUC is there so old behaviour can be restored.

Why would anyone want that, I don't know.  In context of PostgreSQL,
I see no reason to prefer old behaviour.

-- 
marko

On 11/29/2013 05:43 PM, Marko Kreen wrote:
> On Fri, Nov 29, 2013 at 09:25:02AM -0500, Peter Eisentraut wrote:
>> On Thu, 2013-11-14 at 11:45 +0100, Magnus Hagander wrote:
>>> I think the default behaviour should be the one we recommend (which
>>> would be to have the server one be preferred). But I do agree with the
>>> requirement to have a GUC to be able to  remove it
>>
>> Is there a reason why you would want to turn it off?
>
> GUC is there so old behaviour can be restored.
>
> Why would anyone want that, I don't know.  In context of PostgreSQL,
> I see no reason to prefer old behaviour.

Imagine that the server is public, and anyone can connect. The server 
offers SSL protection not to protect the data in the server, since 
that's public anyway, but to protect the communication of the client. In 
that situation, it should be the client's choice what encryption to use 
(if any). This is analogous to using https on a public website.

I concur that that's pretty far-fetched. Just changing the behavior, 
with no GUC, is fine by me.

- Heikki

On Fri, Nov 29, 2013 at 05:51:28PM +0200, Heikki Linnakangas wrote:
> On 11/29/2013 05:43 PM, Marko Kreen wrote:
> >On Fri, Nov 29, 2013 at 09:25:02AM -0500, Peter Eisentraut wrote:
> >>On Thu, 2013-11-14 at 11:45 +0100, Magnus Hagander wrote:
> >>>I think the default behaviour should be the one we recommend (which
> >>>would be to have the server one be preferred). But I do agree with the
> >>>requirement to have a GUC to be able to  remove it
> >>
> >>Is there a reason why you would want to turn it off?
> >
> >GUC is there so old behaviour can be restored.
> >
> >Why would anyone want that, I don't know.  In context of PostgreSQL,
> >I see no reason to prefer old behaviour.
> 
> Imagine that the server is public, and anyone can connect. The
> server offers SSL protection not to protect the data in the server,
> since that's public anyway, but to protect the communication of the
> client. In that situation, it should be the client's choice what
> encryption to use (if any). This is analogous to using https on a
> public website.
> 
> I concur that that's pretty far-fetched. Just changing the behavior,
> with no GUC, is fine by me.

But client can control that behaviour - it just needs to specify
suites it wants and drop the rest.

So only question is that does any client have better (non-tuned?)
defaults than we can set from server.

Considering the whole HTTPS world has answered 'no' to that question
and nowadays server-controlled behaviour is preferred, I think it's
safe to change the behaviour in Postgres too.

-- 
marko

Committed your v2 patch (with default to on).  I added a small snippet
of documentation explaining that this setting is mainly for backward
compatibility.

On Thu, 2013-11-07 at 01:59 +0200, Marko Kreen wrote:
> This sets up ECDH key exchange, when compiling against OpenSSL
> that supports EC.  Then ECDHE-RSA and ECDHE-ECDSA ciphersuites
> can be used for SSL connections.  Latter one means that EC keys
> are now usable.

Committed v2.