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. 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. Did any of you check how this is endled on "openssl s_client" command line? > > >> The curve functions are synonyms for the equivalently named group functions >> and are identical in every respect. > > So there is no technical reason to implement the new API call, it's > just to go with the new naming convention. No need for any action > then, we don't have to blow up our code with additional #ifdef mess > for the sake of using better looking names in API calls. Perfectly agreed. > > Thanks for looking into this! > > cheers, > lukas > R, Emeric
