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

[Emmanuel Hocdet]

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

[Emeric Brun]

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

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

[Lukas Tribus]

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.

Same exact behavior happens with boringssl as well (not only openssl 1.1.1).


Any help with this would be much appreciated.


Thanks,
Lukas

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

[Lukas Tribus]

Hello Emeric,


On Wed, 30 May 2018 at 19:34, Lukas Tribus  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

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

[Lukas Tribus]

Hello,


On 22 May 2018 at 15:26, Lukas Tribus  wrote:
> Hello Emeric,
>
>
> On 22 May 2018 at 14:44, Emeric Brun  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

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

[Lukas Tribus]

Hello Emeric,


On 22 May 2018 at 14:44, Emeric Brun  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

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

[Emeric Brun]

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

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

[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(0003)
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(0003)
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