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

libpq: Support TLS versions beyond TLSv1.

Per report from Jeffrey Walton, libpq has been accepting only TLSv1
exactly. Along the lines of the backend code, libpq will now support
new versions as OpenSSL adds them.

Marko Kreen, reviewed by Wim Lewis.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/820f08cabdcbb8998050c3d4873e9619d6d8cba4

Modified Files
--------------
src/interfaces/libpq/fe-secure.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

Noah Misch <noah(at)leadboat(dot)com> writes:
> libpq: Support TLS versions beyond TLSv1.

> Per report from Jeffrey Walton, libpq has been accepting only TLSv1
> exactly. Along the lines of the backend code, libpq will now support
> new versions as OpenSSL adds them.

This patch seems fishy. The commit comment claims that it makes libpq
consistent with the backend, but it doesn't: in the backend, we use
SSLv23_method() but then set only the option SSL_OP_NO_SSLv2. With the
patch, libpq now also sets the option SSL_OP_NO_SSLv3, which I assume
means that we just disabled SSL v3 protocol. Did we actually want to
do that? If so, why wasn't this patch advertised as doing that, and
why wasn't the backend also made to reject SSL v3?

regards, tom lane

On Sat, Jan 25, 2014 at 11:24:19AM -0500, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > libpq: Support TLS versions beyond TLSv1.
>
> > Per report from Jeffrey Walton, libpq has been accepting only TLSv1
> > exactly. Along the lines of the backend code, libpq will now support
> > new versions as OpenSSL adds them.
>
> This patch seems fishy. The commit comment claims that it makes libpq
> consistent with the backend, but it doesn't: in the backend, we use
> SSLv23_method() but then set only the option SSL_OP_NO_SSLv2. With the
> patch, libpq now also sets the option SSL_OP_NO_SSLv3, which I assume
> means that we just disabled SSL v3 protocol. Did we actually want to
> do that? If so, why wasn't this patch advertised as doing that, and
> 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.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

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

On Sat, Jan 25, 2014 at 12:25:30PM -0500, Tom Lane wrote:
> 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.
[...]

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

* Noah Misch (noah(at)leadboat(dot)com) wrote:
> +1. If you can upgrade to 9.4, you can also bring your TLS protocol out of
> the iron age.

Agreed- this was going to be my 2c. Anyone w/ an SSL library that old
isn't likely to be upgrading to 9.4 of libpq or PG.

Thanks,

Stephen

Stephen Frost escribió:
> * Noah Misch (noah(at)leadboat(dot)com) wrote:
> > +1. If you can upgrade to 9.4, you can also bring your TLS protocol out of
> > the iron age.
>
> Agreed- this was going to be my 2c. Anyone w/ an SSL library that old
> isn't likely to be upgrading to 9.4 of libpq or PG.

What about people doing SSL connections through JDBC? As far as I
understand, these don't use openssl.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 01/26/2014 10:13 AM, Alvaro Herrera wrote:
> Stephen Frost escribió:
>> * Noah Misch (noah(at)leadboat(dot)com) wrote:
>>> +1. If you can upgrade to 9.4, you can also bring your TLS protocol out of
>>> the iron age.
>>
>> Agreed- this was going to be my 2c. Anyone w/ an SSL library that old
>> isn't likely to be upgrading to 9.4 of libpq or PG.
>
> What about people doing SSL connections through JDBC? As far as I
> understand, these don't use openssl.

That's correct, PgJDBC uses Java's built-in SSL support, which is
provided by the underlying JSSE ("Java Secure Socket Extension") service
in the JVM.

From what I can find, it looks like Java 1.4.2 and newer, including Java
5, appear to support TLS 1.0. I haven't found anything definitive for
1.4.2 yet, but 1.5 certainly supports it.

That's all we need to care about IMO; 1.4.x users are running
unsupported and old PgJDBC versions (we dropped support for 1.4) and
they're generally happy living in the stone age.

So I don't see Java as a barrier here.

----

Finding a good reference on which Java runtimes support which features
is surprisingly hard.

Java 6 supports TLS. It took a bit to confirm that 1.5 does too. 1.4.2
may, but we don't need to care.

http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html

claims:

"The JSSE implementation in the J2SDK 1.4 and later implements SSL 3.0
and TLS 1.0"

... but in the table "Default Enabled Cipher Suites" in:

http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html

Java 1.4.2 and newer are shown to support by default:

TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA

... and a bunch of SSL_ stuff.

so it looks like TLS support has probably been backpacked to 1.4.2. Java
1.4 is PostgreSQL 7.2 vintage, well into "we don't care, go away" land.

BTW, the JSSE docs also claim that "TLS 1.0 is a modest upgrade to the
most recent version of SSL, version 3.0. The differences between SSL 3.0
and TLS 1.0 are minor".

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Sat, Jan 25, 2014 at 12:25:30PM -0500, Tom Lane wrote:
> 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.

Attached patch disables SSLv3 in backend.

TLS is supported in OpenSSL since fork from SSLeay, in Java since 1.4.2,
in Windows since XP. It's hard to imagine this causing any
compatibility problems.

--
marko

Marko Kreen <markokr(at)gmail(dot)com> writes:
> On Sat, Jan 25, 2014 at 12:25:30PM -0500, Tom Lane wrote:
>> 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?

> Attached patch disables SSLv3 in backend.
> TLS is supported in OpenSSL since fork from SSLeay, in Java since 1.4.2,
> in Windows since XP. It's hard to imagine this causing any
> compatibility problems.

I didn't hear anyone objecting to this idea, so I'll go ahead and commit
this in HEAD.

regards, tom lane