Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?
Дата
Msg-id 22227.1501632275@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?  (Shay Rojansky <roji@roji.org>)
Ответы Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?  (Shay Rojansky <roji@roji.org>)
Список pgsql-hackers
Shay Rojansky <roji@roji.org> writes:
> Once again, I manged to make the error go away simply by setting the
> session id context, which seems to be a mandatory server-side step for
> properly support session tickets.

The fact that you made the error go away doesn't make this a good
solution.  In particular, using a simple constant session ID is completely
insecure according to the TLS spec.  RFC 5246, F.1.4, doesn't even care
for the idea of ever writing session IDs to stable storage; although
Apache seems to be content with a session ID that is unique per-server
(it looks like they just use a hash of the server's host name).

More generally, PG as currently configured can't do anything with a
session cache since each new backend would start with an empty cache.
So the question here is whether it's safe or worthwhile to allow use
of session tickets.  I agree with Heikki's opinion that it's unlikely
to provide any meaningful performance gain for database sessions that
are of reasonable length.  I'm also pretty concerned about the possibility
for security problems, eg a client being able to force a server into some
low-security SSL mode.  Both RFC 5077 and the Apache people say that if
you use session tickets you'd better rotate the keys for them regularly,
eg in Apache's changelog we find

     Session ticket creation uses a random key created during web
     server startup and recreated during restarts. No other key
     recreation mechanism is available currently. Therefore using session
     tickets without restarting the web server with an appropriate frequency
     (e.g. daily) compromises perfect forward secrecy. [Rainer Jung]

Since we have no mechanism for that, I think that we need to err on
the side of security.

Accordingly, what I think we should do is something more like the
attached.  Could you see whether it fixes your problem?

            regards, tom lane

diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index dc307c1..fc6d0f7 100644
--- a/src/backend/libpq/be-secure-openssl.c
+++ b/src/backend/libpq/be-secure-openssl.c
@@ -290,6 +290,14 @@ be_tls_init(bool isServerStart)
                         SSL_OP_SINGLE_DH_USE |
                         SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);

+    /* disallow SSL session tickets */
+#ifdef SSL_OP_NO_TICKET
+    SSL_CTX_set_options(context, SSL_OP_NO_TICKET);
+#endif
+
+    /* disallow SSL session caching, too */
+    SSL_CTX_set_session_cache_mode(context, SSL_SESS_CACHE_OFF);
+
     /* set up ephemeral DH and ECDH keys */
     if (!initialize_dh(context, isServerStart))
         goto error;

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Why does logical replication launcher exit with exitcode 1?
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Why does logical replication launcher exit with exitcode 1?