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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Wim Lewis <wiml(at)omnigroup(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Jeffrey Walton <noloader(at)gmail(dot)com>
Subject: Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.
Date: 2014-01-25 17:25:30
Message-ID: 29006.1390670730@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Noah Misch 2014-01-25 17:52:21 Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.
Previous Message Noah Misch 2014-01-25 16:46:22 Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2014-01-25 17:30:00 Re: extension_control_path
Previous Message Dimitri Fontaine 2014-01-25 17:07:24 Re: extension_control_path