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 по дате отправления: