Re: PQgetssl() and alternative SSL implementations - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: PQgetssl() and alternative SSL implementations |
Date | |
Msg-id | 20140819154436.GD16422@tamriel.snowman.net Whole thread Raw |
In response to | Re: PQgetssl() and alternative SSL implementations (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Responses |
Re: PQgetssl() and alternative SSL implementations
Re: PQgetssl() and alternative SSL implementations |
List | pgsql-hackers |
* Heikki Linnakangas (hlinnakangas@vmware.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
pgsql-hackers by date: