Topic: Supporting ML-KEM with TLS 1.3 - a new default in Chrome

[labradort]

Hello,

Our Apache site stopped working with Chrome users when they received browser updates this week.

The error was SSLProtocol Error on the web page, and nothing was logged in Apache.

Firefox and Edge loaded the site fine - the problem was specific to Chrome.

Everything was A+ in the Qualsys SSL Labs report - no hints of a bad configuration.

When chrome was run in debug mode, the screen behind showed:

[2464:1112:1113/152621.301:ERROR:registration_request.cc(291)] Registration response error message: DEPRECATED_ENDPOINT
[7780:11388:1113/152638.287:ERROR:ssl_client_socket_impl.cc(878)] handshake failed; returned -1, SSL error code 1, net_error -107

A colleague discovered that when ML-KEM with TLS 1.3 option was disabled in Chrome, then the site loaded properly.

I went through all the suggestions from ChatGPT for getting Apache configured to support this new feature in TLS 1.3.

In particular, it suggested:

SSLCipherSuite TLSv1.3:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384

I tried this in the Apache we're running - the 2.4.62 release from September 2024. It wouldn't start like that. Apparently this isn't supported on the Apache for Windows.

Our workaround is to run the site with only TLS 1.2 for the time being so that Chrome users can access it.

[labradort]

I've noticed another thread here about TLS 1.3 and it pointed to a page here documenting the best setup.

Based on that, I used:

SSLUseStapling On
SSLSessionCache shmcb:C:/Windows/Temp/ssl_gcache_data(512000)
SSLStaplingCache shmcb:C:/Windows/Temp/ssl_stapling_data(512000)
SSLOptions +StrictRequire +StdEnvVars -ExportCertData
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCompression Off
SSLHonorCipherOrder On
SSLCipherSuite SSL ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384
SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384

SSLOpenSSLConfCmd ECDHParameters secp521r1
SSLOpenSSLConfCmd Curves secp521r1:secp384r1


This seems to have satisfied Chrome since the Nov 12th patch.

Really, the idea that one can put in a minimum SSL configuration and run the site that way is becoming outdated as the web browsers insist on the latest tech.

I recommend that the packaging for Apache24 take this into account and provide the better recommendation within the
file httpd-ssl.conf as it is shipped.

[James Blond]

Hi labradort,
you may report that to the httpd Apache developer mailing list. The Apache Lounge policy is not to change the code and ship it "as is".

In our tutorial[1] we point out a good configuration.


[1] https://www.apachelounge.com/viewtopic.php?t=2394

[labradort]

I googled this issue, as it started to appear on other servers than Windows. It's been very illogical to address the problem, and that's because the problem isn't in Apache nor the configuration. It struck me that no one else in these forums is talking about it, and it should be happening everywhere. That's because it's actually a problem in Fortinet firewall.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-ERR-SSL-PROTOCOL-ERROR-when-using-Flow-based-Deep/ta-p/357555

My network analyst was able to configure some by-pass that dodges the problem and I'm able to run TLS 1.3 without any special CipherSuites or curves, although it's always fun to get the SSL Labs score high.

Thanks for reading, and hopefully this post might help someone else fighting the problem around now.