Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Sat, May 27, 2017 at 5:59 PM, Álvaro Hernández Tortosa > > <a...@8kdata.com> wrote: > >> - tls-unique, as you mentioned, uses two undocumented APIs. This raises a > >> small flag about the stability and future of those APIs. > > > It seems to me that the question is not just whether those APIs will > > be available in future versions of OpenSSL, but whether they will be > > available in every current and future version of every SSL > > implementation that we may wish to use in core or that any client may > > wish to use. We've talked before about being able to use the Windows > > native SSL implementation rather than OpenSSL and it seems that there > > would be significant advantages in having that capability. > > Another thing of the same sort that should be on our radar is making > use of Apple's TLS code on macOS. The handwriting on the wall is > unmistakable that they intend to stop shipping OpenSSL before long, > and I do not think we really want to be in a position of having to > bundle OpenSSL into our distribution on macOS. > > I'm not volunteering to do that, mind you. But +1 for not tying new > features to any single TLS implementation.
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 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). 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). 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. Thanks! Stephen
signature.asc
Description: Digital signature
