Re: be-secure.c and SSL/TLS

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Jeffrey Walton <noloader(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: be-secure.c and SSL/TLS
Date: 2013-11-14 20:31:55
Message-ID: 20131114203155.GC7583@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2013-11-15 21:47:38 Re: BUG #8591: Erroneous results, planner pushing where into left join right side
Previous Message Kevin Grittner 2013-11-14 14:20:20 Re: Clang 3.3 findings and Illegal Shifts