Re: Question regarding SSL code in backend and frontend
От | Magnus Hagander |
---|---|
Тема | Re: Question regarding SSL code in backend and frontend |
Дата | |
Msg-id | CABUevEyeAanEwcJRUUfpvz9HTezaMm0Bx+F5E-KujYa2BvkgkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Question regarding SSL code in backend and frontend (Tatsuo Ishii <ishii@postgresql.org>) |
Ответы |
Re: Question regarding SSL code in backend and frontend
|
Список | pgsql-hackers |
On Thu, Apr 5, 2012 at 08:00, Tatsuo Ishii <ishii@postgresql.org> wrote: >>> Those code fragment judges the return value from >>> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and* >>> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry >>> when SSL_ERROR_WANT_READ. It seems they are not consistent. Comments? >> >> There's no particular reason why they should be consistent, I think. >> The assumptions for nonblocking operation are different. > > Ok. Thanks. > > BTW, usage of SSL_CTX_new() is different among frontend and backend as > well. > > fe-secure.c: SSL_context = SSL_CTX_new(TLSv1_method()); > be-secure.c: SSL_context = SSL_CTX_new(SSLv23_method()); > > In my understanding by using SSLV23_method, it is compatible with > SSLv2, SSLv3, and TLSv1 protocol. So it seems there's no particular > reason to use TLSv1_method(). Am I missing something? The reason is that TLS is more secure, I believe. It was changed in commit 750a0e676e1f8f71bf1c6aba05d3264a7c57218b for backwards compatibility. If anything, we should be changing it to TLSv1 in both client and server, since every client out there now should be using that anyway, given that the client has been specifying it for a long time. Unless I am also missing something? :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: