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

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. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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. +

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly