On Fri, Jun 29, 2018 at 10:37:55AM +0900, Michael Paquier wrote: > The set of APIs that we use to the SSL abstraction layer is very > internal, so it would not be an issue if we add some in stable branches, > no? My point is that from OpenSSL point of view, TLS 1.3 stuff has been > added in 1.1.1 which is now in beta 6 stage, so we could consider as > well all this part once OpenSSL is released. That's compatibility work > I wanted to work on anyway. Impossible to say down to which versions of > Postgres things could be applied easily though without a deep > investigation of the new compatibility breakages that upstream OpenSSL > has very-likely introduced in upstream. > > Still it does not sound completely strange either to me to wait for > OpenSSL to release as we won't be able to have a full solution designed > before that.
Actually, I got curious about that part and just compiled Postgres with OpenSSL 1.1.1 beta 6 that I compiled manually, and channel binding is generating consistent data for both tls-unique and tls-server-end-point even if TLS v1.3 is used, while tests in src/test/ssl/ are all able to pass. So that's less dramatic than what I thought after the melodrama of upgrading the code to 1.1.0. The thread where this is discussed is also kind of interesting as the last email points to having tls-unique deprecated for all the TLS versions: https://www.ietf.org/mail-archive/web/tls/current/msg18265.html I am able to find easily drafts of TLS 1.3, but I am not seeing an RFC associated to it, which would be the base document to rely on I guess... So that's really hard to make any decision in this area without the real deal. As far as I can see tls-unique could be deprecated and replaced, but from OpenSSL point of view it technically works. -- Michael
signature.asc
Description: PGP signature
