, there's a simple solution to this.){kind=link}
The Qualys SSL Labs Server Test is one of the most popular free online tools for inspecting the quality and security rating of your SSL (or as we always remind ourselves, technically ‘TLS’) certificates.
You might assume that if you’re hosting with Amazon Web Services (AWS) using their own Certificate Authority (CA), they’ll have this covered – so you might be surprised to find that your site still comes up short on the SSL Lab Test, with a rating of only a B or lower. Why?
Background
The first thing to note is that what is considered secure now is inevitably considered less secure in the future. A test conducted today is a point-in-time appraisal based on our current understanding of security vulnerabilities and vectors of attack, and these, like the technology, are ever evolving.
The second aspect is both AWS’ strength and weakness – backwards compatibility and legacy support. The most commonly-referenced example of this is SimpleDB – you won’t find it mentioned anywhere in the public-facing AWS product site, it’s CLI-only with no console interface. It’s as deprecated as a Dodo and yet lurches on in a tiny corner because presumably someone, somewhere, is still using it (amusingly SimpleDB’s most recent community forum post was in December 2019, one of only three that year. The last announcement from AWS was in 2012!).
The same holds true for SSL and TLS protocols (that’s the thing that makes your connections theoretically secure) and ciphersuites. Ancient PCs, Tablets, and Mobile phones are the main culprits here, where the hardware is at least 5-10 years old and won’t ever receive a software update again yet is still being used by many all over the world.
TLS 1.0 was published in 1999 and deprecated in 2020, overlapping significantly with SSL 3.0, published in 1996 and deprecated in 2015. At the time of writing, anything that’s TLS 1.1 and lower is considered ‘not good’, so it’s TLS 1.2 at the minimum and preferably TLS 1.3 which was published in 2018.
So what’s the problem? Why not just configure your site to accept TLS 1.3 only? It’s that ‘old device’ problem again. Let’s say I’ve still got a Nexus 7 from 2012 that runs Android 4.3 – that won’t support anything later than TLS 1.0 so if I enforce a newer protocol it just won’t be able to talk to my website on SSL – and if I’m a customer that means I’m not buying anything from you. These older devices and browsers also don’t support Service Name Indication (SNI) which is a modern extension to TLS to get around the historical restriction of an SSL certificate needing to be on a dedicated IP address. Even before the IPv4 address space became perennially exhausted, running your website on a dedicated IP wasn’t easy or particularly cheap, which is why having an SSL-secured website was a lot rarer in the past.
It’s a tricky choice to knowingly exclude some percentage of your possible customer base because, ideologically, you want your site to be more secure. What’s the proper balance of security vs. compatibility?
The reality is, not many people are really thinking about it that much, and if you’re reading this article, congratulations! You’re way more tuned in than most.
How to get the ‘A’ SSLLabs Rating
Ok so enough with the history lesson, how do I fix it?
Cloudfront supports pretty much everything and has nice documentation on the supported protocols and ciphers between viewers and CloudFront.
To edit these, go to the Cloudfront console in AWS and click on your distribution. Under the ‘General’ tab, click the ‘Edit’ button and scroll until you see these options.
AWS will recommend the latest TLS 1.2 security policy, but do mention that you perhaps shouldn’t if your users are using older browsers or devices. I’ve also included the section here that gives you the option to not use Server Name Indication – so if you really want to support legacy devices by allocating dedicated IP addresses to each CloudFront edge location, that’ll cost you a cool $600! You’d better have a good reason!
That’s it for Cloudfront.
Classic Elastic Load Balancers (ELB) and Application Load Balancers (ALB)
You’ll be unsurprised to learn that load balancers work in a very similar way. There are options to modify the SSL negotiation configuration for Classic Load Balancers
It’s slightly different for Application Load Balancers, as you’ll need to be creating an HTTPS listener during which you can specify a TLS security policy where you have multiple options depending on if you want to support Forward Secrecy (FS)
Specify a CAA record in your domain’s DNS records
You might be thinking – a CAA record? Never heard of it. Certification Authority Authorization (CAA) is essentially a DNS record that says ‘Only these certificate authorities are allowed to create SSL certificates for my domain name’.
This record is to try to tackle a general weakness in the way Certificate Authorities operate – there are a lot of them, and they can generate SSL certificates for any domain name on request. Depending on their verification methods and susceptibility to social engineering, you can predict the possibility that a hacker might try to get hold of a certificate for your domain and use it for nefarious ends.
CAA isn’t great, because it’s mostly just advisory. The Certificate Authority still needs to check for, and honour, the value of this record when considering whether or not to issue a certificate. But it’s better than nothing, and it’s a thing that the SSL Labs tool looks for as a qualifier of whether or not you’ve given it any thought. Extra points for those that have!
Amazon’s CA has four valid values that they’ll accept for the AWS Amazon Certificate Manager (ACM) service:
amazon.com
amazontrust.com
awstrust.com
amazonaws.com
It’s also worth noting that the CAA record can also discriminate between wildcarded and not-wildcarded certifications. Clearly, it’s quite a lot more powerful to be able to get hold of a certificate for, say, *.amazon.com, than it is for highlyspecificsubdomain.amazon.com – and it’s encouraging that the standard has thought about this.
Full documentation on CAA for AWS is available – now you know it exists!
That covers it – implement the above and you should see your AWS-hosted site report a nice clean A grade from SSLLabs.
For further reading, have a good read of SSLLabs Best Pratices for SSL and TLS deployments.