ECDSA Certificates with Apache 2.4 & Lets Encrypt

Update: Modified the configuration so instead of whitelisting TLS versions, it is blacklisting insecure TLS versions based on feedback. Thanks Johannes Pfrang.

A little while ago, I wrote a post about running dual RSA and ECDSA certificates on my websites. Since then, I’ve found that there is little to no impact of running my websites with only an ECDSA certificate. You can also get these certificates for free, since Let’s Encrypt is now signing ECDSA certificates with their RSA root.

Infrastructure Set-Up

The infrastructure supporting this all is as follows:

  1. Ubuntu 15.10
  2. Ondřej Surý’s Apache 2.4.x PPA
  3. OpenSSL 1.0.2 (via the PPA above)
  4. Let’s Encrypt Auto Script

Capturing TLS Usage Logs

One of the things that did help with deciding how to proceed with this setup was to configure a new Apache access log file to capture TLS request data.

LogFormat "%t,%h,%H,%v,%{SSL_PROTOCOL}x,%{SSL_CIPHER}x,\"%{User-agent}i\"" ssl
CustomLog /var/log/apache2/ssl.log ssl

This outputs a log file that shows the time of the request, the source IP address, the HTTP version, Apache Virtual Host, TLS Version, TLS Cipher and the Browser User Agent. Example:

[28/Feb/2016:13:42:20 +1100],,HTTP/2,,TLSv1.2,ECDHE-ECDSA-AES128-GCM-SHA256,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36"
[28/Feb/2016:13:45:31 +1100],,HTTP/1.1,,TLSv1.2,ECDHE-ECDSA-AES128-GCM-SHA256,"Mozilla/5.0 (compatible; Googlebot/2.1; +"
[28/Feb/2016:13:45:52 +1100],,HTTP/2,,TLSv1.2,ECDHE-ECDSA-AES128-GCM-SHA256,"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
[28/Feb/2016:13:46:06 +1100],,HTTP/2,,TLSv1.2,ECDHE-ECDSA-AES256-GCM-SHA384,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"

In the end, I discovered it was fairly easy to run some basic queries against this data. I ended up doing the following:

  1. Using the AWS Cloudwatch Logs Agent to send the whole log file in real-time to AWS Cloudwatch Logs.
  2. Using the AWS Management Console to export all logs to Amazon S3 and then download them locally.
  3. Using q – Text as Data to run SQL queries directly the GZIP’d log data.

Once I had all the AWS data from S3 in a folder, I could run a simple query such as:

q -d"," -T "SELECT c6, count(*) FROM ..\data-q\*.gz GROUP BY c6 ORDER BY count(*) DESC"

This gives me some nice, basic statistics (percentages added in post-processing):

Ciphersuite Requests %
ECDHE-RSA-AES128-GCM-SHA256 45557 93.5
ECDHE-RSA-AES256-GCM-SHA384 1914 3.9
ECDHE-RSA-AES128-SHA 625 1.3
ECDHE-RSA-AES128-SHA256 293 0.6
ECDHE-RSA-AES256-SHA  184 0.4
ECDHE-RSA-AES256-SHA384  149 0.3

Apache TLS Hardening

I had already decided that DHE support wasn’t needed on my website. This was largely due to the fact I was running multiple SSL virtual hosts on a single IP (so lot’s of the older clients which didn’t support SNI wouldn’t work anyway). The only SNI supporting client I would lose, according to the Qualys SSL Labs Server test, was OpenSSL 0.9.8. Given it’s not a typical user-facing client, I decided this wasn’t a major loss.

Therefore, the move to ECDSA certificates had no noticeable impact on my client compatibility. The ciphersuites (and order) I landed on are as follows:


Note: ChaCha20-Poly1305 is in there for a bit of future proofing once OpenSSL 1.1 is released.

In the end, all the following SSL hardening (which I’ve adapted from the CIS Apache Server Benchmark, Mozilla Server-Side TLS recommendations and various online sources), ends up looking like this:

# Disable insecure renegotiation.
SSLInsecureRenegotiation Off

# Disable Compression.
SSLCompression Off

# Set up OCSP stapling.
SSLUseStapling On
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:logs/ssl_stapling(32768)

# Disable Session Tickets.
SSLSessionTickets Off

# Turn on TLS.
SSLEngine on

# Disallow insecure protocols, allow current and future protocols. (TLS 1.0 is arguably still required.)
SSLProtocol -SSLv2 -SSLv3

# Ask the client to prefer the order of support ciphers advertised by the server.
SSLHonorCipherOrder On

# The actual ciphersuite and order to use.

# Bump up the strength of the ECDHE key exchange.
SSLOpenSSLConfCmd ECDHParameters secp384r1
SSLOpenSSLConfCmd Curves secp384r1

