Re: PQgetssl() and alternative SSL implementations

* Heikki Linnakangas (hlinnakangas(at)vmware(dot)com) wrote:
> I think it would be nice to be able to query those attributes
> explicitly, rather than just expect libpq to reject the connection
> if something's wrong. For example, I'm thinking that an interactive
> client might present an annoying pop-up window to the user if the
> server cert is not valid, asking if he wants to connect anyway, and
> perhaps remember the certificate and not ask again (TOFU).

Alright, I could see that being useful, though as you say, it'd really
be new functionality.

> Hmm. That seems a bit too much. Perhaps provide just the certificate
> itself in DER/PEM format, and have the client parse it (using
> OpenSSL or something else) if it wants more details.

I really don't care for that approach. Our SSL support has always been
horrible- I was hoping we'd actually improve that situation. Adding
things in piecemeal over time will just be painful for our users and I
don't see why we should wait.

> >OCSP used?
>
> We don't support OCSP.

Another thing that we really should address (actually- can't you enable
it in OpenSSL directly? I seem to recall something along those lines
anyway, though it's been quite a few years now).

> >This really shouldn't be for *just* the server's certificate but rather
> >available for all certificates involved- on both sides.
>
> Ok, but why? All the other stuff is readily available in the
> configuration you use to connect. I guess it doesn't hurt to expose
> them through this interface as well, but I can't immediately think
> of an example that would use them.

For starters, certificates can be passed between the client and the
server to complete the chain, so I don't see how it's "readily
available", not to mention that even if the location of the certs was in
simple files locally, the application would need to bring in their own
library to parse and extract out this information, which we've
more-or-less already got.

> Indeed, the ODBC driver only uses libpq for authentication, then
> calls PQgetssl(), and takes over the whole show calling SSL_read()
> and SSL_write() itself. Ideally, we'd modify psqlodbc to stop doing
> that, but that's not an easy job. In the short-term, I think we need
> to export pqsecure_read() and pqsecure_write() functions in libpq,
> so that the ODBC driver can use those instead of SSL_read() and
> SSL_write().

Yeah, that's what I remembered. There was an attempt to make that
change at one point, but it was reverted due to the lack of batching
ability in libpq (without resorting to cursors, as I recall...),
requiring double the memory usage. Still, if pqsecure_read and
pqsecure_write are sufficient to make the ODBC driver work, that's good
news. I had been worried it did other things with the OpenSSL struct
beyond just using those.

Thanks,

Stephen