Michael,
* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Tue, May 30, 2017 at 8:14 AM, Stephen Frost <sfrost@snowman.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