Noah Misch <n...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
