Thread: Backend SSL configuration enhancement
This patch adds two new configuration diretives to postgresql.conf file 1. ssl_ciphers - allows server administrator to specify set of SSL ciphersuites which can be used by clients to connect the server. 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware crypto accelerator support) to use.
Attachment
"Victor B. Wagner" <vitus@cryptocom.ru> writes:
> This patch adds two new configuration diretives to postgresql.conf file
> 1. ssl_ciphers - allows server administrator to specify set of SSL
> ciphersuites which can be used by clients to connect the server.
> 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware
> crypto accelerator support) to use.
Why are either of these useful? What are the compatibility implications
of changing them? Does the addition of the engine-load code break
compatibility with older OpenSSL releases?
regards, tom lane
On 2006.08.30 at 10:14:02 -0400, Tom Lane wrote: > "Victor B. Wagner" <vitus@cryptocom.ru> writes: > > This patch adds two new configuration diretives to postgresql.conf file > > 1. ssl_ciphers - allows server administrator to specify set of SSL > > ciphersuites which can be used by clients to connect the server. > > 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware > > crypto accelerator support) to use. > > Why are either of these useful? What are the compatibility implications First one is useful if for some reason some ciphers supported by OpenSSL is not permitted to use in the particular network, or if there is need to use ciphersuites which are not included into default ciphersuite list, now compiled into PostgreSQL. It might be requirement of enhanced security, or some national standards requirement. Or vice versa - people might want client certificates for authentication, but avoid encryption for performance reasons. Second one can be used for taking cryptography load from server into special hardware chip, which can be useful for loaded servers. Also, upcoming OpenSSL 0.9.9 allows to add entirely new cryptographic algorithms via engines, so engine support allows to use algorithms, i.e. national standards, which are not supported in the OpenSSL core. We have developed this patch in order to use Russian GOST algorithms for SSL connections. > of changing them? Does the addition of the engine-load code break > compatibility with older OpenSSL releases? Engines have appeared in OpenSSL quite a long ago. Version 0.9.7 already supports them. So, compatibility is broken only with 0.9.6 and eariler which have numerous other problems anyway. I can recheck my patch and add conditional compilation around engine loading code to be sure that it doesn't break compatiblity with 0.9.6, just ignores ssl_engine keyword if underlying OpenSSL doesn't support engines.
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Victor B. Wagner wrote:
> On 2006.08.30 at 10:14:02 -0400, Tom Lane wrote:
>
> > "Victor B. Wagner" <vitus@cryptocom.ru> writes:
> > > This patch adds two new configuration diretives to postgresql.conf file
> > > 1. ssl_ciphers - allows server administrator to specify set of SSL
> > > ciphersuites which can be used by clients to connect the server.
> > > 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware
> > > crypto accelerator support) to use.
> >
> > Why are either of these useful? What are the compatibility implications
>
> First one is useful if for some reason some ciphers supported by OpenSSL
> is not permitted to use in the particular network, or if there is need
> to use ciphersuites which are not included into default ciphersuite
> list, now compiled into PostgreSQL.
>
> It might be requirement of enhanced security, or some national standards requirement.
>
> Or vice versa - people might want client certificates for
> authentication, but avoid encryption for performance reasons.
>
> Second one can be used for taking cryptography load from server into
> special hardware chip, which can be useful for loaded servers.
> Also, upcoming OpenSSL 0.9.9 allows to add entirely new cryptographic
> algorithms via engines, so engine support allows to use algorithms,
> i.e. national standards, which are not supported in the OpenSSL core.
>
> We have developed this patch in order to use Russian GOST algorithms
> for SSL connections.
> > of changing them? Does the addition of the engine-load code break
> > compatibility with older OpenSSL releases?
>
> Engines have appeared in OpenSSL quite a long ago. Version 0.9.7 already
> supports them. So, compatibility is broken only with 0.9.6 and eariler
> which have numerous other problems anyway.
>
> I can recheck my patch and add conditional compilation around engine
> loading code to be sure that it doesn't break compatiblity with 0.9.6,
> just ignores ssl_engine keyword if underlying OpenSSL doesn't support
> engines.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > This has been saved for the 8.3 release: > http://momjian.postgresql.org/cgi-bin/pgpatches_hold This version was withdrawn by the author for rework, no? regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > This has been saved for the 8.3 release: > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold > > This version was withdrawn by the author for rework, no? Right, and the thread in patches_hold shows that. The reason it is in there is so we can ping the author at the start of 8.3 to get an updated version. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Victor Wagner wrote: > On 2006.09.04 at 15:46:03 -0400, Bruce Momjian wrote: > > > Tom Lane wrote: > > > Bruce Momjian <bruce@momjian.us> writes: > > > > This has been saved for the 8.3 release: > > > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold > > > > > > This version was withdrawn by the author for rework, no? > > > > Right, and the thread in patches_hold shows that. The reason it is in > > there is so we can ping the author at the start of 8.3 to get an updated > > version. > > I've already send version 2 of the patch to patches mailing list. > I think that this letter even got into thread mentioned above. > > It's a pity that it's to late for patch to get into 8.2. > It means that during all 8.2 lifecycle we'll have to maintain this patch > separately. Yep, sorry. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tue, Sep 05, 2006 at 10:17:15AM +0400, Victor Wagner wrote: > It's a pity that it's to late for patch to get into 8.2. > It means that during all 8.2 lifecycle we'll have to maintain this patch > separately. Hmm? After 8.2 releases, if it's ready, it will go straight into CVS at which point it'll be in the next release. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.