From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL JDBC List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Channel binding support for SCRAM-SHA-256 |
Date: | 2017-05-30 17:00:36 |
Message-ID: | 20170530170036.GZ3151@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
Michael,
* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> On Tue, May 30, 2017 at 8:14 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > 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 *)
Those look pretty reasonable to me and seem to go along with the
concepts from the RFC, making them hopefully the right API.
> > 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
Good.
> On macos though it is another story, I am not seeing anything:
> https://developer.apple.com/reference/security/secure_transport#symbols
That's a bit unfortunate, if that's the case. Perhaps Apple will see
fit to address that deficiency though.
> 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.
Right, of course.
All-in-all, this sounds like it's heading in the right direction, at
least at a high level. Glad to see that there's been consideration of
other TLS implementations, and as such I don't think we need to be
overly concerned about the specifics of the OpenSSL API here.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2017-05-30 17:01:17 | Re: Surjective functional indexes |
Previous Message | Tom Lane | 2017-05-30 16:56:58 | Re: Segmentation fault when creating a BRIN, 10beta1 |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2017-05-30 19:54:22 | Re: [JDBC] Channel binding support for SCRAM-SHA-256 |
Previous Message | Michael Paquier | 2017-05-30 16:25:58 | Re: [HACKERS] Channel binding support for SCRAM-SHA-256 |