Beta Branch prep for Nginx AWS-LC crypto library support in 130.00beta01

prep for Nginx AWS-LC crypto library support in 130.00beta01

---

- Add Centmin Mod Nginx crypto library support for AWS-LC which is a fork that combines OpenSSL and BoringSSL with HTTP/3 QUIC support created by Amazon GitHub - aws/aws-lc: AWS-LC is a general-purpose cryptographic library maintained by the AWS Cryptography team for AWS and their customers. It іs based on code from the Google BoringSSL project and the OpenSSL project.. With this addition, Centmin Mod Nginx would optionally support OpenSSL 1.1.1/3.0/3.1/3.2/3.3, LibreSSL, quicTLS OpenSSL fork, BoringSSL and AWS-LC crypto libraries
- This only adds AWS-LC crypto library for Nginx to to compile against for HTTP/3 QUIC support. However, Nginx directives required for enable HTTP/3 are not automatically configured right now. This commit is to just test if Centmin Mod Nginx compiles against AWS-LC first
- Intended to support EL8 and EL9 operating systems for Nginx 1.27.0 or higher versions only so no CentOS 7 support

Example Centmin Mod Nginx 1.27.0 built with AWS-LC crypto library and --with-http_v3_module module for HTTP/3 QUIC support on AlmaLinux 8

Continue reading...

130.00beta01 branch

• Branch: GitHub - centminmod/centminmod at 130.00beta01
• Commit History: Commits · centminmod/centminmod

Support Centmin Mod

If you find Centmin Mod useful, please help support Centmin Mod

 

Centmin Mod Nginx 1.27.0 built against AWS-LC 1.29.0 to support HTTP/3 QUIC. AWS-LC combines the best of both OpenSSL and BoringSSL. So unlike BoringSSL, AWS-LC retains support for dual RSA + ECDSA SSL certificate support and OSCP stapling support that were present in OpenSSL Right now though AWS-LC doesn't have TLSv1.3 session resumption/ticket support AFAIK.

test against custom curl 8.9.0 dev built with HTTP/3 QUIC support via Cloudflare Quiche/BoringSSL library

Test custom curl 8.9.0 HTTP/3 QUIC request against Centmin Mod Nginx 1.27.0 built against AWS-LC 1.29.0

Code (Text):

curl -Ik --http3 https://domain.com
HTTP/3 200
date: Tue, 11 Jun 2024 11:59:21 GMT
content-type: text/html; charset=utf-8
content-length: 6356
last-modified: Tue, 11 Jun 2024 11:51:21 GMT
vary: accept-encoding
etag: "66683a39-18d4"
server: nginx centminmod
x-powered-by: centminmod
alt-svc: h3=":8443"; ma=86400
accept-ranges: bytes

 

AWS-LC aim is to combine the best of BoringSSL + OpenSSL so intended to keep OCSP stapling and support dual RSA + ECDSA SSL certs. Though according to Haproxy folks, dual cert SNI domain detection is currently broken - I tested dual certs on Centmin Mod Nginx + AWS-LC and confirmed it's broken it only serves ECDSA SSL cert not the RSA one so that needs work. But aim of AWS-LC is to have all benefits of BoringSSL with missing OpenSSL features.

While BoringSSL is more development oriented, AWS-LC aims to have more stable releases and it's one of the front runners also for Haproxy folks looking at replacing quicTLS QUIC OpenSSL 1.1.1 fork for HTTP/3 QUIC support. Haproxy is ruling out OpenSSL 3.0 as it's tested at 1/10th performance of OpenSSL 1.1.1 for Haproxy work loads and OpenSSL 3.1/3.2 is at 1/4th performance of OpenSSL 1.1.1. AWS-LC is comparable performance to OpenSSL 1.1.1. For my tests ECDSA ciphers, AWS-LC is even faster than OpenSSL 1.1.1 just like BoringSSL is faster for ECDSA. Expected as AWS-LC is based off of BoringSSL + OpenSSL 1.1.1.

Info at

