In my time in IT I’ve installed certificates quite a few times on various web servers and into various applications but it’s really only in the past two years that I’ve started looking into HTTPS and the myriad of options that come with certificates which are often hidden deep into config files but yet can make the difference between a site that can be rendered vulnerable via a HTTPS downgrade attack or one that is actually secure because today, installing a cert is simply the tip of the iceberg so I thought it might be handy to go through the options that need to be set in a web servers config file in order to get A+ on both the Qualys and securityheaders.io web servers.
This blog is going to be all about the secure certificate side of things, by setting these headers you reduce the chances of certain types of probes and attacks from being successful. The server itself and whatever applications you are running on it still need to be upgraded and configured to reduce the chances of someone gaining unauthorised access to your systems.
The above A+ rating simply says that the site is not only using HTTPS but is also presenting various headers that make it as secure as it can be. Each of the six headers has the specific reason to be used and I’ll go through why.
In order to get the above A+ rating, there are additional headers that need to be set in the config file for the site, below you can see the ones I set on all the servers I build that host NGINX.
HSTS (HTTP Strict Transport Security)
HSTS – This sets a cookie on the client side which states that the site will be served over HTTPS for a period of time. That time is set in the cookie by the header. Best practice is to set this for two years, each time the client connects to the site, the cookie gets updated. The setting that I use for all my sites is:
max-age=63072000; includeSubDomains; preload
This sets the cookie to ensure that everything from the site is in HTTPS, including subdomains. Once the cookie is set, the site will not be loadable over HTTP unless the cookie is deleted or something like incognito mode is used.
Content Security Policy
This header allows content sources to be specified and tells the server which sources are trusted and can be loaded. This directive has many options so it’s worth a read through the potential settings to ensure that any third-party content you choose to load into the site is actually allowed to be loaded. On my sites, I start out with “upgrade-insecure-requests” which does exactly that.
X-Frame-Options
This option prevents your site content from being injected into another site, these so-called “clickjacking” attacks occur because the web server will happily serve up content to other sites. This option prevents that. If you want to allow certain content to be embedded, you can use an “ALLOW FROM [site]” directive
X-XSS-Protection
This option can be covered by the Content Security policy but it’s still worth including for older browsers and it still helps your score on the evaluation sites. In short, this option helps to prevent cross-site scripting attacks. Setting this to “1; mode=block;” not only enables filtering but will block cross-site scripts that appear to be an attack.
X-Content-Type-Options
There is only one setting for this, “nosniff;”. Setting this option stops certain types of MIME exploits.
Referrer-Policy
The referrer policy sets what information is sent when a request is made. Like the Content Security Policies, there are quite a few options that can be set here. The one I always use is “strict-origin” as that ensures that the URL that is used is the URL that sent, i.e. it won’t change an HTTPS link to HTTP.
That’s everything that you need to set to get an A+ on reportheaders.io – to get an A+ on Qualys you need to disable everything bar TLS 1.1 and 1.2 plus you need to use a strong cipher set, I won’t list a recommend cipher set as there is every chance that it’ll change, you’re better off using google to find the latest HTTPS cipher set.
That covers getting an A+ on both Qualys and securityheaders.io, It’s worth running checks against both of these sites whenever a change is made to a website just to confirm that everything on the HTTPS site is secure as possible. It’s still recommended to have quite an aggressive patching schedule due to the speed of execution from a vulnerability being found to exploit code being made available. Don’t forget to check and update plugins as well!
The Mozilla developer site has a list of HTTP(s) headers and what each does. The ones I’ve listed above are listed there and its worth having a read through of the various options you can set. https://developer.mozilla.org/en-US/docs/Web/HTTP
It is worth mentioning a few other things that are either relatively new or just about to be released.
TLS 1.3
TLS 1.3 is the latest and greatest version of the HTTPS protocol, it introduces some nice features like downgrade protection and removes older, insecure elements from the cypher sets.
HTTP 2.0
HTTP 2.0 is worth talking about as this implementation of HTTP requires that the traffic is over HTTPS and as such it is optimised to make HTTPS many times faster than that HTTP 1.1, this results in HTTPS content being delivered faster over HTTPS using HTTP 2.0 than HTTP is over HTTP 1.1
DNS CAA records
It’s worth mentioning CAA records. Not all DNS providers support this option yet but they all should quite soon. A DNS CAA record is basically a text record that lists the approved cert authorities for a domain. For example, if www.example.com uses a let’s encrypt cert then the CAA record would look like this:
Example.com CAA 0 issue “letsencrypt.org”
If a cert was then attempted to be generated at digicert they’d reject the request because the CAA record says that they are not authorised to create certs for that domain
HTTPS Offload
A few years ago, it made sense to offload HTTPS requests to a device like a load balancer or dedicated SSL appliance because the encryption/decryption process took a fair amount of CPU. Today, with CPU enhancements and instructions specifically built to handle such requests, the requirement of HTTPS offload is generally no longer there and HTTPS connections should always terminate on the servers themselves. HTTPS offloading devices are basically Man in the Middle attacks where a device intercepts that traffic and, if that traffic isn’t re-encrypted it’ll be travelling over the internal network in plain text.
The security.txt file initiative
This is a relatively new idea but one that I think is worth implementing. Basically, all it requires is a file called “security.txt” to be placed into a website path called “/.well-known”. For www.example.com you’d find the security.txt file at www.example.com/well-known/security.txt.
The file should be a very simple list of contacts that can be used should a security issue be discovered on a website. More details of the project can be seen here: https://securitytxt.org/
The last thing I’ll mention in this blog is the often asked question “Who needs certs?”
The simple answer to this is “every website out there”. It doesn’t matter if the content you are hosting is fully available to the public and/or that the site doesn’t use any login forms or anything that needs encryption because every single website should use an HTTPS cert. HTTPS helps with Google site ranking, it stops eavesdropping and it guarantees that the data that was received is the data that was sent. HTTP doesn’t go away but with changes coming to browsers, it’ll soon be clear which sites are secure and which are not. If you’re not using HTTPS today you really need to consider moving to it.
