Re: SSL renegotiation

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: SSL renegotiation
Дата
Msg-id 20130712203252.GH29206@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: SSL renegotiation  (Troels Nielsen <bn.troels@gmail.com>)
Ответы Re: SSL renegotiation  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
Troels Nielsen escribió:
> Hi,
> 
> These are the relevant bits from Apache2.4's mod_ssl.
> 
> [snip]

So this is basically the same thing the Pg code is doing.

> That code supports at least OpenSSL 0.9.7 and later.
> 
> Some explanation for it can be found here:
> 
>
http://books.google.dk/books?id=IIqwAy4qEl0C&pg=PT184&lpg=PT184&dq=SSL_do_handshake&source=bl&ots=ma632U4vWv&sig=d2qqS0svhu4EwIZZaONdHoTulVI&hl=en&sa=X&ei=xdPdUczoDuf34QSzmoDQDg&ved=0CIIDEOgBMCo
> 
> The snippet there is probably the textbook implementation.

Ah, thanks for the pointer.  I notice this book is from 2002 and
documents OpenSSL 0.9.6.

So yeah, that's what both mod_ssl and Pg implement.  However, reading
the text carefully, I see that this snippet is the correct
implementation for 0.9.6 and earlier; the same book, speaking about the
0.9.7 release in the future tense, explains that in that release it will
be much easier to do renegotiations, without getting into precise
details of how exactly is to be done (I suppose the OpenSSL team hadn't
finalized the API yet).  As far as I can understand, what I propose is
the right sequence.

Now, should we support the 0.9.6-and-earlier mechanism?  My inclination
is no; even RHEL 3, the oldest supported Linux distribution, uses 0.9.7
(Heck, even Red Hat Linux 9, released on 2003).  To see OpenSSL 0.9.6
you need to go back to Red Hat Linux 7.2, released on 2001 using a Linux
kernel 2.4.  Surely no one in their right mind would use a current
Postgres release on such an ancient animal.

So I continue to maintain that we should rip the old mechanism out and
replace it with current renegotiation.

Now, I've read a bit more of the code and it seems that we should be
doing SSL_renegotiate() and then check the SSL_renegotiate_pending()
result until it returns that the renegotiation has completed.

> So the original code looks OK. Perhaps the check
> on the return code of the first SSL_do_handshake (and SSL_renegotiate)
> is unnecessary and may lead to unwarranted error messages, though.
> And it may be wrong to continue the renegotiation if
> the state is not SSL_ST_OK after the first SSL_do_handshake.
> 
> If the renegotiation fails, I suppose two things can be done:
> 1. Quit the connection
> 2. Carry on pretending nothing happened.
> 
> I think 2. is correct  in the vast majority of cases (as it looks like is
> being done now).
> And in that case: not resetting  port->count will make for a very slow
> and awkward connection as new handshakes will be attempted again and again,
> even if the other party persistently refuse to shake hands.

Good point.  From a security point of view, it seems that the correct
reaction is to close the connection if renegotiation doesn't complete.

Along the same lines, it seems to me that accepting SSLv2 (which doesn't
support renegotiations at all) when renegotiations have been requested
is not a good choice; we should accept only SSLv3 in that case.

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



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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Kudos for Reviewers -- wrapping it up
Следующее
От: Cédric Villemain
Дата:
Сообщение: Re: Bugfix and new feature for PGXS