• GitHub - aws/aws-lc: AWS-LC is a general-purpose cryptographic library maintained by the AWS Cryptography team for AWS and their customers. It іs based on code from the Google BoringSSL project and the OpenSSL project.
• And AWS already got AWS-LC FIP certified AWS-LC is now FIPS 140-3 certified | Amazon Web Services

I tested Centmin Mod Nginx 1.27 + AWS-LC 1.29.0 against testssl tool and a self-signed SSL cert domain.com Nginx vhost just to see what it reports. Of course OCSP can't be tested on signed-self SSL cert though.

Code (Text):

/usr/local/src/centminmod/tools/switch-nginx-ciphers.sh testssl domain.com
testssl.sh --nodns=min --wide -p -c -f -E -S -P --quiet https://domain.com

 Start 2024-06-12 04:20:00                -->> 192.168.122.53:443 (domain.com) <<--

 Further IP addresses: 
 A record via:           /etc/hosts
 rDNS (192.168.122.53):  (instructed to minimize DNS queries)
 Service detected:       HTTP


 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1 (offered)

 Testing server's cipher preferences

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
SSLv2
 -
SSLv3
 -
TLSv1
 -
TLSv1.1
 -
TLSv1.2 (server order)
 xc02b   ECDHE-ECDSA-AES128-GCM-SHA256     ECDH 253   AESGCM      128      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256         
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 253   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384         
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 253   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256   
TLSv1.3 (no server order, thus listed by strength)
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                           
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                     
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                           

 Has server cipher order?     yes (OK) -- only for < TLS 1.3


 Testing robust forward secrecy (FS) -- omitting Null Authentication/Encryption, 3DES, RC4

 FS is offered (OK) , ciphers follow (client/browser support is important here)

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                           
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                     
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 256   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384         
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 253   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256   
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                           
 xc02b   ECDHE-ECDSA-AES128-GCM-SHA256     ECDH 256   AESGCM      128      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256         

 Elliptic curves offered:     prime256v1 secp384r1 X25519
 TLS 1.2 sig_algs offered:    ECDSA+SHA256 ECDSA+SHA384 ECDSA+SHA512 ECDSA+SHA1
 TLS 1.3 sig_algs offered:    ECDSA+SHA256

 Testing server defaults (Server Hello)

 TLS extensions (standard)    "server name/#0" "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35"
                              "key share/#51" "supported versions/#43" "extended master secret/#23"
                              "application layer protocol negotiation/#16"
 Session Ticket RFC 5077 hint 3600 seconds, session tickets keys seems to be rotated < daily
 SSL Session ID support       yes
 Session Resumption           Tickets: yes, ID: yes
 TLS clock skew               Random values, no fingerprinting possible
 Certificate Compression      none
 Client Authentication        none
 Signature Algorithm          ECDSA with SHA256
 Server key size              EC 256 bits (curve P-256)
 Server key usage             Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
 Server extended key usage    --
 Serial                       1EC9CFAD16D2BC2A42B2DB4A0D5AE7E572E5B3B7 (OK: length 20)
 Fingerprints                 SHA1 5EFC5FB06A26CBDA90D632401096EE53C037A40C
                              SHA256 6B61B19593FF5A21826228EE9DD89F2046597FD2D0AED30584B92393335E133F
 Common Name (CN)             domain.com
 subjectAltName (SAN)         domain.com www.domain.com
 Trust (hostname)             Ok via SAN and CN (same w/o SNI)
 Chain of trust               NOT ok (chain incomplete)
 EV cert (experimental)       no
 Certificate Validity (UTC)   36499 >= 60 days (2024-06-11 17:11 --> 2124-05-18 17:11)
                              >= 10 years is way too long
 ETS/"eTLS", visibility info  not present
 Certificate Revocation List  --
 OCSP URI                     --
                              NOT ok -- neither CRL nor OCSP URI provided
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    (instructed to minimize/skip DNS queries)
 Certificate Transparency     --
 Certificates provided        1
 Issuer                       domain.com (domain.com from US)
 Intermediate Bad OCSP (exp.) Ok



 Testing ciphers per protocol via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
SSLv2
 -
SSLv3
 -
TLS 1
 -
TLS 1.1
 -
TLS 1.2
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 256   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384         
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 253   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256   
 xc02b   ECDHE-ECDSA-AES128-GCM-SHA256     ECDH 256   AESGCM      128      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256         
TLS 1.3
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                           
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                     
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                           

 Running client simulations (HTTP) via sockets

 Browser                      Protocol  Cipher Suite Name (OpenSSL)       Forward Secrecy
------------------------------------------------------------------------------------------------
 Android 6.0                  TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 Android 7.0 (native)         TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 Android 8.1 (native)         TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Android 10.0 (native)        TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Android 11 (native)          TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Android 12 (native)          TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Chrome 79 (Win 10)           TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Chrome 101 (Win 10)          TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Firefox 100 (Win 10)         TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      No connection
 IE 11 Win 7                  TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 IE 11 Win 8.1                TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 IE 11 Win Phone 8.1          TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 IE 11 Win 10                 TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 Edge 15 Win 10               TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     253 bit ECDH (X25519)
 Edge 101 Win 10 21H2         TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Safari 12.1 (iOS 12.2)       TLSv1.3   TLS_CHACHA20_POLY1305_SHA256      253 bit ECDH (X25519)
 Safari 13.0 (macOS 10.14.6)  TLSv1.3   TLS_CHACHA20_POLY1305_SHA256      253 bit ECDH (X25519)
 Safari 15.4 (macOS 12.3.1)   TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 Java 11.0.2 (OpenJDK)        TLSv1.3   TLS_AES_128_GCM_SHA256            256 bit ECDH (P-256)
 Java 17.0.3 (OpenJDK)        TLSv1.3   TLS_AES_256_GCM_SHA384            253 bit ECDH (X25519)
 go 1.17.8                    TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 LibreSSL 2.8.3 (Apple)       TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     253 bit ECDH (X25519)
 OpenSSL 1.0.2e               TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 OpenSSL 1.1.0l (Debian)      TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     253 bit ECDH (X25519)
 OpenSSL 1.1.1d (Debian)      TLSv1.3   TLS_AES_256_GCM_SHA384            253 bit ECDH (X25519)
 OpenSSL 3.0.3 (git)          TLSv1.3   TLS_AES_256_GCM_SHA384            253 bit ECDH (X25519)
 Apple Mail (16.0)            TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 Thunderbird (91.9)           TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)

 Done 2024-06-12 04:20:30 [  32s] -->> 192.168.122.53:443 (domain.com) <<--

 

Only tested testing with AWS-LC 1.29.0 so no sure about other releases. But AWS-LC is definitely on my short list as AWS-LC aim to make it work with common open source software. Also from all integrations I have done, AWS-LC was easiest to add and compiled the fastest - way faster than OpenSSL 1.1.1/3.x, LibreSSL, BoringSSL, QuicTLS for compile speed!

Their BoringSSL integration might not be the latest as I tried testing Cloudflare Post-Quantum KEM Kyber768 ciphers on Centmin Mod Nginx + AWS-LC and didn't work like it did with straight Centmin Mod Nginx + BoringSSL https://blog.centminmod.com/2023/10...68-key-exchange-support-in-centmin-mod-nginx/

Centmin Mod Nginx + AWS-LC doesn't support Post-Quantum Kyber768 Nginx curves when i tried to se

Code (Text):

ssl_ecdh_curve X25519Kyber768Draft00:X25519;

I got

Code (Text):

nginx -t
nginx: [emerg] SSL_CTX_set1_curves_list("X25519Kyber768Draft00:X25519") failed
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed

 

Just to a properly Centmin Mod Nginx 1.27.0 + AWS-LC crypto library for SSLlabs test with dual RSA+ECDSA SSL certificates and can confirm currently dual RSA+ECDSA SSL certs is not working in AWS-LC, it serves the ECDSA SSL certificate and SSLlabs isn't listing RSA ciphers as available. But good news seems AWS-LC crypto has working OCSP stapling and TLS session resumption/caching

 

If folks are interested in testing Centmin Mod Nginx built with Amazon AWS-LC crypto library, on Centmin Mod 130.00beta01 based EL8/EL9 systems only, you set AWS_LC_SWITCH='y' in persistent config file /etc/centminmod/custom_config.inc and run cmupdate + recompile Nginx via centmin.sh menu option 4

 

Looks like AWS-LC does support dual RSA + ECDSA SSL certificates after all. I had mistakenly disabled the RSA SSL cert in my Centmin Mod Nginx vhost I was testing when I was testing something else and forgot to re-enable it. With RSA + ECDSA SSL certificates setup again, Nginx compiled with AWS-LC does work according to testssl.sh and SSLLabs tests

Code (Text):

 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1 (offered)

Code (Text):

 Testing server's cipher preferences

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
SSLv2
 -
SSLv3
 -
TLSv1
 -
TLSv1.1
 -
TLSv1.2 (server order)
 xc02b   ECDHE-ECDSA-AES128-GCM-SHA256     ECDH 253   AESGCM      128      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256        
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 253   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256          
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 253   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384        
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 253   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384          
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 253   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256  
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256    
TLSv1.3 (no server order, thus listed by strength)
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                          
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                    
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                          

 Has server cipher order?     yes (OK) -- only for < TLS 1.3


 Testing robust forward secrecy (FS) -- omitting Null Authentication/Encryption, 3DES, RC4

 FS is offered (OK) , ciphers follow (client/browser support is important here)

Code (Text):

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                          
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                    
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 253   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384          
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 253   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384        
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 253   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256  
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256    
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                          
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 253   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256          
 xc02b   ECDHE-ECDSA-AES128-GCM-SHA256     ECDH 256   AESGCM      128      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256        

 Elliptic curves offered:     prime256v1 secp384r1 X25519
 TLS 1.2 sig_algs offered:    RSA-PSS-RSAE+SHA256 RSA+SHA256 RSA-PSS-RSAE+SHA384 RSA+SHA384 RSA-PSS-RSAE+SHA512 RSA+SHA512 RSA+SHA1 ECDSA+SHA256
                              ECDSA+SHA384 ECDSA+SHA512 ECDSA+SHA1
 TLS 1.3 sig_algs offered:    ECDSA+SHA256 RSA-PSS-RSAE+SHA256 RSA-PSS-RSAE+SHA384 RSA-PSS-RSAE+SHA512

 Testing server defaults (Server Hello)

 TLS extensions (standard)    "server name/#0" "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35" "status request/#5"
                              "key share/#51" "supported versions/#43" "extended master secret/#23" "application layer protocol negotiation/#16"
 Session Ticket RFC 5077 hint 3600 seconds, session tickets keys seems to be rotated < daily
 SSL Session ID support       yes
 Session Resumption           Tickets: yes, ID: yes
 TLS clock skew               Random values, no fingerprinting possible
 Certificate Compression      none
 Client Authentication        none

 

In practice, the key exchange algorithm used is determined by the certificate type selected by the client during the TLS handshake.

You only see ECDH being used, likely due to the client's preference or capabilities. When both RSA and ECDSA certificates are available, many modern clients prefer ECDSA because it generally offers better performance and stronger security per key size than RSA. Therefore, ECDH (Elliptic Curve Diffie-Hellman) is used as the key exchange method when an ECDSA certificate is chosen.

If the client does not support ECDSA or prefers RSA, then RSA-based key exchange methods would be used instead. You can confirm this by testing with different clients or tools that explicitly allow you to specify which certificate to use during the TLS handshake.

Code (Text):

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -cipher 'ECDHE-RSA-AES128-GCM-SHA256'

But seems with Nginx with AWS_LC, it's still serving KEX ECDH.

Code (Text):

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2325 bytes and written 332 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Code (Text):

nginx -V
nginx version: nginx/1.27.1 (280824-115129-almalinux8-174377d-br-a71f931)
built by gcc 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC)
built with [B]OpenSSL 1.1.1 (compatible; AWS-LC 1.34.2) (running with AWS-LC 1.34.2)[/B]

then switched Centmin Mod Nginx HTTP/3 QUIC with OpenSSL 3.1.5 quicTLS fork and dual RSA + ECDSA SSL certificates working when falling back to RSA

Code (Text):

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -cipher 'ECDHE-RSA-AES128-GCM-SHA256'

defaulted to TLSv1.3 and still showed ECDSA

Code (Text):

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2392 bytes and written 332 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

TLSv1.2 shows RSA though

Code (Text):

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -tls1_2

Code (Text):

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3233 bytes and written 248 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

So yup AWS_LC dual RSA + ECDSA SSL certificate support in Nginx still needs work.

 

Yeah if you want HTTP/3 and dual RSA + ECDSA SSL cert, put your site behind Cloudflare paid plan

Though the 2 arguments for Centmin Mod Nginx using BoringSSL or AWS_LC is Nginx HTTPS performance overall (CF edge to origin connection) and if you want to use Cloudflare Post-Quantum KEX to connect to Centmin Mod Nginx origins https://blog.centminmod.com/2023/10...68-key-exchange-support-in-centmin-mod-nginx/

Yeah with OpenSSL 1.1.1 EOL and QuicTLS stuck for 3.2, I lean towards AWS_LC still https://community.centminmod.com/threads/openssl-1-1-1-eol-alternatives.25488/

 

Yup. The most recent servers I've set up are using Centmin Mod 140.00beta01 with Nginx and AWS_LC behind Cloudflare with Post-Quantum KEX. It also serves a other purposes in actually using and testing it in production + also still testing Centmin Mod Nginx HTTP/3 QUIC support

Also with backing of Amazon AWS, AWS_LC is improving everyday. They're now looking at adding AVX512 CPU instruction support for accelerating RSA performance. With right CPUs with AVX512 support, would improve performance for RSA based cryptographic tasks https://github.com/aws/aws-lc/pull/1273 . The difference in resources and motivation for improving AWS_LC is way greater than for OpenSSL development and focus

So whether AWS_LC supports dual RSA + ECDSA SSL certs might not matter when default RSA has accelerated performance eventually when Centmin Mod Nginx + AWS_LC supports AVX512 RSA cryptography on AVX512 supported CPU and behind Cloudflare, the only matter is Cloudflare Edge to Centmin Mod Nginx origin connections.

 

No crashes so far but I am only testing on some new sites i.e. Matomo Analytics and Sendy.co newsletter which I am revisiting.

That's why AWS_LC isn't the default crypto library for Centmin Mod Nginx HTTPS usage yet so let folks and myself test it over time. And why Centmin Mod Nginx supports so many crypto libraries https://community.centminmod.com/threads/openssl-1-1-1-eol-alternatives.25488/ - thus allowing to me and Centmin Mod users to easily switch from one crypto library to another for Centmin Mod Nginx HTTPS usage

 

FYI, here's latest benchmark numbers on AlmaLinux 9 based AMD Ryzen 5950X 16C/32T dedicated server's libvirtd KVM VPS assigned with 16 CPU cores and 8GB of memory on Centmin Mod 140.00beta01 just for each crypto library that Centmin Mod Nginx supports https://community.centminmod.com/threads/openssl-1-1-1-eol-alternatives.25488/

• AlmaLinux 9 system OpenSSL 3.0.7
• OpenSSL 3.3.2 built using GCC 13.2.1
• OpenSSL 1.1.1w EOL built using GCC 13.2.1
• BoringSSL built using GCC 13.2.1
• AWS-LC built using GCC 13.2.1

The AWS-LC which is BoringSSL/OpenSSL 1.1.1 based fork and BoringSSL speed tests via native bssl client reports results with different benchmark names so AFAIK X25519 reported in OpenSSL is similar or same as Cruve25519 Base-point reported in BoringSSL and AWS-LC?

Seems only benefit is it you choose to use non-default ECDSA 256bit SSL certificates instead of default RSA 2048bit SSL certificates. If you have Cloudflare orange cloud enabled proxy enabled in front of Nginx, then these numbers don't mean much as Cloudflare edge server's HTTPS config is used to serve HTTPS traffic to your visitors. But still are applicable if you have Cloudflare FULL or FULL Strict SSL mode enabled as Cloudflare edge servers will talk to Centmin Mod Nginx origin servers via HTTPS and Centmin Mod Nginx HTTPS configured SSL certificates and Nginx crypto library used where AWS-LC, BoringSSL and then OpenSSL 1.1.1 will be most performant followed by OpenSSL 3.3.2 then OpenSSL 3.0.7

AWS-LC has very performant ED25519 signature algorithms but AFAIK browsers do not support ED25519 SSL certificates yet. Only support default RSA 2048bit and ECDSA 256bit SSL certificates.

ECDSA 256bit SSL certificates and digital signature signing is 29-34x faster than RSA 2048bit SSL certificates



Here's how these metrics correlate with Nginx HTTPS performance:

Key Metrics and Their Impact:

1. RSA 2048 Sign/Verify:
   • Impact on HTTPS Performance: RSA operations are used during the handshake for certificate verification and key exchange. Specifically:
     • Sign/s: RSA signing occurs during the server-side certificate signature when the server presents its certificate to the client. The faster this is, the quicker the handshake process.
     • Verify/s: RSA verification is used by the client to verify the server's certificate. A higher verify rate improves performance, especially in client-heavy environments.
   • Stage in HTTPS Request: Initial handshake (certificate validation and signing) uses RSA operations if RSA certificates are involved. Performance bottlenecks may occur in environments with a large number of handshakes, especially for sites with high traffic.
2. ECDSA (nistp256) Sign/Verify:
   • Impact on HTTPS Performance: ECDSA is used for digital signature operations during the SSL/TLS handshake. It's faster and more efficient than RSA for signing, making it common in modern HTTPS setups, especially for sites requiring higher scalability.
     • Sign/s: This is critical for the server's certificate signing in setups using ECDSA certificates.
     • Verify/s: Client-side certificate verification during the handshake.
   • Stage in HTTPS Request: Same as RSA, but more performant in environments using ECDSA certificates. Nginx servers with ECDSA certificates benefit from faster handshakes, reducing overhead and latency in establishing connections.
3. ECDH (nistp256) Ops/s:
   • Impact on HTTPS Performance: ECDH (Elliptic Curve Diffie-Hellman) is commonly used for key exchange during the TLS handshake when Perfect Forward Secrecy (PFS) is enabled. The performance of ECDH operations directly impacts how quickly the session keys are generated.
   • Stage in HTTPS Request: During the handshake, ECDH is used to agree upon a session key for the encrypted connection. A higher number of operations per second results in faster key exchange and thus lower latency during connection establishment.
4. X25519 Ops/s and Curve25519 Ops:
   • Impact on HTTPS Performance: X25519 and Curve25519 are high-performance elliptic curve algorithms commonly used for key exchange in modern TLS setups (e.g., TLS 1.3). Their speed is crucial for fast handshakes when ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is used for key exchange.
   • Stage in HTTPS Request: In TLS 1.3, key exchange uses these elliptic curves to negotiate secure session keys. Faster operations reduce the time spent in key negotiation, improving handshake latency.
   • Base-point vs Arbitrary-point Ops: Base-point operations are typically faster and more efficient, which is why they are preferred in setups where the server controls the parameters.
5. Ed25519 Sign/Verify:
   • Impact on HTTPS Performance: Ed25519 is used for digital signatures, similar to ECDSA, but is faster and more efficient. Its impact is primarily seen in servers using Ed25519 certificates.
   • Stage in HTTPS Request: Used in the same stage as ECDSA and RSA for certificate signing and verification during the handshake. With faster sign/verify rates, Ed25519 certificates help reduce handshake latency, especially in high-traffic scenarios.

Performance Implications in Nginx:

• Handshake Overhead: The most critical part of HTTPS performance affected by these metrics is the handshake phase. The faster the cryptographic operations (signature, verification, key exchange), the quicker the SSL/TLS handshake completes, resulting in lower connection setup time. This is especially relevant in high-traffic environments where numerous handshakes occur.
  
  
• RSA vs ECDSA vs Ed25519: Modern HTTPS servers often prefer ECDSA and Ed25519 certificates over RSA due to their superior performance in signing and verification. Servers that handle a high number of connections benefit from the significantly faster key exchange and certificate validation times associated with ECDSA or Ed25519.
  
  
• Key Exchange (ECDH, X25519): For key exchange, especially with Perfect Forward Secrecy (PFS) enabled (e.g., in TLS 1.2 and TLS 1.3), the speed of ECDH or X25519 operations affects how quickly session keys are negotiated. Faster key exchange operations lead to quicker handshakes and less latency before encrypted data transmission begins.
  
  
• TLS 1.3 and Session Resumption: In TLS 1.3, the handshake is streamlined, but cryptographic performance still matters. Faster key exchanges (e.g., using X25519) and signature verifications (e.g., ECDSA, Ed25519) contribute to overall lower connection latency. Additionally, session resumption mechanisms may reduce the number of full handshakes needed, but for new connections, cryptographic speed is critical.

The library performance for cryptographic operations (RSA, ECDSA, ECDH, etc.) significantly impacts the speed of establishing HTTPS connections in Nginx. Faster sign/verify operations improve the efficiency of the handshake process, especially in scenarios with high traffic and frequent new connections. Key exchange speed (ECDH, X25519) further influences how quickly secure sessions are established. Therefore, using libraries with optimized performance like AWS-LC, BoringSSL, or OpenSSL 3.x can reduce handshake latency, improving overall HTTPS throughput and user experience on Nginx servers.

raw benchmark results from my openssltest.sh script which properly formats each bssl and openssl binaries' speed test output as they output format differs

Code (Text):

---------------------------------------
./openssltest.sh opensslsys
Benchmarking OpenSSL 3.0.7 System...
rsa 2048 bits signs/s: 2194.7
rsa 2048 bits verify/s: 80739.2
256 bits ecdsa (nistp256) signs/s: 63866.6
256 bits ecdsa (nistp256) verify/s: 21088.2
 256 bits ecdh (nistp256)   0.0000s  27819.3
 253 bits ecdh (X25519)   0.0000s  41142.8
253 bits Ed25519 sign/s: 33063.4
253 bits Ed25519 verify/s: 12021.9


---------------------------------------
./openssltest.sh openssl33
Benchmarking OpenSSL 3.3.2 openssl33...
rsa 2048 bits signs/s: 2154.4
rsa 2048 bits verify/s: 75425.2
256 bits ecdsa (nistp256) signs/s: 66174.1
256 bits ecdsa (nistp256) verify/s: 21575.4
 256 bits ecdh (nistp256)   0.0000s  27535.6
 253 bits ecdh (X25519)   0.0000s  38390.5
253 bits Ed25519 sign/s: 41968.7
253 bits Ed25519 verify/s: 12713

---------------------------------------
./openssltest.sh openssl111
Benchmarking OpenSSL 1.1.1w openssl111...
rsa 2048 bits signs/s: 2158.5
rsa 2048 bits verify/s: 75584.1
256 bits ecdsa (nistp256) signs/s: 68769.2
256 bits ecdsa (nistp256) verify/s: 21854.4
 256 bits ecdh (nistp256)   0.0000s  27546.5
 253 bits ecdh (X25519)   0.0000s  39233.5
253 bits Ed25519 sign/s: 42439.7
253 bits Ed25519 verify/s: 12689.7

---------------------------------------
./openssltest.sh boringssl
Benchmarking BoringSSL...
Did 2288 RSA 2048 signing operations in 1046948us (2185.4 ops/sec)
Did 83000 RSA 2048 verify (same key) operations in 1011442us (82061.1 ops/sec)
Did 72000 RSA 2048 verify (fresh key) operations in 1010942us (71220.7 ops/sec)
Did 12000 RSA 2048 private key parse operations in 1018071us (11787.0 ops/sec)
Did 74000 ECDSA P-256 signing operations in 1008721us (73360.2 ops/sec)
Did 26000 ECDSA P-256 verify operations in 1017743us (25546.7 ops/sec)


Curve25519 Output:
Did 56000 Curve25519 base-point multiplication operations in 1017078us (55059.7 ops/sec)
Did 34000 Curve25519 arbitrary point multiplication operations in 1004168us (33858.9 ops/sec)
Ed25519 Output:
Did 54000 Ed25519 key generation operations in 1001561us (53915.8 ops/sec)
Did 53000 Ed25519 signing operations in 1001897us (52899.6 ops/sec)
Did 30000 Ed25519 verify operations in 1024632us (29278.8 ops/sec)
P-256 Output:
Did 24000 ECDH P-256 operations in 1008084us (23807.5 ops/sec)
Did 74000 ECDSA P-256 signing operations in 1009903us (73274.4 ops/sec)
Did 26000 ECDSA P-256 verify operations in 1017294us (25558.0 ops/sec)
Kyber Output:
Did 19000 Kyber generate + decap operations in 1013198us (18752.5 ops/sec)
Did 30000 Kyber parse + encap operations in 1005961us (29822.2 ops/sec)
ML-KEM Output:
Did 19000 ML-KEM-768 generate + decap operations in 1010531us (18802.0 ops/sec)
Did 34000 ML-KEM-768 parse + encap operations in 1027599us (33086.8 ops/sec)

---------------------------------------
./openssltest.sh awslc
Benchmarking AWS-LC...
Did 2365 RSA 2048 signing operations in 1090887us (2168.0 ops/sec)
Did 83000 RSA 2048 verify (same key) operations in 1010722us (82119.5 ops/sec)
Did 72000 RSA 2048 verify (fresh key) operations in 1008566us (71388.5 ops/sec)
Did 8770 RSA 2048 private key parse operations in 1012287us (8663.6 ops/sec)
Did 74000 ECDSA P-256 signing operations in 1002630us (73805.9 ops/sec)
Did 26000 ECDSA P-256 verify operations in 1023690us (25398.3 ops/sec)

Did 39000 EVP ECDH X25519 operations in 1007067us (38726.3 ops/sec)
Did 40000 ECDH X25519 operations in 1016304us (39358.3 ops/sec)
Curve25519 Output:
Did 174000 Curve25519 base-point multiplication operations in 1003708us (173357.2 ops/sec)
Did 51000 Curve25519 arbitrary point multiplication operations in 1004321us (50780.6 ops/sec)
Ed25519 Output:
Did 163000 Ed25519 key generation operations in 1005844us (162053.0 ops/sec)
Did 156000 Ed25519 signing operations in 1001387us (155783.9 ops/sec)
Did 34000 Ed25519 verify operations in 1001420us (33951.8 ops/sec)
P-256 Output:
Did 24000 ECDH P-256 operations in 1007920us (23811.4 ops/sec)
Did 75000 ECDSA P-256 signing operations in 1009698us (74279.6 ops/sec)
Did 26000 ECDSA P-256 verify operations in 1012813us (25671.1 ops/sec)
Did 24000 EVP ECDH P-256 operations in 1011962us (23716.3 ops/sec)
Kyber Output:
Did 38000 Kyber768_R3 keygen operations in 1024250us (37100.3 ops/sec)
Did 33000 Kyber768_R3 encaps operations in 1021726us (32298.3 ops/sec)
Did 31000 Kyber768_R3 decaps operations in 1032474us (30025.0 ops/sec)

 

Not yet AFAIK only HTTP/3 QUIC client side not server.