Welcome! Log In Create A New Profile

Advanced

BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2

Posted by Lukas Tribus 
Hey guys,


we have a regression in 1.8 and -dev with OpenSSL 1.1.1 (from the
first beta to current master): when strict-sni is set, TLSv1.0 and
TLSv1.1 does not work (TLSv1.2 is fine). I haven't tested whether SNI
based certificate selection is broken as well, but strict-sni
definitely rejects TLSv1.1 and TLSv1.0 sessions (with the correct SNI
value).


Repro config:

frontend my-https-frontend
bind :443 ssl crt /home/lukas/cert/certdir/dev.lan.ltri.eu.pem strict-sni


I have bisected this to haproxy commit 84e417d85934 ("MINOR: ssl:
support Openssl 1.1.1 early callback for switchctx").


In haproxy debug mode we can see the following errors:

fd[0006] OpenSSL error[0x142090ea]
tls_early_post_process_client_hello: callback failed


and the openssl s_client (forcing TLSv1.1) fails like this:

$ openssl s_client -connect dev.lan.ltri.eu:443 -tls1_1 -servername
dev.lan.ltri.eu
CONNECTED(00000003)
140549797119640:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number:s3_pkt.c:362:



after commit c2aae74f01 ("MEDIUM: ssl: Handle early data with OpenSSL
1.1.1") the error changes:

fd[0006] OpenSSL error[0x1417a0c1] tls_post_process_client_hello: no
shared cipher


and the openssl s_client fails like this:

$ openssl s_client -connect dev.lan.ltri.eu:443 -tls1_1 -servername
dev.lan.ltri.eu
CONNECTED(00000003)
139752173131416:error:14094410:SSL routines:ssl3_read_bytes:sslv3
alert handshake failure:s3_pkt.c:1487:SSL alert number 40
139752173131416:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl
handshake failure:s3_pkt.c:656:



Haproxy 1.8 has these 2 commits as well. OpenSSL 1.1.0 is unaffected
of course (the changes only affect the API when openssl is 1.1.1).


Some naive and limited poking around with the code in question did not
return any results, so I'm "calling this in" now ;)



cheers,
lukas
Hi Lukas,

I've just made some tests using openssl-1.1.1-pre6 and can't reproduce the issue.

here my simple configuration:
frontend my
mode http
bind :443 ssl crt default strict-sni
redirect location /

(default certificate CN is aloha)

I've tested with openssl-1.1.1-pre6 as client without issue (same thing with 1.0.2g)

openssl s_client -connect 10.0.3.168:443 -tls1_1 -servername aloha
HS => OK
openssl s_client -connect 10.0.3.168:443 -tls1 -servername aloha
HS => OK
openssl s_client -connect 10.0.3.168:443 -tls1 -servername foobar
HS => KO

My haproxy sources are latest 1.8 + some backports from dev branch

Do you have any specific parameter related to ssl in your global section?

R,
Emeric
Hello Emeric,


On 22 May 2018 at 14:44, Emeric Brun <[email protected]> wrote:
> Hi Lukas,
>
> I've just made some tests using openssl-1.1.1-pre6 and can't reproduce the issue.
>
> here my simple configuration:
> frontend my
> mode http
> bind :443 ssl crt default strict-sni
> redirect location /
>
> (default certificate CN is aloha)
>
> I've tested with openssl-1.1.1-pre6 as client without issue (same thing with 1.0.2g)
>
> openssl s_client -connect 10.0.3.168:443 -tls1_1 -servername aloha
> HS => OK
> openssl s_client -connect 10.0.3.168:443 -tls1 -servername aloha
> HS => OK
> openssl s_client -connect 10.0.3.168:443 -tls1 -servername foobar
> HS => KO
>
> My haproxy sources are latest 1.8 + some backports from dev branch
>
> Do you have any specific parameter related to ssl in your global section?

I have this in the global section:
ssl-server-verify none
tune.ssl.default-dh-param 2048


And I am compiling openssl 1.1.1 with:
../config --prefix=/home/lukas/libsslbuild/ no-shared
enable-ec_nistp_64_gcc_128 enable-weak-ssl-ciphers

The certificate is NOT a RSA certificate, but a ECC certificate
(prime256v1, from Let's Encrypt, see https://crt.sh/?id=474207449)


Unsure if/what is triggering the behavior that is not present on your side.


thanks,
Lukas
Hello,


On 22 May 2018 at 15:26, Lukas Tribus <[email protected]> wrote:
> Hello Emeric,
>
>
> On 22 May 2018 at 14:44, Emeric Brun <[email protected]> wrote:
>> Hi Lukas,
>>
>> I've just made some tests using openssl-1.1.1-pre6 and can't reproduce the issue.
>>
>> here my simple configuration:
>> frontend my
>> mode http
>> bind :443 ssl crt default strict-sni
>> redirect location /
>>
>> (default certificate CN is aloha)
>>
>> I've tested with openssl-1.1.1-pre6 as client without issue (same thing with 1.0.2g)
>>
>> openssl s_client -connect 10.0.3.168:443 -tls1_1 -servername aloha
>> HS => OK
>> openssl s_client -connect 10.0.3.168:443 -tls1 -servername aloha
>> HS => OK
>> openssl s_client -connect 10.0.3.168:443 -tls1 -servername foobar
>> HS => KO
>>
>> My haproxy sources are latest 1.8 + some backports from dev branch
>>
>> Do you have any specific parameter related to ssl in your global section?

I've confirmed the change in behavior only happens with an ECC
certificate, an RSA certificate is not affected.


Can you retry with an ECC cert?


Thanks,
Lukas
Hello Emeric,


On Wed, 30 May 2018 at 19:34, Lukas Tribus <[email protected]> wrote:
> >> Do you have any specific parameter related to ssl in your global section?
>
> 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.


Can you confirm you are seeing the same issue, when using a ECC certificate?


Thanks,
Lukas
Hello,


On Sat, 1 Sep 2018 at 20:49, Lukas Tribus <[email protected]> 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.


Thanks,
Lukas
Hi Lukas,

On 09/02/2018 03:31 PM, Lukas Tribus wrote:
> Hello,
>
>
> On Sat, 1 Sep 2018 at 20:49, Lukas Tribus <[email protected]> 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
Emmanuel Hocdet
Re: BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2
September 03, 2018 12:00PM
Hi Lukas,

> Le 2 sept. 2018 à 15:31, Lukas Tribus <[email protected]> a écrit :
> On Sat, 1 Sep 2018 at 20:49, Lukas Tribus <[email protected]> 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
Hi Lukas, Emeric

This patch fix the issue. If you can check it.
Thanks
Manu
Attachments:
open | download - 0001-BUG-MEDIUM-ECC-cert-should-work-with-TLS-v1.2-and-op.patch (4.4 KB)
Hello Mano,


On Mon, 3 Sep 2018 at 18:26, Emmanuel Hocdet <[email protected]> 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
On Mon, Sep 03, 2018 at 06:26:38PM +0200, Emmanuel Hocdet wrote:
> Hi Lukas, Emeric
>
> This patch fix the issue. If you can check it.

Cool, applied now. Thank you guys!

Willy
Sorry, only registered users may post in this forum.

Click here to login