Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, May 30, 2017 at 8:14 AM, Stephen Frost <sfr...@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
signature.asc
Description: Digital signature