Hi Manu, On 03/22/2017 06:24 PM, Emmanuel Hocdet wrote: > >> Le 22 mars 2017 à 16:30, Emmanuel Hocdet <[email protected]> a écrit : >> […] >> 0005 force-tlsxx implementation compatibility (Emeric first point) >> >> For the second point >>> But we will face issue using 'force-' when openssl will support further tls >>> versions not yet handled by haproxy. This problem was correctly handled by >>> the previous implementation. >> >> I can provide a patch for that but it will not useful for years until a new >> TLS will be implemented. It can generate build breaks until this time. >> . all TLS methods are known in haproxy (set_options usage is safe) >> . Haproxy must be run with the same version as the compilation. Change the >> openssl version (other than for bug fix) is not supported. > > By testing TLSv1.3 i noticed that per default, the version is disable and > can’t be used until SSL_CTX_set_max_proto_version is set with TLS1_3_VERSION. > So i will add a patch for SSL_CTX_set_max_proto_version with TLSv1.3 disable > per default. > > This look like what you might have encountered with initial openssl > development and force-tlsxx: activate a pending TLS version. > Does that tell you something Emeric? > > Manu > > >
I said that using SSL_CTX_set_max_proto_version and SSL_CTX_set_min_proto_version to handle force-tlsxx will keep it compliant for any newcoming protocol version. Using ~knownbitflags is not the case cause you have to predict further versions, to disable them. R, Emeric
