Re: PQgetssl() and alternative SSL implementations - Mailing list pgsql-hackers

* Magnus Hagander (magnus@hagander.net) wrote:
> On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > Aren't these questions addressed by sslmode?
>
> Not entirely. You can have sslmode=require and have a matching
> certificate. You don't *have* to have sslmode=verify-full for that.
>
> However, whether it makes *sense* without sslmode is another story -
> but assuming you use something like kerberos for auth, it might. For
> password, you've already lost once you get that far.

Sure- I guess my point was really, if you're not verifying them by
sslmode=verify-full, do you really want to ask the question?  If you
*are* verifying them by verify-full, then you already know the answers.

> >> What else do we need?
> >
> > At first blush, I'd say a whole bunch..  Off the top of my head I can
> > think of:
> >
> > For all certificates:
> > (client, server, cert that signed each, any intermediate CAs, root CAs)
> >   Certificate itself (perhaps in DER, PEM, X509 formats..)
>
> Yeah, if we can extract it in PEM for example, that would be useful.
>
> >   Fingerprint
>
> Definitely.
>
> >   Signed-By info
>
> If we can get the full cert, do that one instead.
>
> >   Common Name
>
> Definitely.
>
> >   Organization (et al)
> >   Alternate names
> >   Issue date, expiration date
> >   CRL info, OCSP info
> >   Allowed usage (encryption, signing, etc)
>
> All those would also be covered by the "certificate itself" part I
> think - they're not that common.

Not sure I agree with that but what I don't really like is the
suggestion that we'll need to tell everyone who wants more detailed
information from the certificate to link in whatever their preferred SSL
library is and use that to decode the PEM cert to pull the info.  We'll
end up having applications linking in both OpenSSL and GNUTLS, for
example, which is pretty grotty, imv.

Serial is absolutely another one we need to include, as I look over at
what mod_ssl supports.  Really, I'd look at that list as our minimum to
support..

> >> I think it would also be nice to get more information from the
> >> server's certificate, like the hostname and the organization its
> >> issued to, and expiration date, so that an interactive client like
> >> pgAdmin or even psql could display that information like a web
> >> browser does. Would it be best to add those as extra attributes in
> >> the above list, perhaps with a "server_cert_*" prefix, or add a new
> >> function for extracting server cert's attributes?
> >
> > This really shouldn't be for *just* the server's certificate but rather
> > available for all certificates involved- on both sides.
>
> Well, if you are already the client, wouldn't you know your own certificate?

Uh, no?  Not without having a library of your own which can open the
certificate file (after it figures out which one we decided to use- oh
yeah, we should probably include that information too..  and then we
have to make sure we can represent things like "on a smart card") and
then parse and extract the information you want from it..

> > That's not ideal, but the only other option I can think of offhand is to
> > break the existing API and force everyone to update and that seems
> > worse.
>
> Agreed.
>
> If we just return an arbitrary pointer, then any application that
> *did* actually try to use it would crash.

That wasn't what I was thinking but rather something like "remove
PQgetssl and replace it with PQgetopenssl" or something, breaking the
API completely, forcing everyone to make changes to compile against the
new library, etc, etc.  Very ugly but also very obvious.

> It's not ideal, but errorring in the way of not saying we're secure
> when we are, is acceptable - unlike the opposite.

Yeah, I tend to agree, though I don't particularly like it.  The options
are just so much worse. :/

> Of course, we need to publish it very clearly in the release notes,
> and I would suggest backpatching into the documentation in old
> versions etc as well.

Sounds like a good idea to me.
Thanks,
    Stephen