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

On Tue, May 30, 2017 at 8:14 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Work has been done in that area already, as well as for LibNSS support.
>
> I've not had a chance to closely look over the proposed approach here,
> but generally speaking, we need to be looking for a standard way to
> generate and transmit the channel binding information across the
> wire.

The RFC of SCRAM specifies that the client sends the type of channel
binding in its first message data, and then provides the contents of
the TLS message it generated in the challenge response.

> The specific APIs are, certainly, going to be different between
> different TLS implementations and I don't believe we need to be
> particularly concerned with that (or if they change in the future), as
> long as we abstract those APIs. Perhaps there's some question as to
> just how to abstract them, but I'm at least a bit less concerned with
> that as I expect we'll be able to adjust those abstraction layers later
> (presuming they aren't exposed, which I wouldn't expect them to be).

The current patch fetches the TLS finish message data just after the
handshake in be_tls_open_server() using the dedicated OpenSSL API. We
could definitely go with a more generic routine on our side that
sticks with the concepts of be_tls_get_compression():
- For the backend, this routine returns an allocated string with the
contents of the expected TLS message, and its size:
char *be_tls_get_tls_finish(Port *, int *)
- For the frontend, a routine to get the generated TLS finish message:
char *pgtls_get_tls_finish(PGconn *, int *)

> I skimmed over RFC5929, which looks to be the correct RFC when it comes
> to channel binding with TLS. Hopefully the various TLS implementations
> work in a similar manner, following that RFC (or whichever is relevant).

That's the one I use as a reference.

> If that wasn't the case then, for example, it wouldn't be possible to do
> channel binding with a LibNSS client and an OpenSSL server or with other
> combinations and I find that rather hard to believe.

As far as I can see, Windows has some APIs to get the TLS finish message:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa382420(v=vs.85).aspx
On macos though it is another story, I am not seeing anything:
https://developer.apple.com/reference/security/secure_transport#symbols

Depending on the SSL implementation the server is compiled with, it
will be up to the backend to decide if it should advertise to the
client the -PLUS mechanism or not, so we can stay modular here.
--
Michael