A Geeky Website Update

My website SSL certificate was up for renewal. That relatively simple task of renewing the certificate ended up into a sort of Apache web server renewal project. This blog post is a sort of update on the website change activities.

I have been using ECDSA-based certificates since 2016. I’ve been buying these certificates, instead of using the free ones from Let’s Encrypt. Let’s Encrypt appears to have started supporting ECDSA-based certificates in 2018, but they do not have ECDSA-based root or intermediates certificates.

There are a couple of advantages to ECDSA-based certificates over the RSA-based ones, and hence I prefer to use as much of the former as possible. I’ve been using Comodo’s PostiveSSL with positive, pardon the pun, experience. The last year, I bought their certificates through SSLs.com, and I decided to continue to use them this year.

The certificate activation process at SSLs.com is excellent. For most users, especially when you are relatively new to SSL certificates, the process of generating keys and producing a CSR can be rather daunting. SSLs.com simplifies the process for newbies, such as generating a key for you in-browser. If you don’t trust that, they will give you a simple, sort of, one-liner openssl command to generate a key and CSR.

I am even more impressed that the commands they provided will generate an EC key! It’s about the same as I had documented before. If you need to know the command, here it is:

$ openssl ecparam -genkey -name secp384r1 | openssl ec -out server.key; openssl req -new -key server.key -out server.csr -subj /CN=server.com; cat server.csr

Needless to say, the entire process was simple and quick. I haven’t seen anything as good.

The new SSL certificate works fine, of course. I installed it last night. I ran a couple of checks, including testing my website, as I commonly do, against SSL Labs’ SSL Server Test. I was surprised to see Sectigo in the certification path. How did my Comodo PositiveSSL certificate become Sectigo?

It turns out Sectigo is the rebranding of Comodo CA after Francisco Partners acquired the latter in October 2017. Despite that new branding, you’ll still see the Comodo CA name everywhere, even today in 2019.

This opportunity to re-look at my website setup reminded me that it still doesn’t support TLS 1.3. This wasn’t such an important thing in 2018. But since I’ve started to implement TLS 1.3 for websites at work, I thought it makes sense that my personal website ought to support that as well.

Back in August 2018 when I upgraded my web server to Ubuntu 18.04.1, I decided to switch back to the stock Ubuntu Apache packages. It doesn’t support TLS 1.3. That is also partly because the version of OpenSSL shipped with Ubuntu 18.04 does not support TLS 1.3. It was time, again, to think about switching to an alternate package repository: Ondrej Sury’s PPA for Apache 2.x. That was the same repository I had used prior to the Ubuntu 18.04.1 upgrade.

Setup is simple. Run as root:

$ add-apt-repository ppa:ondrej/apache2
$ apt update
$ apt install apache2
$ apt install openssl
$ apt install brotli

OpenSSL will be ugpraded to Ondrej’s package. I’ve also included updated brotli compression support.

Depending on your Apache’s configuration, you may have to edit the SSLProtocol line to enable TLS 1.3: SSLProtocol -all +TLSv1.2 +TLSv1.3

Some little changes are required to the SSL cipher suite:

SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384::ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384
SSLCipherSuite          TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384

My old brotli configuration doesn’t work anymore due to some changes in the configuration keywords. I’m now using the below:

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/x-javascript application/javascript application/json application/x-font-ttf application/vnd.ms-fontobject image/x-icon
    BrotliFilterNote Input brotli_input_info
    BrotliFilterNote Output brotli_output_info
    BrotliFilterNote Ratio brotli_ratio_info
    LogFormat '"%r" %{brotli_output_info}n/%{brotli_input_info}n (%{brotli_ratio_info}n%%)' brotli
    CustomLog "|${APACHE_ROOT}/bin/rotatelogs ${APACHE_LOG_DIR}/brotli_log.%Y%m%d 86400" brotli
    SetEnvIfNoCase Request_URI .(gif|jpe?g|png|swf|woff|woff2) no-brotli dont-vary
    Header append Vary User-Agent env=!dont-vary
</IfModule>

Remember to restart Apache after any configuration change.

My tests with SSL Labs SSL Server Test were good. A+, and a perfect 100 score for everything. But, there was a problem. TLS 1.3 requires the TLS_AES_128_GCM_SHA256 cipher suite to be supported. However, if I enable TLS_AES_128_GCM_SHA256, then my Cipher Strength score will drop to 90, for the simple reason that it is a 128-bit cipher.

There has been quite a bit of discussion on this topic, such as this issue on GitHub. It seems, one either has to choose standards compliance and get penalised for supporting a weaker cipher, or refuse to support the weaker cipher and thus violate RFC 8446.

This is a good case to ditch the standard because it asks to support 128-bit AES at a time when 256-bit is quite commonplace. Security is important. RFC 8446 is a year 2018 publication, why would they still want to accommodate, let alone mandate, a 128-bit cipher?

I like perfect scores. I also like to follow standards. In the end, I decided to downgrade security a little bit. I ultimately made two changes, adding two 128-bit ciphers to my cipher suite list:

SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384::ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256
SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256

TLS_AES_128_GCM_SHA256 is for the RFC 8446 compliance. I also added ECDHE-ECDSA-AES128-GCM-SHA256 to the TLS 1.2 list in order to satisfy compatibility with some legacy clients, namely: Android 5.0, Android 6.0, and Firefox 31.3.0 ESR / Win 7.

There is one remaining standard client that SSL Labs SSL Server Test tests for which is unsupported on my website: Chrome 49 / XP SP3. I figured, no one is supposed to be using Windows XP anymore, anyway, so this is fine.

I hate having to make choices between something bad, and another that is somewhat equally bad, though in a different way.
TLS_AES_128_GCM_SHA256 isn’t good, but the ordering of cipher suites in Apache, however, means that more capable clients should be selecting stronger cipher suites anyway.

As much as I agree that 128-bit ciphers are definitely too weak, given these circumstances, I think they are an acceptable trade off for both standards compliance and expanded client compatibility.