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

2014-01-31 Thread Marko Kreen
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

diff --git a/src/backend/libpq/be-secure.c b/src/backend/libpq/be-secure.c
index 43633e7..fc749f4 100644
--- a/src/backend/libpq/be-secure.c
+++ b/src/backend/libpq/be-secure.c
@@ -880,9 +880,9 @@ initialize_SSL(void)
 			SSLerrmessage(;
 	}
 
-	/* set up ephemeral DH keys, and disallow SSL v2 while at it */
+	/* set up ephemeral DH keys, and disallow SSL v2/v3 while at it */
 	SSL_CTX_set_tmp_dh_callback(SSL_context, tmp_dh_cb);
-	SSL_CTX_set_options(SSL_context, SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2);
+	SSL_CTX_set_options(SSL_context, SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
 
 	/* set up ephemeral ECDH keys */
 	initialize_ecdh();

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2014-01-31 Thread Tom Lane
Marko Kreen mark...@gmail.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2014-01-26 Thread Craig Ringer
On 01/26/2014 10:13 AM, Alvaro Herrera wrote:
 Stephen Frost escribió:
 * Noah Misch (n...@leadboat.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2014-01-25 Thread Tom Lane
Noah Misch n...@leadboat.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2014-01-25 Thread Noah Misch
On Sat, Jan 25, 2014 at 11:24:19AM -0500, Tom Lane wrote:
 Noah Misch n...@leadboat.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2014-01-25 Thread Tom Lane
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


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

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

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2014-01-25 Thread Stephen Frost
* Noah Misch (n...@leadboat.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


signature.asc
Description: Digital signature


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

2014-01-25 Thread Alvaro Herrera
Stephen Frost escribió:
 * Noah Misch (n...@leadboat.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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers