Re: Supporting Windows SChannel as OpenSSL replacement - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Supporting Windows SChannel as OpenSSL replacement
Date
Msg-id 20140711173913.GC6390@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: Supporting Windows SChannel as OpenSSL replacement  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Supporting Windows SChannel as OpenSSL replacement
List pgsql-hackers
Heikki Linnakangas wrote:

> I did again the refactoring you did back in 2006, patch attached.
> One thing I did differently: I moved the raw, non-encrypted,
> read/write functions to separate functions: pqsecure_raw_read and
> pqsecure_raw_write. Those functions encapsulate the SIGPIPE
> handling. The OpenSSL code implements a custom BIO, which calls to
> pqsecure_raw_read/write to do the low-level I/O.  Similarly in the
> server-side, there are be_tls_raw_read and pg_tls_raw_write
> functions, which do the
> prepare_for_client_read()/client_read_ended() dance, so that the SSL
> implementation doesn't need to know about that.

I'm skimming over this patch (0001).  There are some issues:

* You duplicated the long comment under the IDENTIFICATION tag that was in be-secure.c; it's now both in that file and
alsoin be-secure-openssl.c.  I think it should be removed from be-secure.c. Also, the hardcoded DH params are
duplicatedin be-secure.c, but they belong in -openssl.c only now.
 

* There is some mixup regarding USE_SSL and USE_OPENSSL in be-secure.c. I think anything that's OpenSSL-specific should
bein be-secure-openssl.c only; any new SSL implementation will need to implement all those functions.  For instance,
be_tls_init().I imagine that if we select any SSL implementation, USE_SSL would get defined, and each SSL
implementationwould additionally define its own symbol.  Unless the idea is to get rid of USE_OPENSSL completely, and
useonly the Makefile bit to decide which implementation to use?  If so, then USE_OPENSSL as a preprocessor symbol is
useless...
 

* ssl_renegotiation_limit is also duplicated.  But removing this one is probably not going to be as easy as deleting a
linefrom be-secure.c, because guc.c depends on that one.  I think that variable should be defined in be-secure.c (i.e.
deleteit from -openssl) and make sure that all SSL implementations enforce it on their own somehow.
 

The DISABLE_SIGPIPE thingy looks wrong in pqsecure_write.  I think it
should be like this:

ssize_t
pqsecure_write(PGconn *conn, const void *ptr, size_t len)
{ssize_t        n;

#ifdef USE_SSLif (conn->ssl_in_use){    DECLARE_SIGPIPE_INFO(spinfo);
    DISABLE_SIGPIPE(conn, spinfo, return -1);
    n = pgtls_write(conn, ptr, len);
    RESTORE_SIGPIPE(spinfo);}else 
#endif   /* USE_OPENSSL */{    n = pqsecure_raw_write(conn, ptr, len);}
return n;
}

You are missing the restore call, and I moved the declaration inside the
ssl_in_use block since otherwise it's not useful.  The other path is
fine since pqsecure_raw_write disables and restores the flag by itself.
Also, you're missing DECLARE/DISABLE/RESTORE in the ssl_in_use block in
pqsecure_read.  (The original code does not have that code in the
non-SSL path.  I assume, without checking, that that's okay.)  I also
assume without checking that all SSL implementations would be fine with
this SIGPIPE handling.

Another thing that seems wrong is the REMEMBER_EPIPE stuff.  The
fe-secure-openssl.c code should be setting the flag, but AFAICS only the
non-SSL code is doing it.


Thanks for working on this -- I'm sure many distributors will be happy
to be able to enable other, less license-broken TLS implementations.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: tweaking NTUP_PER_BUCKET
Next
From: Robert Haas
Date:
Subject: Re: RLS Design