Re: Supporting Windows SChannel as OpenSSL replacement

On Monday, June 9, 2014, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:

> 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/