[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(+)
Attachments:
0001-SSL-GUC-option-to-prefer-server-cipher-order.patchtext/x-patch; name=0001-SSL-GUC-option-to-prefer-server-cipher-order.patchDownload
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 77a9303..56bfa01 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -883,6 +883,18 @@ include 'filename'
</listitem>
</varlistentry>
+ <varlistentry id="guc-ssl-prefer-server-ciphers" xreflabel="ssl_prefer_server_ciphers">
+ <term><varname>ssl_prefer_server_ciphers</varname> (<type>bool</type>)</term>
+ <indexterm>
+ <primary><varname>ssl_prefer_server_ciphers</> configuration parameter</primary>
+ </indexterm>
+ <listitem>
+ <para>
+ Specifies whether to prefer client or server ciphersuite.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-password-encryption" xreflabel="password_encryption">
<term><varname>password_encryption</varname> (<type>boolean</type>)</term>
<indexterm>
diff --git a/src/backend/libpq/be-secure.c b/src/backend/libpq/be-secure.c
index 7f01a78..2094674 100644
--- a/src/backend/libpq/be-secure.c
+++ b/src/backend/libpq/be-secure.c
@@ -112,6 +112,9 @@ static bool ssl_loaded_verify_locations = false;
/* GUC variable controlling SSL cipher list */
char *SSLCipherSuites = NULL;
+/* GUC variable: if false, prefer client ciphers */
+bool SSLPreferServerCiphers;
+
/* ------------------------------------------------------------ */
/* Hardcoded values */
/* ------------------------------------------------------------ */
@@ -845,6 +848,10 @@ initialize_SSL(void)
if (SSL_CTX_set_cipher_list(SSL_context, SSLCipherSuites) != 1)
elog(FATAL, "could not set the cipher list (no valid ciphers available)");
+ /* Let server choose order */
+ if (SSLPreferServerCiphers)
+ SSL_CTX_set_options(SSL_context, SSL_OP_CIPHER_SERVER_PREFERENCE);
+
/*
* Load CA store, so we can verify client certificates if needed.
*/
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 538d027..7f1771a 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -127,6 +127,7 @@ extern char *temp_tablespaces;
extern bool ignore_checksum_failure;
extern bool synchronize_seqscans;
extern char *SSLCipherSuites;
+extern bool SSLPreferServerCiphers;
#ifdef TRACE_SORT
extern bool trace_sort;
@@ -801,6 +802,15 @@ static struct config_bool ConfigureNamesBool[] =
check_ssl, NULL, NULL
},
{
+ {"ssl_prefer_server_ciphers", PGC_POSTMASTER, CONN_AUTH_SECURITY,
+ gettext_noop("Give priority to server ciphersuite order."),
+ NULL
+ },
+ &SSLPreferServerCiphers,
+ false,
+ NULL, NULL, NULL
+ },
+ {
{"fsync", PGC_SIGHUP, WAL_SETTINGS,
gettext_noop("Forces synchronization of updates to disk."),
gettext_noop("The server will use the fsync() system call in several places to make "
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(+)
Attachments:
0002-SSL-Support-ECDH-key-excange.patchtext/x-patch; name=0002-SSL-Support-ECDH-key-excange.patchDownload
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 56bfa01..3785052 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -895,6 +895,19 @@ include 'filename'
</listitem>
</varlistentry>
+ <varlistentry id="guc-ssl-ecdh-curve" xreflabel="ssl_ecdh_curve">
+ <term><varname>ssl_ecdh_curve</varname> (<type>string</type>)</term>
+ <indexterm>
+ <primary><varname>ssl_ecdh_curve</> configuration parameter</primary>
+ </indexterm>
+ <listitem>
+ <para>
+ Specifies name of EC curve which will be used in ECDH key excanges.
+ Default is <literal>prime256p1</>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-password-encryption" xreflabel="password_encryption">
<term><varname>password_encryption</varname> (<type>boolean</type>)</term>
<indexterm>
diff --git a/src/backend/libpq/be-secure.c b/src/backend/libpq/be-secure.c
index 2094674..8d688f2 100644
--- a/src/backend/libpq/be-secure.c
+++ b/src/backend/libpq/be-secure.c
@@ -69,6 +69,9 @@
#if SSLEAY_VERSION_NUMBER >= 0x0907000L
#include <openssl/conf.h>
#endif
+#if (OPENSSL_VERSION_NUMBER >= 0x0090800fL) && !defined(OPENSSL_NO_ECDH)
+#include <openssl/ec.h>
+#endif
#endif /* USE_SSL */
#include "libpq/libpq.h"
@@ -112,6 +115,9 @@ static bool ssl_loaded_verify_locations = false;
/* GUC variable controlling SSL cipher list */
char *SSLCipherSuites = NULL;
+/* GUC variable for default ECHD curve. */
+char *SSLECDHCurve;
+
/* GUC variable: if false, prefer client ciphers */
bool SSLPreferServerCiphers;
@@ -765,6 +771,29 @@ info_cb(const SSL *ssl, int type, int args)
}
}
+#if (OPENSSL_VERSION_NUMBER >= 0x0090800fL) && !defined(OPENSSL_NO_ECDH)
+static void
+initialize_ecdh(void)
+{
+ EC_KEY *ecdh;
+ int nid;
+
+ nid = OBJ_sn2nid(SSLECDHCurve);
+ if (!nid)
+ elog(FATAL, "ECDH: curve not known: %s", SSLECDHCurve);
+
+ ecdh = EC_KEY_new_by_curve_name(nid);
+ if (!ecdh)
+ elog(FATAL, "ECDH: failed to allocate key");
+
+ SSL_CTX_set_options(SSL_context, SSL_OP_SINGLE_ECDH_USE);
+ SSL_CTX_set_tmp_ecdh(SSL_context, ecdh);
+ EC_KEY_free(ecdh);
+}
+#else
+#define initialize_ecdh()
+#endif
+
/*
* Initialize global SSL context.
*/
@@ -844,6 +873,9 @@ initialize_SSL(void)
SSL_CTX_set_tmp_dh_callback(SSL_context, tmp_dh_cb);
SSL_CTX_set_options(SSL_context, SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2);
+ /* set up ephemeral ECDH keys */
+ initialize_ecdh();
+
/* set up the allowed cipher list */
if (SSL_CTX_set_cipher_list(SSL_context, SSLCipherSuites) != 1)
elog(FATAL, "could not set the cipher list (no valid ciphers available)");
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 7f1771a..defd44a 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -127,6 +127,7 @@ extern char *temp_tablespaces;
extern bool ignore_checksum_failure;
extern bool synchronize_seqscans;
extern char *SSLCipherSuites;
+extern char *SSLECDHCurve;
extern bool SSLPreferServerCiphers;
#ifdef TRACE_SORT
@@ -3151,6 +3152,21 @@ static struct config_string ConfigureNamesString[] =
},
{
+ {"ssl_ecdh_curve", PGC_POSTMASTER, CONN_AUTH_SECURITY,
+ gettext_noop("Sets the list of EC curve used for ECDH."),
+ NULL,
+ GUC_SUPERUSER_ONLY
+ },
+ &SSLECDHCurve,
+#ifdef USE_SSL
+ "prime256v1",
+#else
+ "none",
+#endif
+ NULL, NULL, NULL
+ },
+
+ {
{"application_name", PGC_USERSET, LOGGING_WHAT,
gettext_noop("Sets the application name to be reported in statistics and logs."),
NULL,
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thursday, November 7, 2013, Marko Kreen wrote:
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.
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 - even though I don't
like the idea of more GUCs. But making it a compile time option would make
it the same as not having one...
//Magnus
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 itIs 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 itIs 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 itIs 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Committed your v2 patch (with default to on). I added a small snippet
of documentation explaining that this setting is mainly for backward
compatibility.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers