Re: USE_QUIC=1 support for awslc

[Frederic Lecaille]

On 1/24/24 05:58, Yaacov Akiba Slama wrote:
> So right now, the only thing missing in aws_lc in order to fully support
> quic is the implementation of EVP_chacha20() ?

This is one of the *identified* things which are missing in addition to
TLS_AES_128_CCM_SHA256 which cannot be enabled. This does not mean there
is no others which are not identified yet.

Re: USE_QUIC=1 support for awslc

[Yaacov Akiba Slama]

So right now, the only thing missing in aws_lc in order to fully support 
quic is the implementation of EVP_chacha20() ?

Thanks a lot for your work,
--yas

On 23/01/2024 17:18, Frederic Lecaille wrote:

FYI, I have just pushed 4 patches to master to make haproxy support
0-RTT when built against aws-lc TLS stack.

Regards.

Re: USE_QUIC=1 support for awslc

[Frederic Lecaille]

On 1/15/24 17:16, Yaacov Akiba Slama wrote:
> On 04/10/2023 18:38, William Lallemand wrote:
>> Hello,
>>
>> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya
>> mentionned.
>>
>> For now:
>>
>>     - 0RTT was disabled.
>>     - TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256
>> were disabled
> 
> https://github.com/aws/aws-lc/commit/bc9b35c4f5a34edcc7ed5ae86f24116198f61456 
> and 
> https://github.com/aws/aws-lc/commit/f7798b764b95692d865fa0e067558deb8be3926a 
> were merged, so perhaps this can be revisited.
> 
> What is missing to have 0RTT support?

FYI, I have just pushed 4 patches to master to make haproxy support
0-RTT when built against aws-lc TLS stack.

Regards.

Re: USE_QUIC=1 support for awslc

[Frederic Lecaille]

On 1/17/24 00:53, Hopkins, Andrew wrote:
> AWS-LC recently plumbed support for ChaChaPoly and AES CCM through the 
> existing EVP_CIPHER API that HAProxy uses in 
> https://github.com/aws/aws-lc/pull/1311 and 
> https://github.com/aws/aws-lc/pull/1373. Do you need support for just the 
> cipher EVP_chacha20? 

Yes, EVP_chacha20 is required to protect the QUIC packet header (so
without AAD and with a longer IV length compared to EVP_chacha20_poly1305.

About TLS_AES_128_CCM_SHA256, I have noticed that it is disabled by
aws-lc during TLS 1.3 QUIC sessions. Even when I set the default
ciphersuites as mentionned in my previous mail. This is done by a call
to SSL_CTX_set_ciphersuites(). I have not found any
TLS_AES_128_CCM_SHA256 strings into aws-lc source code. So, I guess this
is the root cause of this issue.

Re: USE_QUIC=1 support for awslc

[Hopkins, Andrew]

AWS-LC recently plumbed support for ChaChaPoly and AES CCM through the existing 
EVP_CIPHER API that HAProxy uses in https://github.com/aws/aws-lc/pull/1311 and 
https://github.com/aws/aws-lc/pull/1373. Do you need support for just the 
cipher EVP_chacha20? 

On 1/16/24, 5:30 AM, "Frederic Lecaille" mailto:flecai...@haproxy.com>> wrote:


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.






On 1/16/24 14:25, Frederic Lecaille wrote:
> On 1/15/24 17:16, Yaacov Akiba Slama wrote:
>> On 04/10/2023 18:38, William Lallemand wrote:
>>> Hello,
>>>
>>> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya
>>> mentionned.
>>>
>>> For now:
>>>
>>> - 0RTT was disabled.
>>> - TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256
>>> were disabled
>>
>> https://github.com/aws/aws-lc/commit/bc9b35c4f5a34edcc7ed5ae86f24116198f61456
>>  
>> 
>>  and 
>> https://github.com/aws/aws-lc/commit/f7798b764b95692d865fa0e067558deb8be3926a
>>  
>> 
>>  were merged, so perhaps this can be revisited.
>>
>> What is missing to have 0RTT support?
>>
>>> - clienthello callback is missing, certificate selection could be
>>> limited (RSA + ECDSA at the same time)
>>
>>
>
> About TLS_AES_128_CCM_SHA256 and *quictls*, this haproxy setting is
> required:
>
> ssl-default-bind-ciphersuites
> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256
>
> because the TLS stack disables TLS_AES_128_CCM_SHA256 by default.
>
> About *aws-lc*, even with this patch to reactivate
> TLS_AES_128_CCM_SHA256 and the setting above the connection are closed
> with NO_SHARED_CIPHER as OpenSSL internal error :
>
> diff --git a/include/haproxy/quic_tls.h b/include/haproxy/quic_tls.h
> index 86b8c1ee32..742118a82e 100644
> --- a/include/haproxy/quic_tls.h
> +++ b/include/haproxy/quic_tls.h
> @@ -144,7 +144,7 @@ static inline const EVP_CIPHER *tls_aead(const
> SSL_CIPHER *cipher)
> case TLS1_3_CK_CHACHA20_POLY1305_SHA256:
> return EVP_chacha20_poly1305();
> #endif
> -#if !defined(USE_OPENSSL_WOLFSSL) && !defined(OPENSSL_IS_AWSLC)
> +#if !defined(USE_OPENSSL_WOLFSSL)
> case TLS1_3_CK_AES_128_CCM_SHA256:
> return EVP_aes_128_ccm();
> #endif
>
>
>


Should have mentionned that I use ngtcp2 as client to enforce a unique
cipher (TLS1_3_CK_CHACHA20_POLY1305_SHA256 or
TLS1_3_CK_AES_128_CCM_SHA256) to connect to haproxy.

Re: USE_QUIC=1 support for awslc

[Frederic Lecaille]

On 1/16/24 14:25, Frederic Lecaille wrote:
> On 1/15/24 17:16, Yaacov Akiba Slama wrote:
>> On 04/10/2023 18:38, William Lallemand wrote:
>>> Hello,
>>>
>>> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya
>>> mentionned.
>>>
>>> For now:
>>>
>>>     - 0RTT was disabled.
>>>     - TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256
>>> were disabled
>>
>> https://github.com/aws/aws-lc/commit/bc9b35c4f5a34edcc7ed5ae86f24116198f61456
>>  and 
>> https://github.com/aws/aws-lc/commit/f7798b764b95692d865fa0e067558deb8be3926a
>>  were merged, so perhaps this can be revisited.
>>
>> What is missing to have 0RTT support?
>>
>>>     - clienthello callback is missing, certificate selection could be 
>>> limited (RSA + ECDSA at the same time)
>>
>>
> 
> About TLS_AES_128_CCM_SHA256 and *quictls*, this haproxy setting is
> required:
> 
> ssl-default-bind-ciphersuites
> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256
> 
> because the TLS stack disables TLS_AES_128_CCM_SHA256 by default.
> 
> About *aws-lc*, even with this patch to reactivate
> TLS_AES_128_CCM_SHA256 and the setting above the connection are closed
> with NO_SHARED_CIPHER as OpenSSL internal error :
> 
> diff --git a/include/haproxy/quic_tls.h b/include/haproxy/quic_tls.h
> index 86b8c1ee32..742118a82e 100644
> --- a/include/haproxy/quic_tls.h
> +++ b/include/haproxy/quic_tls.h
> @@ -144,7 +144,7 @@ static inline const EVP_CIPHER *tls_aead(const
> SSL_CIPHER *cipher)
> case TLS1_3_CK_CHACHA20_POLY1305_SHA256:
> return EVP_chacha20_poly1305();
>  #endif
> -#if !defined(USE_OPENSSL_WOLFSSL) && !defined(OPENSSL_IS_AWSLC)
> +#if !defined(USE_OPENSSL_WOLFSSL)
> case TLS1_3_CK_AES_128_CCM_SHA256:
> return EVP_aes_128_ccm();
>  #endif
> 
> 
> 

Should have mentionned that I use ngtcp2 as client to enforce a unique
cipher (TLS1_3_CK_CHACHA20_POLY1305_SHA256 or
TLS1_3_CK_AES_128_CCM_SHA256) to connect to haproxy.

Re: USE_QUIC=1 support for awslc

[Frederic Lecaille]

On 1/15/24 17:16, Yaacov Akiba Slama wrote:
> On 04/10/2023 18:38, William Lallemand wrote:
>> Hello,
>>
>> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya
>> mentionned.
>>
>> For now:
>>
>>     - 0RTT was disabled.
>>     - TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256
>> were disabled
> 
> https://github.com/aws/aws-lc/commit/bc9b35c4f5a34edcc7ed5ae86f24116198f61456 
> and 
> https://github.com/aws/aws-lc/commit/f7798b764b95692d865fa0e067558deb8be3926a 
> were merged, so perhaps this can be revisited.
> 
> What is missing to have 0RTT support?
> 
>>     - clienthello callback is missing, certificate selection could be 
>> limited (RSA + ECDSA at the same time)
> 
> 

About TLS_AES_128_CCM_SHA256 and *quictls*, this haproxy setting is
required:

ssl-default-bind-ciphersuites
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256

because the TLS stack disables TLS_AES_128_CCM_SHA256 by default.

About *aws-lc*, even with this patch to reactivate
TLS_AES_128_CCM_SHA256 and the setting above the connection are closed
with NO_SHARED_CIPHER as OpenSSL internal error :

diff --git a/include/haproxy/quic_tls.h b/include/haproxy/quic_tls.h
index 86b8c1ee32..742118a82e 100644
--- a/include/haproxy/quic_tls.h
+++ b/include/haproxy/quic_tls.h
@@ -144,7 +144,7 @@ static inline const EVP_CIPHER *tls_aead(const
SSL_CIPHER *cipher)
case TLS1_3_CK_CHACHA20_POLY1305_SHA256:
return EVP_chacha20_poly1305();
 #endif
-#if !defined(USE_OPENSSL_WOLFSSL) && !defined(OPENSSL_IS_AWSLC)
+#if !defined(USE_OPENSSL_WOLFSSL)
case TLS1_3_CK_AES_128_CCM_SHA256:
return EVP_aes_128_ccm();
 #endif

Re: USE_QUIC=1 support for awslc

[Frederic Lecaille]

On 1/15/24 17:16, Yaacov Akiba Slama wrote:
> On 04/10/2023 18:38, William Lallemand wrote:
>> Hello,
>>
>> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya
>> mentionned.
>>
>> For now:
>>
>>     - 0RTT was disabled.
>>     - TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256
>> were disabled
> 
> https://github.com/aws/aws-lc/commit/bc9b35c4f5a34edcc7ed5ae86f24116198f61456 
> and 
> https://github.com/aws/aws-lc/commit/f7798b764b95692d865fa0e067558deb8be3926a 
> were merged, so perhaps this can be revisited.
> 
> What is missing to have 0RTT support?
> 
>>     - clienthello callback is missing, certificate selection could be 
>> limited (RSA + ECDSA at the same time)
> 
> 

To me there are two ciphers to be implemented by aws-lc to make QUIC
works with TLS_CHACHA20_POLY1305_SHA256 cipher: EVP_chacha20_poly1305()
and EVP_chacha20(). Perhaps I have missed something but EVP_chacha20()
is missing.

Regards,

Fred.

Re: USE_QUIC=1 support for awslc

[Yaacov Akiba Slama]

On 04/10/2023 18:38, William Lallemand wrote:

Hello,

I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya
mentionned.

For now:

- 0RTT was disabled.
- TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256 were 
disabled


https://github.com/aws/aws-lc/commit/bc9b35c4f5a34edcc7ed5ae86f24116198f61456 
and 
https://github.com/aws/aws-lc/commit/f7798b764b95692d865fa0e067558deb8be3926a 
were merged, so perhaps this can be revisited.


What is missing to have 0RTT support?


- clienthello callback is missing, certificate selection could be  limited 
(RSA + ECDSA at the same time)

USE_QUIC=1 support for awslc

[William Lallemand]

Hello,

I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya
mentionned.

For now:

   - 0RTT was disabled.
   - TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256 were 
disabled
   - clienthello callback is missing, certificate selection could be  limited 
(RSA + ECDSA at the same time)


I could made some tests with curl --http3 and firefox which seems to be
working, no chance with chrome yet.

At least we activated the build so I'll check the next steps:

> чт, 7 сент. 2023 г. в 00:05, Hopkins, Andrew :
> > 1. AWS-LC plumbs these two algorithms through the EVP_CIPHER API. This is
> > useful for HAProxy and other AWS-LC customers, but is the most work

That would be the best from a maintainance point of view.

> > 2. HAProxy adopts AWS-LC’s (and BoringSSL’s) AEAD API
> >

Well, since it exists in awslc, libressl and boringssl, maybe we could
spend some time on this, I'll check if this is complicated to integrate
in our current code.

> > 3. HAProxy turns off ChaCha Poly and AES CCM support in quic when built
> > with AWS-LC

That's the current status for now.

-- 
William Lallemand