Re: [BUGS] BUG #5895: Ability to match more than just CN in client certificate
On Thu, 3 Mar 2011 10:20:06 -0500 Robert Haas wrote: [snip] > It seems like there are a lot of possible combinations here that could > be useful, so we'd want something that allowed a fairly flexible > specification of what to match. > > Is this a problem you're interested in working on (i.e. contributing > code)? > I agree, it seems like something along the lines of a full distinguished name with the option to leave out fields would make the most sense, plus some way of specifying other fields not in the formal DN (serial #, fingerprint, or so). Thinking about it, serial number is not necessarily ideal either, since one could reasonably want to trust more than one CA. I feel like I'm pretty much saying I want to specify a single certificate, in which case the full PKI is really kind of pointless, but X.509 certificates are for better or worse the only sane way of doing non-password-based authentication over TLS right now, so that's what we've got to work with. As for contributing code, not right now, but sometime in the near future (next handful of months) I might be interested in hacking at this. Chris -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5895: Ability to match more than just CN in client certificate
The following bug has been logged online: Bug reference: 5895 Logged by: Christopher Head Email address: chris2...@hotmail.com PostgreSQL version: 9.0.3 Operating system: Linux amd64 Description:Ability to match more than just CN in client certificate Details: This is a feature request/wishlist, not a bug. Right now, when using client certificates over SSL for authentication, the username map maps from the Subject Common Name field in the certificate to a username in the database. It would be nice if matches could be done on a few other fields in the certificate. For example, my name is not particularly unusual, so it's reasonable that someone else in the world might (and probably does) have the same name. That doesn't mean I want to give that person access to my database, even if they also get a certificate from e.g. cacert.org! A few fields to match on that would pretty much instantly close this hole would be e-mail address and certificate serial number. While the e-mail address suggestion could be generalized to match an arbitrary subset of the subject's distinguished name fields (e.g. write something like /O=FooOrg/CN=Christopher Head/ to require that both fields must be present with the specified values), matching certificate serial number would be slightly different as the serial number is not part of the distinguished name. It would probably be the most secure field to match on, however, as no CA will ever issue two certificates with the same serial number. E-mail address would be a close second as an address can only be held by one person, though it relies on the CA being able to verify the legitimate owner of the address. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5868: Client ignores X.509 subject alternative name
The following bug has been logged online: Bug reference: 5868 Logged by: Christopher Head Email address: chris2...@hotmail.com PostgreSQL version: 9.0.1 Operating system: Linux amd64 Description:Client ignores X.509 subject alternative name Details: This is more of a wishlist/feature-request than an actual bug. The X.509v3 certificate standard allows an extension field called the "subject alternative name". This field can contain a list of names that should be considered as legitimate names for the entity to which the certificate belongs. Specifically, if an alternative name is of the form "DNS:some.domain.name.tld", then the certificate should be treated as though legitimate for the domain "some.domain.name.tld", just as if that domain were in the common name field of the subject distinguished name. Right now, the psql client (probably libpq) doesn't look at this certificate extension; rather, it only checks if the subject distinguished name common name field matches the requested hostname. It would be nice if the alternative names could be checked also (modern Web browsers all seem to check the extension fine when using the certificate for HTTPS). What this allows is for the common name to have a human-readable name instead of a hostname, with the hostnames stuffed into the alternative names list. While this is pretty much irrelevant for PostgreSQL connections, when sharing a certificate with a Web server, browsers will show the human-readable distinguished name, which is nice. Therefore, it would be preferable for the PostgreSQL clients to also honour this field. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5559: Full SSL verification fails when hostaddr provided
On Tue, 4 Jan 2011 19:42:38 -0500 Robert Haas wrote: > Me, too. I reread the original discussion of this topic and I'm still > a little fuzzy on it, but the issue that was under discussion seems to > be what information we pass to external auth libraries like GSSAPI or > Kerberos, given that we have host and hostaddr to choose from. I'd have thought the logical thing there would be "host", in keeping with the idea that "host is the thing you want to connect to, hostaddr is just how you get there". If you're tunnelling through SSH, you want to ask Kerberos for a ticket to the final end machine, not "localhost", after all. Chris -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5559: Full SSL verification fails when hostaddr provided
On Wed, 14 Jul 2010 18:35:55 -0400 Tom Lane wrote: > Bruce Momjian writes: > > Do the docs need any more updating? > > No doubt, but it's a bit premature to consider that while we're still > arguing whether the code needs to change more. > > regards, tom lane > Sorry to bother everyone, but AFAICT this discussion kind of disappeared. Did I perhaps get dropped from CC? I'm interested to know what the final resolution of this is. My own thought would be: "host" means the thing you intended to connect to: a unique identifier for the server, probably (usually) the hostname, and also the thing that goes in a certificate. Should (probably) never be omitted. "hostaddr" means the thing you actually send your TCP SYN packet to: maybe an IP address if you want to save a DNS lookup, maybe even "localhost" if you want to use an SSH tunnel (or even some other hostname if you have an even stranger tunnel set up), but purely a "network-layer" thing about *how to get to* the server, and not a "user-trust-layer" thing about *who the server is*. If omitted, defaults to being equal to "host". I don't know if that's what was intended, but that's what I thought they would mean. Chris -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5559: Full SSL verification fails when hostaddr provided
The following bug has been logged online: Bug reference: 5559 Logged by: Christopher Head Email address: chris2...@hotmail.com PostgreSQL version: 8.4.4 Operating system: Gentoo Linux i386, kernel 2.6.34 Description:Full SSL verification fails when hostaddr provided Details: When establishing a connection to a PostgreSQL server using a connection string, there are two parameters that can be provided to specify where to connect to: "host" and "hostaddr". If both are provided, the documentation states that "hostaddr" is used to actually establish the socket (thus avoiding a potentially-expensive DNS lookup), while "host" is used for doing some Kerberos stuff. It makes sense that in the case of an SSL connection with "sslmode=verify-full" (check that the server's certificate is signed by a trusted CA and has the correct hostname), if both parameters are provided, that "host" also be used for certificate checking. Unfortunately, as per line 536 of the file fe-secure.c in the PostgreSQL sources, if hostaddr is specified, SSL full verification just plain fails without trying at all. I suspect this line should be "if (!conn->pghost)" instead of "if (conn->pghostaddr)". There is no security vulnerability here, since "host" is a configuration slot intended to hold some kind of semantic name for the host as understood by the user (which is precisely what you want to verify a certificate against—that you are connecting to the semantically-correct server, not simply the one that happens to have the right IP address), while "hostaddr" is merely a network-level implementation detail which should be essentially meaningless to the user. Although it's easy enough to avoid the issue when using psql (just don't include "hostaddr" at all), this unfortunately causes all connections to fail when using pgAdmin3, as that program apparently does its own DNS lookups and always attaches a hostaddr (thus causing the confusing message "verified SSL connections are only supported when connecting to a host name" even if one *does* in fact specify a host*name* in the appropriate place!) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
