| 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: | Whole Thread | Raw Message | 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
| 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. |
| 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 |