Hi Emeric, Lukas, Dirkjan
> Le 14 sept. 2018 à 11:12, Emeric Brun <[email protected]> a écrit : > > Hi Lukas, Dirkjan, > > On 09/13/2018 10:17 PM, Lukas Tribus wrote: >> Hello Dirkjan, >> >> >> On Thu, 13 Sep 2018 at 16:44, Dirkjan Bussink <[email protected]> wrote: >>> So with a new API call, does that mean adding for example a `ciphersuites` >>> option that works similar to `ciphers` today that it accepts a string and >>> then >>> calls `SSL_CTX_set_ciphersuites`? >> >> Yes, that's what I'd have in mind. Sufficiently #ifdef that everything >> still builds the same and documented of course so that people >> understand what is what. Let's wait for Manu and Emeric's feedback >> though, before investing your time. > > I think if TLSv <= 1.2 and TLSv1.3 ciphers are handled separately, this is > good reason > to add a new keyword to manage both at a same line on an haproxy > configuration file's line . > > I've just realized that it may be the openssl's response to an issue we faced > on earlier version of > openssl1.1.1 dev branch where forcing cipher suite on a SSL_CTX broke TLSv1.2 > handshakes if > no TLSv1.3 ciphers were specified in this list. > > Doing this, managing differently TLS <= v1.2 and 1.3 ciphers permits the user > to not face regression issues > upgrading to v1.1.1 when suites where forced in configuration because > openssl-1.1.1 kept default > TVSv1.3 ciphers. > Same deal with boringssl, TLSv <= 1.2 ciphers configuration and TLSv1.3 ciphers are segregated. https://boringssl.googlesource.com/boringssl/+/abbbee10ad4739648bcbf36a5ac52f23263a67dd%5E!/ > So i'm convinced we need to handle this new TLSv1.3 cipher suite with a new > config keyword, but I > don't know how we should name it. I think it will be a mistake to make appear > 1.3 in the new name because > there is no warranty that next TLS versions will specify specific cipher > lists. Openssl's > API make the choice of "ciphersuites" ... perhaps a the right choice. Following the API name should be the right choice. ++ Manu
