Re: Supporting Windows SChannel as OpenSSL replacement

On Mon, Jun 9, 2014 at 4:39 PM, Martijn van Oosterhout <kleptog(at)svana(dot)org>
wrote:

> On Mon, Jun 09, 2014 at 03:35:23PM +0200, Magnus Hagander wrote:
> > On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson <andreas(at)proxel(dot)se>
> wrote:
> >
> > > On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
> > > There was a patch set for this from Martijn van Oosterhout which was
> quite
> > > complete.
> > >
> > > http://www.postgresql.org/message-id/20060504134807.GK4752@svana.org
>
> Wow, blast from the past.
>

That's fun, itsn't it? :)

> A lot has, unfortunately, changed since 2006. It might be a good
> > startingpoint. But also actively starting from the point of "let's try to
> > support multiple libraries" rather than "let's try to support gnutls" is
> > probably also important.
>
> The patch did provide an API. The idea was that there were a number of
> functions which would need to be defined to support an SSL library.
> Each library would then have a wrapper which wrapped the library and
> based on the results of configure it compiled the right file into the
> backend.
>
> These functions were:
>
> extern void pgtls_initialize(void);
> extern void pgtls_destroy(void);
> extern int pgtls_open_server(Port *);
> extern void pgtls_close(Port *);
> extern ssize_t pgtls_read(Port *port, void *ptr, size_t len);
> extern ssize_t pgtls_write(Port *port, void *ptr, size_t len);
>
> Which should be easy enough to support for any library. These days
> you'd need to add support for verifying certificates, but I don't think
> that that would be difficult (unless the actual certificate formats are
> different).
>

The two difficult points I think are the async support (libpq) and the
windows socket emulation support (backend). Do those really work there? In
particular the win32 stuff - though I guess that's less critical since we
can actually do hackish things there, unlike in libpq. But the example
there is that we can't have the library use recv()/send(), instead having
it work through our own functions.

> No switching after compile time, that would just lead to useless
> overhead.
>

Yes, I absolutely think we don't need to support >1 library at runtime.

> At some point we should design a new API, so that we can deprecate the old
> > one. Even if we don't hve the code ready, we need to get rid of
> PQgetssl(),
> > and replace it with something else. I'm thinking probably a functoin that
> > returns both a void pointer and an enum that tells you which library is
> > actually in use. And a boolean just saying "ssl on/off", because that's
> > what a lot of clients are interested in and they don't care aobut more
> than
> > that.
> >
> > Obviously, we also have to do something about PQinitOpenSSL().
>
> Yeah, I think this was one of the more controversial parts. Support in
> the backend was primarily moving code around and renaming functions,
> fairly straightforward. Even error handling was not so hard (I found
> the gnutls handling of errors much easier than openssl).
>

Yeah, the backend is easier, but also less important from the original
reason. For the patching reason, it's of course just as important.

One tricky part is that programs like to use libpq for the
> authentication, and then they hijack the connection using PGgetssl().
>

Is there *anybody* other than odbc that does that? Do we actually need a
published API for that, or just a hack for pgodbc?

> The way I dealt with this is defining a new state "passthrough" where
> the caller would get a few function pointers to read/write/check the
> connection. Then the callers would not need to know what library libpq
> was compiled with. And libpq would know the connection was hijacked
> and refuse to act anymore. I don't think everyone was pleased with
> this, but no real alternative was presented (other than requiring
> people hijacking the connection to do the hard work).
>
> For information about which library was in use there was PQgettlsinfo()
> which returned a PGresult with information about the library and
> connection. I beleive since then new functions have been added to
> libpq to retrive info about certificates, so that might need a rethink
> also.
>

Not really, no. we return the OpenSSL structure and have the client use
that one directly. That's quite horrible already :)

Basically, I think these last two points are the hard parts to get
> agreement (assuming there's agreement to do anything at all about the
> problem) and without nailing those down first whoever picks this up
> will be in for a lot of work.
>

Agreed.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/