This pretty much sums up all of the TLS related hardening. The only thing I can think of that’s missing would be to support Certificate Transparency via providing Signed Certificate Timestamps (SCT)’s. It looks like there isn’t a way to do this on Apache 2.4. The current Apache module (mod_ssl_ct) seems to require you to compile a development/trunk version of Apache (and exists in the documentation as an unreleased Apache 2.5).

Manually Generating Signed ECDSA Certificates from Let’s Encrypt

I’m sure an option to generate ECDSA certificates is on its way with the automatic Let’s Encrypt tool, but here is how you can manually generate certificates for now:

# Create the private key.
openssl ecparam -genkey -name secp384r1 > "/letsencrypt/ecdsa/"

# Create OpenSSL configuration file.
cat /etc/ssl/openssl.cnf > "/letsencrypt/ecdsa/"
echo "[SAN]" >> "/letsencrypt/ecdsa/"

# Pick one based on whether its a root domain or not. E.G:
echo "" >> "/letsencrypt/ecdsa/"
echo "," >> "/letsencrypt/ecdsa/"	
# Create Certificate Signing Request.
openssl req -new -sha256 -key "/letsencrypt/ecdsa/" -nodes -out "/letsencrypt/ecdsa/" -outform pem -subj "/" -reqexts SAN -config "/letsencrypt/ecdsa/"

# Get signed certificate.
/letsencrypt/letsencrypt-auto certonly --webroot -w /var/www/ -d --email "" --csr "/letsencrypt/ecdsa/"

If this is the first time you’ve done this, all you need to do now is point to the latest certificate chain and private key in your relevant Apache configuration location.

SSLCertificateFile /letsencrypt/ecdsa/
SSLCertificateKeyFile /letsencrypt/ecdsa/

Qualys SSL Labs Testing

I was fairly satisified with the range of flexibility and client support this configuration allowed for!



Using Amazon Web Services to Capture CSP and HPKP Reports

I’ve been working to review and harden the security on my personal websites lately (maybe some other posts about cipher suite choices and server logging to AWS coming up).

One thing I’ve never utilised before are the reporting features available in both Content Security Policy (CSP) and HTTP Public Key Pinning (HPKP). This reporting lets you help tune your policies (in the case of CSP), and see violations for both HPKP and CSP. For both forms of reporting, you need to provide a URL in the CSP/HPKP header. The client’s browser, which detects whether there is a violation of either scheme, will simply send a HTTP POST request containing the report to that URL.

You generally have two choices here – develop your own mini-application to capture these reports, or use somebody else’s service. I wanted to keep the number of live web applications I had to maintain down to a bare minimum (so option 1 was not looking good), and I didn’t want to a third-party receiving my reports in perpetuity (so option 2 was struck-out).

Having an Amazon Web Services account, I decided to see whether it was possible to utilise some of the tooling available there to help me out. The idea was to provision something in my personal AWS instance that could maintain an endpoint to collect the logs and then export/view/search/alert on the logs as needed. Obviously, the idea was to keep the cost down as much as possible (this is only a personal endeavour, after all!)

To summarise what I ended up doing, my first solution to this problem is as follows:

AWS API Gateway allows you to create an “API” to receive requests. It’s reasonably cheap (you only pay a cup of coffee per million API queries plus cents per GB for data traffic). There’s also a free tier for the first 12 months – which means I’ll be able to estimate roughly how much this will cost me longer term.

Some good things I’ve discovered about the AWS API Gateway service:

  • The AWS API Gateway service can be configured using the AWS Management Console GUI to log all requests to CloudWatch Logs (including full header and responses).
  • You only need to set up a single POST API on the root URL for receiving the report requests – this is only a couple of quick clicks in the AWS Management Console GUI.
  • You can set that single POST API to either do nothing (mock execution) or act as a HTTP proxy for another service (theoretically, I can think this means you could daisy-chain to a secondary service as well, like Report-URI).

The raw logs appear from the API Gateway service (Which includes the violation reports), then get thrown into a Log Group in AWS CloudWatch Logs. You can then use in the inbuilt search/parse tool in Cloudwatch Logs in the Management Console, export the entire log file to Amazon S3 to dice up offline, or pass onto a couple of other AWS services (which I haven’t looked into just yet).

Setting up the API:

API Gateway 1

Configuring the logging:
API Gateway 2

Viewing the reports:
Cloudwatch Logs 1

What I’d like to do in the future:

  1. See if I can use a custom domain with Amazon API Gateway (Definitely possible, but I’d want to see if the new AWS Certificate Manager would provide a free SSL certificate for that endpoint.)
  2. See if I can stream this data into an AWS service for live-analysis when I need to search it (more than the string based search the AWS Management Console provides on Cloudwatch Log data.
  3. See whether I can get alerting in place based on particular keywords of interest and/or volumes of violations seen per day, or on a certain page.