Re: be-secure.c and SSL/TLS
От | Alvaro Herrera |
---|---|
Тема | Re: be-secure.c and SSL/TLS |
Дата | |
Msg-id | 20131114203155.GC7583@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | be-secure.c and SSL/TLS (Jeffrey Walton <noloader@gmail.com>) |
Список | 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 по дате отправления: