Re: [HACKERS] Channel binding support for SCRAM-SHA-256

On 01/06/17 17:50, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Wed, May 31, 2017 at 7:59 PM, Stephen Frost <sfrost@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