Getting ssllabs.com class "A+" by matching at 100% Key Exchange and Cipher Strength criteria

In most cases, getting "A+" rate by the TLS ssllabs.com server checker, does not necessary mean the examined server matches fully (at 100%) all criteria. For instance, "A+" might be given if your server matches partially (at 90% level) the requirements for key exchange protocols and cipher strength:

In my case, I got "A+" status for my Apache/mod_ssl 2.4.6 server (on CentOS 7) by using limited and very conservative list of ciphers (it is a long story about why I do avoid using "CBC"-based ciphers):

ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256

So far (8 months since I implemented the new TLS configuration), I haven't received any complaints from my clients, related to TLS issues. Seems like they keep their mobile and desktop browsers very much up to date.

Recently, for another project (PKI-based one) I decided to go further and try to get "A+" by matching all criteria at 100% (using the same Apache/mod_ssl 2.4.6 setup on CenOS 7):

What I have done? I just removed from the list above the 128-bit ciphers:

ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384

How does this change affect the clients? I got only 1 complaint from a person who is used to use Firefox on CentOS 6 (rather old distribution for a desktop, I dare say). On the other side, even mobile clients with Android 6.0, using Samsung Internet Browser, do not have any problem with the new TLS cipher set.

What was surprising is that replacing RSA server certificate with ECDSA-based one, does not create any significant TLS issues. Again, the first set of ciphers I tested (where "A+" is matched only partially), was based on both 256 and 128-bit ciphers:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256

and the second one included only 256-bit based ciphers:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384

It seems like most of the browser and OS vendors take a lot of measures to secure the TLS protocol implementation in their software products.

Read More

Using high-grade ECC temporary keys with Apache and mod_ssl on CentOS 7

To support ECHDE-based SSL ciphers, your Apache server (through mod_ssl) needs a temporary ECC key to be generated and loaded during each start or restart of the httpd daemon. While on RHEL8 and CentOS 8 you can automatically generate and load such keys, every time when Apache daemon is invoked, simply by adding the declaration:

SSLOpenSSLConfCmd Curves P-384

to the section in /etc/httpd/conf.d/ssl.conf, there is no such support in mod_ssl 2.4.6 - the version shipped with CentOS 7. That does not mean mod_ssl 2.4.6 does not support ECDHE and the use of temporary ECC keys. It supports it, but instead of allowing the temporary ECC key size to be configured as a parameter in /etc/httpd/conf.d/ssl.conf, it sticks only to 256-bit secp256k1 key. Key of that size might not be suitable (cannot be recognized secure enough) for use in long-time running Apache instances. One workaround here is to manually generate ECC key, using secp384r1 (that is high-grade key), and add it to the end of the certificate file (that is the file pointed by the SSLCertificateFile declaration in /etc/httpd/conf.d/ssl.conf).

To generate the key, use openssl:

$ openssl ecparam -genkey -name secp384r1

The output will look like:

-----BEGIN EC PARAMETERS-----
BgUrgQQAIg==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCL5996z0+JsNAR2boRU0zULurtLbKbILiysJx3BbWEWFrlkuXL11BS
MI9bqrYNXjOgBwYFK4EEACKhZANiAAQISZYiUhc3GUXCaxOfsNun9KBiMyp9yAR3
qGH2NR1Va51Q4WfS4X0XPCaa3w3gA5g69MQV8aak3BVnbE27Q+yAZ5zi+dSNt5VU
Jg1tGgZmzX+SfJ6WWtMSv0Aa3r62UEE=
-----END EC PRIVATE KEY-----

Add it to the end of the certificate file, right after the line:

-----END CERTIFICATE-----

Save the changes to the file and reload or restart Apache's daemon httpd:

$ sudo systemctl reload httpd

To check if the server is successfully loaded and using the newly generated 384-bit long temporary key, use openssl:

$ openssl s_client -connect your_server_name:443

In case of success, you should see in the result the following line:

Server Temp Key: ECDH, P-384, 384 bits

NOTES: The configuration of mod_ssl should include at least one ECDHE cipher. Do not try to go to 521-bit key, for it is not supported by some browsers (yet).

Read More