Openssl: no cipher match on TLSv1.3

[johni]

I installed both Apache (httpd-2.4.53-11.el9_2.5.x86_64) and openssl(openssl-3.0.7-6.el9_2.x86_64) from the Rocky repository. Apache runs properly when configured ONLY for http but when I try to implement https it fails with httpd error:

[Wed Nov 29 13:49:48.454096 2023] [core:notice] [pid 72883:tid 72883] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Wed Nov 29 13:49:48.454712 2023] [suexec:notice] [pid 72883:tid 72883] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Wed Nov 29 13:49:48.458389 2023] [ssl:emerg] [pid 72883:tid 72883] AH01898: Unable to configure permitted SSL ciphers
[Wed Nov 29 13:49:48.458399 2023] [ssl:emerg] [pid 72883:tid 72883] SSL Library Error: error:0A0000B9:SSL routines::no cipher match
[Wed Nov 29 13:49:48.458402 2023] [ssl:emerg] [pid 72883:tid 72883] AH02312: Fatal error initialising mod_ssl, exiting

The Apache config file parameter SSLCipherSuite is TLSv1.3 and this particular location has a self-signed certificate. All other https instances have commercial .pem certificates, although this does not seem to be the problem I figured I should mention it. This is our test server and does not require a certificate since it is entirely internal but installing openssl and mod_ssl suddenly required that it be https.
The full config is:

# This one picks up all IP based hacker garbage too
<VirtualHost *:80>
   ServerName iliffe.ca
   DocumentRoot /usr/httpd/iliffe
   Options FollowSymLinks
   H2Direct on
   ProxyPassMatch "^/.*\.php(/.*)?$" fcgi://127.0.0.1:9003/usr/httpd/iliffe
   Header always set Strict-Transport-Security "max-age-63072000;includeSubDomains"
</VirtualHost>

# Self signed secure iliffe.ca used to test https only
<VirtualHost *.443>
  Servername iliffe.ca
  DocumentRoot /usr/httpd/iliffe
  Options FollowSymLinks
  ProxyPassMatch "^/.*\.php(/.*)?$" fcgi://127.0.0.1:9003/usr/httpd/iliffe
  H2Direct on
  SSLCertificateKeyFile /etc/httpd/conf/sslcert/iliffe.ca.key
  SSLCertificateFile /etc/httpd/conf/sslcert/iliffe.ca.crt
  SSLCipherSuite TLSv1.3
  SSLHonorCipherOrder on
  Header always set Strict-Transport-Security "max-age-63072000;includeSubDomains"
</VirtualHost>
The full openssl error log entry is:

> Wed Nov 29 14:22:20.732752 2023] [ssl:warn] [pid 73060:tid 73060] AH01909: www.iliffe.ca:443:0 server certificate does NOT include an ID which matches the server name

Does this suggest anything to anyone?  Thanks in advance.
John

[iwalker]

@johni

  SSLCipherSuite TLSv1.3

I would remove this line from the config and then restart Apache to see if it works. This will confirm most likely that this is the cause of the problem with an invalid value. You can also use:

apachectl configtest

to find errors in config files that will most likely reference this line being a problem.

[johni]

configtest gives the following unrelated error:
[Wed Nov 29 14:36:32.633732 2023] [core:error] [pid 73123:tid 73123] (EAI 2)Name or service not known: AH00547: Could not resolve host name *.443 – ignoring!
Syntax OK
Attempting to start httpd gives the same error group and the “no matching ciphers” error.

[johni]

iwalker: Thanks for the suggestion: seems to depend on how you read the Apache docs! Replacing the SSLCipherSuite line with:
SSLCipherSuite HIGH:!aNULL:!MD5
Will allow httpd to start, even though configest is still showing error on *.443 but at least it is running now. Using only the parameter TLSv1.3 was recommended as the best security so I’ll have to ensure that no deprecated ciphers get included in “HIGH”

[iwalker]

The 443 error can be fixed by replacing in your config file:

*.443

with a colon:

*:443

on your VirtualHost line. For TLS, I would rather configure this way:

SSLProtocol -all +TLSv1.2

if you want only TLSv1.3 and higher, change the 1.2 above. Using TLSv1.2 and higher is still valid and OK though. TLSv1.1 and lower are deprecated and insecure.

For verification afterwards:

openssl s_client -connect <ip-addr-or-fqdn>:443 -tls1_2 

attempting -tls1_1 should fail.

[mdcTUX]

Hi, better don’t use TLS1.2 any more, because the DHeat attack. When ever possible only use TLS1.3.

[iwalker]

Slight correction, disable Diffie Hellman, TLSv1.2 isn’t the problem here.

Does TLS 1.3 mitigate this?

Yes and no. The standard of TLS 1.3 contains the Diffie-Hellman key exchange. Moreover, it defines a mechanism (supported groups) that makes it possible for the client to choose the key size, unlike the early versions of TLS (<1.2), where the server determines the key size. TLS 1.3 (also TLS 1.2 by extension) allows negotiating the key size during the cryptographic handshake. A malicious client can force the largest key size enabled in the server configuration, which can significantly increase the effectiveness of the attack. It should be noted that OpenSSL implements key size negotiation from its version 3.0 only in the case of TLS 1.3. In contrast, other libraries (e.g., GnuTLS) may implement key size negotiation also in TLS 1.2 (RFC 7919).

Source: https://dheatattack.com/

[mdcTUX]

But DH is needed for PFS, because the security of the NIST curves are unclear.
See: SafeCurves: Introduction
And the alternatives are only supported under TLS1.3.
So under TLS1.2 you can only select your nightmare.

[johni]

Embarrassingly, I missed the ‘.’ instead of ‘:’ in the config and I spent quite a lot of time checking the typing for errors! Thank you I Walker for spotting it. Did a lot of playing around and seems to work perfectly now.