SSL compression info in psql header
It's today really hard to figure out if your SSL connection is
actually *using* SSL compression. This got extra hard when we the
default value started getting influenced by environment variables at
least on many platforms after the crime attacks. ISTM we should be
making this easier for the user.
Attached patch adds compression info at least to the header of the
psql banner, as that's very non-intrusive. I think this is a small
enough change, yet very useful, that we should squeeze it into 9.4
before the next beta. Not sure if it can be qualified enough of a bug
to backpatch further than that though.
As far as my research shows, the function
SSL_get_current_compression() which it uses was added in OpenSSL
0.9.6, which is a long time ago (stopped being maintained in 2004).
AFAICT even RHEL *3* shipped with 0.9.7. So I think we can safely rely
on it, especially since we only check for whether it returns NULL or
not.
Comments?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
psql_sslcompress.patchtext/x-patch; charset=US-ASCII; name=psql_sslcompress.patchDownload
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index cede72a..b8a8e35 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -1800,8 +1800,9 @@ printSSLInfo(void)
return; /* no SSL */
SSL_get_cipher_bits(ssl, &sslbits);
- printf(_("SSL connection (protocol: %s, cipher: %s, bits: %d)\n"),
- SSL_get_version(ssl), SSL_get_cipher(ssl), sslbits);
+ printf(_("SSL connection (protocol: %s, cipher: %s, bits: %d, compression: %s)\n"),
+ SSL_get_version(ssl), SSL_get_cipher(ssl), sslbits,
+ SSL_get_current_compression(ssl) ? gettext_noop("yes") : gettext_noop("no"));
#else
/*
On Sat, Jul 12, 2014 at 8:49 AM, Magnus Hagander <magnus@hagander.net> wrote:
It's today really hard to figure out if your SSL connection is
actually *using* SSL compression. This got extra hard when we the
default value started getting influenced by environment variables at
least on many platforms after the crime attacks. ISTM we should be
making this easier for the user.Attached patch adds compression info at least to the header of the
psql banner, as that's very non-intrusive. I think this is a small
enough change, yet very useful, that we should squeeze it into 9.4
before the next beta. Not sure if it can be qualified enough of a bug
to backpatch further than that though.As far as my research shows, the function
SSL_get_current_compression() which it uses was added in OpenSSL
0.9.6, which is a long time ago (stopped being maintained in 2004).
AFAICT even RHEL *3* shipped with 0.9.7. So I think we can safely rely
on it, especially since we only check for whether it returns NULL or
not.Comments?
Seems like a fine change. I think it would be OK to slip it into 9.4,
too, but I don't think we should back-patch it further than that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jul 15, 2014 at 1:08 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sat, Jul 12, 2014 at 8:49 AM, Magnus Hagander <magnus@hagander.net> wrote:
It's today really hard to figure out if your SSL connection is
actually *using* SSL compression. This got extra hard when we the
default value started getting influenced by environment variables at
least on many platforms after the crime attacks. ISTM we should be
making this easier for the user.Attached patch adds compression info at least to the header of the
psql banner, as that's very non-intrusive. I think this is a small
enough change, yet very useful, that we should squeeze it into 9.4
before the next beta. Not sure if it can be qualified enough of a bug
to backpatch further than that though.As far as my research shows, the function
SSL_get_current_compression() which it uses was added in OpenSSL
0.9.6, which is a long time ago (stopped being maintained in 2004).
AFAICT even RHEL *3* shipped with 0.9.7. So I think we can safely rely
on it, especially since we only check for whether it returns NULL or
not.Comments?
Seems like a fine change. I think it would be OK to slip it into 9.4,
too, but I don't think we should back-patch it further than that.
Applied and backpatched to 9.4. I also included updating the similar
row that goes in the server log (new as of 9.4) to include it, for
consistency.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
As far as my research shows, the function
SSL_get_current_compression() which it uses was added in OpenSSL
0.9.6, which is a long time ago (stopped being maintained in 2004).
AFAICT even RHEL *3* shipped with 0.9.7. So I think we can safely rely
on it, especially since we only check for whether it returns NULL or
not.
The buildfarm begs to differ. I think you'll need a configure check
for whether the function exists.
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
On Tue, Jul 15, 2014 at 4:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
As far as my research shows, the function
SSL_get_current_compression() which it uses was added in OpenSSL
0.9.6, which is a long time ago (stopped being maintained in 2004).
AFAICT even RHEL *3* shipped with 0.9.7. So I think we can safely rely
on it, especially since we only check for whether it returns NULL or
not.The buildfarm begs to differ. I think you'll need a configure check
for whether the function exists.
Crap.
Out of curiosity, since one of those boxes seems to be yours, which
version of OpenSSL does it actually have?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
Out of curiosity, since one of those boxes seems to be yours, which
version of OpenSSL does it actually have?
Claims to be 0.9.7:
cube:~ tgl$ ls -l /usr/lib/*ssl*
-rwxr-xr-x 1 root wheel 266940 Nov 7 2010 /usr/lib/libssl.0.9.7.dylib*
-rwxr-xr-x 1 root wheel 257700 Nov 7 2010 /usr/lib/libssl.0.9.dylib*
lrwxr-xr-x 1 root wheel 18 Jul 1 2009 /usr/lib/libssl.dylib@ -> libssl.0.9.7.dylib
The box evidently has "0.9" installed as well, but our build should be
seizing on the symlink and finding 0.9.7.
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
On Tue, Jul 15, 2014 at 4:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Out of curiosity, since one of those boxes seems to be yours, which
version of OpenSSL does it actually have?Claims to be 0.9.7:
cube:~ tgl$ ls -l /usr/lib/*ssl*
-rwxr-xr-x 1 root wheel 266940 Nov 7 2010 /usr/lib/libssl.0.9.7.dylib*
-rwxr-xr-x 1 root wheel 257700 Nov 7 2010 /usr/lib/libssl.0.9.dylib*
lrwxr-xr-x 1 root wheel 18 Jul 1 2009 /usr/lib/libssl.dylib@ -> libssl.0.9.7.dylibThe box evidently has "0.9" installed as well, but our build should be
seizing on the symlink and finding 0.9.7.
Weird. It should bei n that version.
Either way, we clearly need a configure check for it.
Being a completely newbie when it comes to writing configure checks -
does this seem correct?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
ssl_compression_configure.patchtext/x-patch; charset=US-ASCII; name=ssl_compression_configure.patchDownload
*** a/configure
--- b/configure
***************
*** 8509,8514 **** else
--- 8509,8525 ----
as_fn_error $? "library 'ssl' is required for OpenSSL" "$LINENO" 5
fi
+ for ac_func in SSL_get_current_compression
+ do :
+ ac_fn_c_check_func "$LINENO" "SSL_get_current_compression" "ac_cv_func_SSL_get_current_compression"
+ if test "x$ac_cv_func_SSL_get_current_compression" = xyes; then :
+ cat >>confdefs.h <<_ACEOF
+ #define HAVE_SSL_GET_CURRENT_COMPRESSION 1
+ _ACEOF
+
+ fi
+ done
+
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing CRYPTO_new_ex_data" >&5
$as_echo_n "checking for library containing CRYPTO_new_ex_data... " >&6; }
*** a/configure.in
--- b/configure.in
***************
*** 950,955 **** if test "$with_openssl" = yes ; then
--- 950,956 ----
if test "$PORTNAME" != "win32"; then
AC_CHECK_LIB(crypto, CRYPTO_new_ex_data, [], [AC_MSG_ERROR([library 'crypto' is required for OpenSSL])])
AC_CHECK_LIB(ssl, SSL_library_init, [], [AC_MSG_ERROR([library 'ssl' is required for OpenSSL])])
+ AC_CHECK_FUNCS([SSL_get_current_compression])
else
AC_SEARCH_LIBS(CRYPTO_new_ex_data, eay32 crypto, [], [AC_MSG_ERROR([library 'eay32' or 'crypto' is required for OpenSSL])])
AC_SEARCH_LIBS(SSL_library_init, ssleay32 ssl, [], [AC_MSG_ERROR([library 'ssleay32' or 'ssl' is required for OpenSSL])])
*** a/src/include/pg_config.h.in
--- b/src/include/pg_config.h.in
***************
*** 430,435 ****
--- 430,438 ----
/* Define to 1 if you have the `srandom' function. */
#undef HAVE_SRANDOM
+ /* Define to 1 if you have the `SSL_get_current_compression' function. */
+ #undef HAVE_SSL_GET_CURRENT_COMPRESSION
+
/* Define to 1 if you have the <stdint.h> header file. */
#undef HAVE_STDINT_H
*** a/src/include/pg_config.h.win32
--- b/src/include/pg_config.h.win32
***************
*** 337,342 ****
--- 337,345 ----
/* Define to 1 if you have the `srandom' function. */
/* #undef HAVE_SRANDOM */
+ /* Define to 1 if you have the `SSL_get_current_compression' function. */
+ #define HAVE_SSL_GET_CURRENT_COMPRESSION 1
+
/* Define to 1 if you have the <stdint.h> header file. */
/* #undef HAVE_STDINT_H */
*** a/src/include/port.h
--- b/src/include/port.h
***************
*** 420,425 **** extern void unsetenv(const char *name);
--- 420,429 ----
extern void srandom(unsigned int seed);
#endif
+ #ifndef HAVE_SSL_GET_CURRENT_COMPRESSION
+ #define SSL_get_current_compression(x) 0
+ #endif
+
/* thread.h */
extern char *pqStrerror(int errnum, char *strerrbuf, size_t buflen);
Magnus Hagander <magnus@hagander.net> writes:
Being a completely newbie when it comes to writing configure checks -
does this seem correct?
Looks reasonable to me.
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
On Tue, Jul 15, 2014 at 6:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Being a completely newbie when it comes to writing configure checks -
does this seem correct?Looks reasonable to me.
Thanks, I've applied it - let's hope the buildfarm is happier now.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers