Re: Supporting Windows SChannel as OpenSSL replacement - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: Supporting Windows SChannel as OpenSSL replacement |
| Date | |
| Msg-id | CABUevEx=+im9MWDSBrOjoV+4uzBwob99fgE-3=O+okOVDRPUuA@mail.gmail.com Whole thread Raw |
| In response to | Supporting Windows SChannel as OpenSSL replacement (Heikki Linnakangas <hlinnakangas@vmware.com>) |
| Responses |
Re: Supporting Windows SChannel as OpenSSL replacement
(Heikki Linnakangas <hlinnakangas@vmware.com>)
Re: Supporting Windows SChannel as OpenSSL replacement (Andres Freund <andres@2ndquadrant.com>) |
| List | pgsql-hackers |
On Monday, June 9, 2014, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Hi,
I've been looking at Windows' native SSL implementatation, the SChannel API. It would be nice to support that as a replacement for OpenSSL on Windows. Currently, we bundle the OpenSSL library in the PostgreSQL, installers, which is annoying because whenever OpenSSL puts out a new release that fixes vulnerabilities, we need to do a security release of PostgreSQL on Windows. I was reminded of this recently wrt. psqlODBC, which bundles libpq and openssl as well. It's particularly annoying for psqlODBC and other client applications, as people typically update it less diligently than their servers.
I think that we should keep the user-visible behavior the same, i.e. the libpq connection options, locations of the certificate files etc. would all be the same regardless of which SSL implementation is used. Using Windows SChannel API might make it possible to integrate better with Windows' own certificate store etc. but I don't really know much about that stuff, so for starters I'd like to just use it as a drop-in replacement for OpenSSL.
Thoughts? While we're at it, we'll probably want to refactor things so that it's easy to support other SSL implementations too, like gnutls.
It's a project that many have started, and nobody has finished :) I'm definitely interested in working on such a things, but I've been unable to carve out enough time recently.
One problem is as you say, that we're exposing openssl too much. For one thing, we *cannot* keep the current interface, because it returns OpenSSL internal datastructures. Those functions will need to be deprecated and replaced with something else.
Also, my memory says that SChannel doesn't support the key file format that we use now, which makes a much bigger break with the supported platforms. That may have changed of course - have you researched that part?
The main other entries I've been looking at are NSS and gnutls, both of which can speak our current file formats. I think the right thing is to start with those and thereby make it more pluggable, and only after that tackle schannel. But I do think it would be good to have them all.
It's also a question of if we can accept supporting a different set of libraries on the server vs on the client. It's really on the client that it's a bigger problem, but in the end I think we want to have "symmetrical support". But it might be worth doing just the client side initially, and then move to the server. I think in general, the client side is actually likely to be *harder* than the server side..
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
pgsql-hackers by date: