[HACKERS] SSL and USER_CERT_FILE patch
I have submitted a patch that does two things: (1) fixes a bug in the client SSL code that never appended the home directory to the root revocation list. and (2) adds 4 new fields to the connect string: sslkey=fullepath_to_file sslcert=fullpath_to_cert ssltrustcrt=fullpath_to_trusted_cert_file sslcrl=fullpath_to_revocation_list -- 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] SSL and USER_CERT_FILE
> [EMAIL PROTECTED] wrote: >> > [EMAIL PROTECTED] writes: >> >> Maybe we need to go even further and add it to the PQconnect API >> >> sslkey=filename and sslcrt=filename in addition to sslmode? >> > >> > If there's a case to be made for this at all, it should be handled >> > the same way as all other libpq connection parameters. >> > >> >regards, tom lane >> > >> >> Here's the use case: >> >> I have an application that must connect to multiple PostgreSQL >> databases and must use secure communications and the SSL keys are >> under the control of the business units the administer the databases, >> not me. In addition my application also communicates with other SSL >> enabled versions of itself. >> >> I think you would agree that a hard coded immutable location for >> "client" interface is problematic. > > I agree fully with the use-case. Most of the other things we allow both > as connection parameters and as environment variables, so we should do > that IMHO. What could be debated is if we should also somehow allow it > to be specified in .pgpass for example? > I am testing a patch that is currently against the 8.2 series. It implements in PQconnectdb(...) sslmode=require sslkey=client.key sslcert=client.crt ssltrustcrt=certs.pem sslcrl=crl.pem" BTW: the revocation list probably never worked in the client. -- 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] SSL and USER_CERT_FILE
[EMAIL PROTECTED] wrote: > > [EMAIL PROTECTED] writes: > >> Maybe we need to go even further and add it to the PQconnect API > >> sslkey=filename and sslcrt=filename in addition to sslmode? > > > > If there's a case to be made for this at all, it should be handled > > the same way as all other libpq connection parameters. > > > > regards, tom lane > > > > Here's the use case: > > I have an application that must connect to multiple PostgreSQL > databases and must use secure communications and the SSL keys are > under the control of the business units the administer the databases, > not me. In addition my application also communicates with other SSL > enabled versions of itself. > > I think you would agree that a hard coded immutable location for > "client" interface is problematic. I agree fully with the use-case. Most of the other things we allow both as connection parameters and as environment variables, so we should do that IMHO. What could be debated is if we should also somehow allow it to be specified in .pgpass for example? //Magnus -- 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] SSL and USER_CERT_FILE round 2
[EMAIL PROTECTED] wrote: I think if you're going to provide for these then you should also provide for the CA cert and CRL. Otherwise, it seems sensible. I thought about that, but the root and crl are for the server, and that makes sense that the keys would be in the server directory. The server needs to protect its data against clients wishing to connect. The client on the other hand, needs to access one or more postgresql servers. It makes sense that the server keys and credentials be hard coded to its protected data directory, while the client needs the ability to have multiple keys. Think of it this way, a specific lock only takes one key while a person needs to carry multiple keys on a ring. This is completely wrong. Why do you think your web browser has CA keys embedded in it? So it can know which server keys to trust. As documented, if a CA certificate set is present on the libpq client, the client will only trust server keys signed with a chain starting from that set. CA certificates and CRLs can in general be used on both sides of an SSL connection, and we make explicit provision for them on both sides. See http://www.postgresql.org/docs/current/static/libpq-ssl.html cheers andrew -- 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] SSL and USER_CERT_FILE round 2
>
>
> [EMAIL PROTECTED] wrote:
>> Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
>>
>> After some discussion, I think it is more appropriate to add the
>> key/cert
>> file for SSL into the connect string. For example:
>>
>> PQconnectdb("host=foo dbname=bar sslmode=require
>> sslkey=/opt/myapp/share/keys/client.key
>> sslcert=/opt/myapp/share/keys/client.crt");
>>
>>
>> Any comments?
>>
>>
>
> I think if you're going to provide for these then you should also
> provide for the CA cert and CRL.
>
> Otherwise, it seems sensible.
I thought about that, but the root and crl are for the server, and that
makes sense that the keys would be in the server directory. The server
needs to protect its data against clients wishing to connect. The client
on the other hand, needs to access one or more postgresql servers.
It makes sense that the server keys and credentials be hard coded to its
protected data directory, while the client needs the ability to have
multiple keys.
Think of it this way, a specific lock only takes one key while a person
needs to carry multiple keys on a ring.
--
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] SSL and USER_CERT_FILE round 2
[EMAIL PROTECTED] wrote:
Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
After some discussion, I think it is more appropriate to add the key/cert
file for SSL into the connect string. For example:
PQconnectdb("host=foo dbname=bar sslmode=require
sslkey=/opt/myapp/share/keys/client.key
sslcert=/opt/myapp/share/keys/client.crt");
Any comments?
I think if you're going to provide for these then you should also
provide for the CA cert and CRL.
Otherwise, it seems sensible.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SSL and USER_CERT_FILE round 2
Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
After some discussion, I think it is more appropriate to add the key/cert
file for SSL into the connect string. For example:
PQconnectdb("host=foo dbname=bar sslmode=require
sslkey=/opt/myapp/share/keys/client.key
sslcert=/opt/myapp/share/keys/client.crt");
Any comments?
--
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] SSL and USER_CERT_FILE
>
> On May 15, 2008, at 6:31 AM, [EMAIL PROTECTED] wrote:
>
>>> Mark Woodward wrote:
I am using PostgreSQL's SSL support and the conventions for the
key and
certifications don't make sense from the client perspective.
Especially
under Windows.
I am proposing a few simple changes:
Adding two API
void PQsetSSLUserCertFileName(char *filename)
{
user_crt_filename = strdup(filename);
}
PQsetSSLUserKeyFileName(char *filename)
{
user_key_filename = strdup(filename);
}
>>> [snip]
Any comments?
>>>
>>>
>>> I think it would probably be much better to allow for some
>>> environment
>>> variables to specify the locations of the client certificate and key
>>> (and the CA cert and CRL) - c.f. PGPASSFILE.
>>>
>>> That way not only could these be set by C programs but by any libpq
>>> user
>>> (I'm sure driver writers who use libpq don't want to have to bother
>>> with
>>> this stuff.) And we wouldn't need to change the API at all.
>>>
>>
>> The problem I have with environment variables is that they tend not
>> to be
>> application specific and almost always lead to configuration issues.
>> As a
>> methodology for default configuration, it adds flexibility. Also, the
>> current configuration does not easily take in to consideration the
>> idea
>> that different databases with different keys can be used from the same
>> system the same user.
>
> Environment variables don't have to be set in your shell.
>
> This would seem to give the same functionality you suggest above,
> given support for environment variables:
>
> void PQsetSSLUserCertFileName(char * filename)
> {
>setenv("PGCERTFILE", filename);
> }
>
> void PQsetSSLUserKeyFileName(char *filename)
> {
>setenv("PGKEYFILE", filename);
> }
>
> Or, in perl, $ENV{PGKEYFILE} = $file and so on. It seems
> less intrusive than adding new API calls.
>
> Cheers,
>Steve
Doesn't it make sense that the connection be configured in one place? I
agree with Tom, if it should be done, it should be done in PQconnectdb.
--
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] SSL and USER_CERT_FILE
> [EMAIL PROTECTED] writes: >> Maybe we need to go even further and add it to the PQconnect API >> sslkey=filename and sslcrt=filename in addition to sslmode? > > If there's a case to be made for this at all, it should be handled the > same way as all other libpq connection parameters. > > regards, tom lane > Here's the use case: I have an application that must connect to multiple PostgreSQL databases and must use secure communications and the SSL keys are under the control of the business units the administer the databases, not me. In addition my application also communicates with other SSL enabled versions of itself. I think you would agree that a hard coded immutable location for "client" interface is problematic. -- 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] SSL and USER_CERT_FILE
On May 15, 2008, at 6:31 AM, [EMAIL PROTECTED] wrote:
Mark Woodward wrote:
I am using PostgreSQL's SSL support and the conventions for the
key and
certifications don't make sense from the client perspective.
Especially
under Windows.
I am proposing a few simple changes:
Adding two API
void PQsetSSLUserCertFileName(char *filename)
{
user_crt_filename = strdup(filename);
}
PQsetSSLUserKeyFileName(char *filename)
{
user_key_filename = strdup(filename);
}
[snip]
Any comments?
I think it would probably be much better to allow for some
environment
variables to specify the locations of the client certificate and key
(and the CA cert and CRL) - c.f. PGPASSFILE.
That way not only could these be set by C programs but by any libpq
user
(I'm sure driver writers who use libpq don't want to have to bother
with
this stuff.) And we wouldn't need to change the API at all.
The problem I have with environment variables is that they tend not
to be
application specific and almost always lead to configuration issues.
As a
methodology for default configuration, it adds flexibility. Also, the
current configuration does not easily take in to consideration the
idea
that different databases with different keys can be used from the same
system the same user.
Environment variables don't have to be set in your shell.
This would seem to give the same functionality you suggest above,
given support for environment variables:
void PQsetSSLUserCertFileName(char * filename)
{
setenv("PGCERTFILE", filename);
}
void PQsetSSLUserKeyFileName(char *filename)
{
setenv("PGKEYFILE", filename);
}
Or, in perl, $ENV{PGKEYFILE} = $file and so on. It seems
less intrusive than adding new API calls.
Cheers,
Steve
--
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] SSL and USER_CERT_FILE
[EMAIL PROTECTED] writes: > Maybe we need to go even further and add it to the PQconnect API > sslkey=filename and sslcrt=filename in addition to sslmode? If there's a case to be made for this at all, it should be handled the same way as all other libpq connection parameters. 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] SSL and USER_CERT_FILE
> Mark Woodward wrote:
>> I am using PostgreSQL's SSL support and the conventions for the key and
>> certifications don't make sense from the client perspective. Especially
>> under Windows.
>>
>> I am proposing a few simple changes:
>>
>> Adding two API
>> void PQsetSSLUserCertFileName(char *filename)
>> {
>> user_crt_filename = strdup(filename);
>> }
>> PQsetSSLUserKeyFileName(char *filename)
>> {
>> user_key_filename = strdup(filename);
>> }
>>
>>
>>
> [snip]
>> Any comments?
>>
>>
>
>
> I think it would probably be much better to allow for some environment
> variables to specify the locations of the client certificate and key
> (and the CA cert and CRL) - c.f. PGPASSFILE.
>
> That way not only could these be set by C programs but by any libpq user
> (I'm sure driver writers who use libpq don't want to have to bother with
> this stuff.) And we wouldn't need to change the API at all.
>
The problem I have with environment variables is that they tend not to be
application specific and almost always lead to configuration issues. As a
methodology for default configuration, it adds flexibility. Also, the
current configuration does not easily take in to consideration the idea
that different databases with different keys can be used from the same
system the same user.
Maybe we need to go even further and add it to the PQconnect API
sslkey=filename and sslcrt=filename in addition to sslmode?
--
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] SSL and USER_CERT_FILE
Mark Woodward wrote:
I am using PostgreSQL's SSL support and the conventions for the key and
certifications don't make sense from the client perspective. Especially
under Windows.
I am proposing a few simple changes:
Adding two API
void PQsetSSLUserCertFileName(char *filename)
{
user_crt_filename = strdup(filename);
}
PQsetSSLUserKeyFileName(char *filename)
{
user_key_filename = strdup(filename);
}
[snip]
Any comments?
I think it would probably be much better to allow for some environment
variables to specify the locations of the client certificate and key
(and the CA cert and CRL) - c.f. PGPASSFILE.
That way not only could these be set by C programs but by any libpq user
(I'm sure driver writers who use libpq don't want to have to bother with
this stuff.) And we wouldn't need to change the API at all.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SSL and USER_CERT_FILE
I am using PostgreSQL's SSL support and the conventions for the key and
certifications don't make sense from the client perspective. Especially
under Windows.
I am proposing a few simple changes:
Adding two API
void PQsetSSLUserCertFileName(char *filename)
{
user_crt_filename = strdup(filename);
}
PQsetSSLUserKeyFileName(char *filename)
{
user_key_filename = strdup(filename);
}
Adding two static vars in fe-secure.c
char *user_key_filename=NULL;
char *user_crt_filename=NULL;
In client_cert_cb(...)
Add:
if(user_crt_filename)
strncpy(fnbuf, sizeof(fnbuf), user_crt_filename);
else
snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_CERT_FILE);
and:
if(user_key_filename)
strncpy(fnbuf, sizeof(fnbuf), user_key_filename);
else
snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_KEY_FILE);
The purpose of these changes is to make it easier to configure SSL in an
application which uses libpq.
Any comments?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
