Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.
Дата
Msg-id 29006.1390670730@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.  (Noah Misch <noah@leadboat.com>)
Ответы Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.  (Noah Misch <noah@leadboat.com>)
Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.  (Marko Kreen <markokr@gmail.com>)
Список pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Sat, Jan 25, 2014 at 11:24:19AM -0500, Tom Lane wrote:
>> why wasn't the backend also made to reject SSL v3?

> The backend allows SSLv3, TLSv1, TLSv1.1 and TLSv1.2.  Before the patch, libpq
> allowed TLSv1 only.  Since the patch, libpq allows TLSv1, TLSv1.1 and TLSv1.2.
> I did twitch a bit over leaving them non-identical.  However, disabling SSLv3
> in the backend would be a separate discussion due to the compatibility break.
> I also didn't see the point of initiating SSLv3 support in libpq when it has
> been disabled so long without complaint.

I looked into the git history to see how it got like this, because it
surely wasn't inconsistent to start with.

Commit 19570420f5318343ed7a263cc6046fd5605b22cc of 2002-06-14
switched both backend and libpq from using SSLv23_method() to using
TLSv1_method() (along with a lot of other changes).
[released in 7.3.0]

Commit 750a0e676e1f8f71bf1c6aba05d3264a7c57218b of 2002-12-18
changed both backend and libpq back to using SSLv23_method().
[released in 7.3.1]

Commit 6ccb5aebaddd9e7aefaa7d1e7baa3264148be3c5 of 2003-01-08
installed the SSL_OP_NO_SSLv2 switch on the backend side
and switched libpq back to using TLSv1_method().
[released in 7.3.2]

AFAICT it's been stable since 7.3.2.  I would offer, however, that
probably *none* of those three patches got reviewed with any care.
SSL wasn't a particularly mainstream concern back then, and
cross-openssl-library-version compatibility issues even less so.

I would argue that we ought to not reject SSLv3 in libpq if we're
not doing so in the backend.  It's certainly moot from a functional
standpoint, since every post-7.3 libpq version has only been able
to talk to servers that had TLS-capable libraries, so it's impossible
to imagine a case where they wouldn't end up negotiating TLS-something.
My beef is that leaving it as it is will confuse everybody who looks at
this code in the future.

Alternatively, given that TLS has been around for a dozen years and
openssl versions that old have not gotten security updates for a long
time, why don't we just reject SSLv3 on the backend side too?
I guess it's barely possible that somebody out there is using a
non-libpq-based client that uses a non-TLS-capable SSL library, but
surely anybody like that is overdue to move into the 21st century.
An SSL library that old is probably riddled with security issues.
        regards, tom lane



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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: extension_control_path
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: extension_control_path