Re: [PATCH] BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1
Hello Mano, On Mon, 3 Sep 2018 at 18:26, Emmanuel Hocdet wrote: > > Hi Lukas, Emeric > > This patch fix the issue. If you can check it. I confirm the patch fixes the original test case and also works fine in my Chrome on XP testbed (TLSv1.2, no ECC support). As you mentioned for clients using <= TLSv1.1 we now prefer RSA over ECC certificates. There is a small theoretical server side penalty for increased CPU load due to RSA handshake for impacted clients, but I am confident that this is neglectable. For the record this impacts Android 4.[0-3], Java 7 and Internet Explorer 7-10 on Vista and 7 (current IE11 on Windows 7 bumps the schannel configuration to TLSv1.2). Thanks for taking care of this! cheers, lukas
[PATCH] BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1
Hi Lukas, Emeric This patch fix the issue. If you can check it. Thanks Manu 0001-BUG-MEDIUM-ECC-cert-should-work-with-TLS-v1.2-and-op.patch Description: Binary data
Re: [PATCH] MEDIUM: lua: Add stick table support for Lua
On Fri, Aug 24, 2018 at 11:40:51PM +0200, Adis Nezirovic wrote: > Thierry, > > Something for Monday :-) > > Latest version of the patch in attachment: > > - Filter table format is flattened/simplified > - I've tried to address filter table format error messages > (what is the error, and which filter entry is wrong) > - Fixed one bug: stktable_get_data_type() return value can be < 0 > (i.e. filter table contains unknown data column) Hi Thierry, Have you had the time to review my patches? Best regards, Adis
Re: BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2
Hi Lukas, > Le 2 sept. 2018 à 15:31, Lukas Tribus a écrit : > On Sat, 1 Sep 2018 at 20:49, Lukas Tribus wrote: >>> I've confirmed the change in behavior only happens with an ECC >>> certificate, an RSA certificate is not affected. >> >> Just to confirm that this is still an actual problem with current >> haproxy and openssl 1.1.1pre9. >> >> You just have to use a ECC certificate instead of a RSA certificate, >> and it will fail with TLSv1.1 when strict-sni is enabled. > > Actually the problem is worse: SNI doesn't work *at all* with ECC > certificates in TLSv1.1 and TLSv1.0. It simply falls back to a > matching RSA certificate or the default-certificate. Of course, if > only the ECC certificate is there, and strict-sni is set, the > handshake is rejected. > > Same exact behavior happens with boringssl as well (not only openssl 1.1.1). > > > Any help with this would be much appreciated. > It’s in ssl_sock_switchctx_cbk for openssl 1.1.1/boringssl: /* without TLSEXT_TYPE_signature_algorithms extension (< TLS 1.2) */ has_ecdsa_sig is not enable -> no check for ECDSA cipher -> ECC certificate for TLS < 1.2 can’t be selected. strict-sni disable the default cert fallback, so handshake is rejected with no rsa certificate. Certificate selection must be changed to match this case (check for ECDSA cipher when TLS < 1.2). I can look at that. ++ Manu
Re: BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2
Hi Lukas, On 09/02/2018 03:31 PM, Lukas Tribus wrote: > Hello, > > > On Sat, 1 Sep 2018 at 20:49, Lukas Tribus wrote: >>> I've confirmed the change in behavior only happens with an ECC >>> certificate, an RSA certificate is not affected. >> >> Just to confirm that this is still an actual problem with current >> haproxy and openssl 1.1.1pre9. >> >> You just have to use a ECC certificate instead of a RSA certificate, >> and it will fail with TLSv1.1 when strict-sni is enabled. > > Actually the problem is worse: SNI doesn't work *at all* with ECC > certificates in TLSv1.1 and TLSv1.0. It simply falls back to a > matching RSA certificate or the default-certificate. Of course, if > only the ECC certificate is there, and strict-sni is set, the > handshake is rejected. Just to be sure, do you want to mean?: > only the ECC certificate is there, *OR* strict-sni is set, the > handshake is rejected. > Same exact behavior happens with boringssl as well (not only openssl 1.1.1). > > > Any help with this would be much appreciated. > We must go deeper, now the bug is more qualified. R, Emeric
