On 01/06/17 17:50, Stephen Frost wrote:
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, May 31, 2017 at 7:59 PM, Stephen Frost <sfr...@snowman.net> wrote:
If your comments regarding the requirement that we have interoperability
testing of this feature before accepting it were intended to mean that
we need to make sure that the JDBC driver is able to work with the
chosen solution (or, perhaps, that we support multuple options, one of
which works with the JDBC changes), and that we review the other TLS
libraries with the goal of making sure that what we agree on in core
should work with those also, then that's great and exactly what I'd like
to see also.
OK, great. That's what I mean (mostly - see below).
Glad to hear it.
If your comments regarding the requirement that we have interoperability
testing of this feature before accepting it were intended to mean that
we must have a complete alternative TLS solution, while that would
actually play a great deal to a goal I've had for a while to have PG
support multiple TLS implementations (LibNSS being top-of-mind, at least
for me, as I've mentioned a couple times), I can't agree that we should
require that before accepting channel binding as a feature. To do so
would be akin to requiring that we support multiple TLS implementations
before we agreed to support client-side certificates, in my opinion.
I don't think that we need to have a committed patch allowing multiple
SSL implementations before we accept a patch for channel binding, but
I think it might be a good idea for someone to hack either libpq or
the server enough to make it work with some other SSL implementation
(Windows SSL would probably be the best candidate) and test that what
we think will work for channel binding actually does work. It
wouldn't need to be a committable patch, but it should be enough to
make a successful connection in the laboratory. Now, there might also
be other ways besides that of testing that interoperability is
possible, so don't take me as being of the view that someone has to
necessarily do exactly that thing that I just said. But I do think
that we probably should do more than say "hey, we've got this
undocumented SSL API, and this other Windows API, and it looks like
they do about the same thing, so we're good". There's sometimes a big
difference between what sounds like it should work on paper and what
actually does work.
I certainly wouldn't object to someone working on this, but I feel like
it's a good deal more work than perhaps you're realizing (and I tend to
think trying to use the Windows SSL implementation would increase the
level of effort, not minimize it). Perhaps it wouldn't be too bad to
write a one-off piece of code which just connects and then returns the
channel binding information on each side and then one could hand-check
that what's returned matches what it's supposed to based on the RFC, but
if it doesn't, then what? In the specific case we're talking about,
there's two approaches in the RFC and it seems like we should support
both because at least our current JDBC implementation only works with
one, and ideally we can allow for that to be extended to other methods,
but I wouldn't want to implement a method that only works on Windows SSL
because that implementation, for whatever reason, doesn't follow either
of the methods available in the RFC.
To make things even more complicated, I think the RFC is not
helping very much, as the definition is not very clear itself:
"
Description: The first TLS Finished message sent (note: the Finished
struct, not the TLS record layer message containing it) in the most
recent TLS handshake of the TLS connection being bound to (note: TLS
connection, not session, so that the channel binding is specific to
each connection regardless of whether session resumption is used).
If TLS renegotiation takes place before the channel binding
operation, then the first TLS Finished message sent of the latest/
inner-most TLS connection is used. Note that for full TLS
handshakes, the first Finished message is sent by the client, while
for abbreviated TLS handshakes (session resumption), the first
Finished message is sent by the server.
"
https://tools.ietf.org/html/rfc5929#section-3.1
If you read further, it becomes even less clear what it is and that
if there are re-negotiations, it gets more complicated. Server-end-point
is kind of better specified:
"
The hash of the TLS server's certificate [RFC5280] as it
appears, octet for octet, in the server's Certificate message.
"
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
