Re: be-secure.c and SSL/TLS - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: be-secure.c and SSL/TLS
Date
Msg-id 20131114203155.GC7583@eldon.alvh.no-ip.org
Whole thread Raw
In response to be-secure.c and SSL/TLS  (Jeffrey Walton <noloader@gmail.com>)
List pgsql-bugs
Jeffrey Walton escribió:

> `initialize_SSL` starts around line 725. `SSL_CTX_set_options` is
> called around line 795, but it only bans SSLv3 with SSL_OP_NO_SSLv2.
> In 2013, SSL_OP_NO_SSLv3 is appropriate, too.
>
> SSL_OP_NO_COMPRESSION might also be a good choice.

Agreed on banning SSLv3.

> Around line 795, the following is called.
>
>     /* set up the allowed cipher list */
>     if (SSL_CTX_set_cipher_list(SSL_context, SSLCipherSuites) != 1)
>
> But I don't see where SSLCipherSuites is set to anything other than
> NULL. (Unfortunately, I don't know the behavior when using NULL).

See guc.c.

> Postgres takes care to ensure cipher suites with perfect forward
> secrecy are used. Its a great effort and sorely needed.
>
> However, session renegotiation breaks PFS. Around line 330:
>
>     if (SSL_renegotiate(port->ssl) <= 0)
>         ereport(COMMERROR,
>             (errcode(ERRCODE_PROTOCOL_VIOLATION),
>             errmsg("SSL renegotiation failure")));
>
> It breaks PFS because the premaster secret and session_id are retained
> for future renegotiations. If the server is operating in a farm *and*
> in-memory IPC is not available, then it gets written to disk, too.

What's the solution for this?  Are you suggesting we should just not use
renegotiation at all?  AFAIK that's a security problem too, because an
attacker would have large amounts of crypted data for cryptanalysis.


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

pgsql-bugs by date:

Previous
From: Rene Grün
Date:
Subject: BUG #8579: CoreDump of background writer process
Next
From: Tom Lane
Date:
Subject: Re: BUG #8591: Erroneous results, planner pushing where into left join right side