On Sat, Jan 25, 2014 at 12:25:30PM -0500, Tom Lane wrote:
> 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.
[...]
Interesting.
> 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.
Quaintness aside, I can't envision a user benefit of a fall 2014 introduction
of SSLv3 support to libpq.
> 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.
+1. If you can upgrade to 9.4, you can also bring your TLS protocol out of
the iron age.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com