Re: Disable OpenSSL compression - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Disable OpenSSL compression
Date
Msg-id CABUevEzoPV0PjvW7FPYyTfg5+WX79eK36SG6gFaBQhs42b4bSA@mail.gmail.com
Whole thread Raw
In response to Re: Disable OpenSSL compression  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Thursday, November 10, 2011, Andrew Dunstan wrote:


On 11/08/2011 12:39 PM, Tom Lane wrote:
Jeroen Vermeulen<jtv@xs4all.nl>  writes:
Another reason why I believe compression is often used with encryption
is to maximize information content per byte of data: harder to guess,
harder to crack.  Would that matter?
Yes, it would.  There's a reason why the OpenSSL default is what it is.

                       


An interesting data point on this is that RedHat's nss_compat_ossl package doesn't support SSL compression at all <http://fedoraproject.org/wiki/Nss_compat_ossl>, and it's supposed to be a path to FIPS 140 compliance: <http://fedoraproject.org/wiki/FedoraCryptoConsolidation>. The latter URL, incidentally, contains a lot of good information, and lays out many of the reasons why I'd like to see us support NSS as an alternative to OpenSSL, notwithstanding the supposed dirtiness of its API. I imagine this would be of interest to commercial Postgres vendors also.

Interesting points. I hadn't really considered it from the FIPS perspective.

I thought the main idea was that if we want to support another one it's probably going to be GnuTLS because that one offers key-file-compatibility with OpenSSL, which NSS doesnät.
 
//Magnus



--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message
Next
From: "Albe Laurenz"
Date:
Subject: Re: Disable OpenSSL compression