Hi Manu, On 03/17/2017 06:43 PM, Emmanuel Hocdet wrote: > >> Le 16 mars 2017 à 17:49, Emmanuel Hocdet <[email protected] >> <mailto:[email protected]>> a écrit : >> >> Hi Emeric, >> >>> Le 16 mars 2017 à 14:44, Emeric Brun <[email protected] >>> <mailto:[email protected]>> a écrit : >>> >>> I'm clearly not sure that setting openssl's options to ~no-tlsxx have the >>> same behavior than forcing the callback sets (using force-) to one protocol. >>> >>> I always suspected that no-tlsxx options applies on a kind of >>> 'capabilities' where as setting a callback-set clearly force the usage of a >>> protocol version. >>> >>> So for me the patch could modify some behavior for openssl versions < 1.1 >> >> I did not see any problems with 1.0.1, 1.0.2 documentation tends to say that >> it’s ok and 1.1.0 deprecated the haproxy ‘force’ implementation. >> At worst, this can change something in openssl 0.9.x but it's for haproxy >> 1.8dev… >> It seem that use SSL_CTX_set_options is a good compatibly choice. >> >> The only thing i see is that no-tlsxx can generate a not recommented >> configuration (1.0.2). >> "The list of protocols available can be further limited using the >> SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and >> SSL_OP_NO_TLSv1_2options of the SSL_CTX_set_options >> <https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_options.html> or >> SSL_set_options >> <https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_options.html> functions. >> Clients should avoid creating "holes" in the set of protocols they support, >> when disabling a protocol, make sure that you also disable either all >> previous or all subsequent protocol versions. In clients, when a protocol >> version is disabled without disabling all previous protocol versions, the >> effect is to also disable all subsequent protocol versions." >> >> Openssl introduce min-tlsxx max-tlsxx directives to avoid ‘holes’ >> configuration is equivalent to use SSL_CTX_set_options correctly. >> >>> There is another point which worries me: >>> >>> In the proposed patch, statement 'force-' will disable all known protocol >>> version except that one. >>> >>> 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 agree, TLSv1.3 is missing. min-tlsxx max-tlsxx openssl directives will be >> a better way to no care about new version. >> I have a second patch who add TLSv1.3 and min-tlsxx max-tlsxx haproxy >> directive (patch is ssl version agnostic). >> > With this patches, all tls versions are supported and it’s easy to add new > tls version internally. > min-tlsxx and max-tlsxx is supported for all ssllibs: configuration will be > more clear that with no-tlsxx and without « holes ». > Add SSL_CTX_set_min/max_proto_version could be a option but i does not see > the necessity. > > Manu > >
I'm still thinking that SSL_set_min/max_proto_version are a better approach to handle 'force-' options for openssl version >= 1.1 . Less intrusive for older openssl's versions and without any doubt on what they gonna do even if new protocols versions would appear. R, Emeric
