SSL/TLS server configuration for maximum security
I've been playing around a lot with SSL/TLS server settings. I'll explain what settings I used for this https connection and how they improve your security.
This site passes the Qualys SSL Server Test with an A. (It does not get an A+ due to a bug in the Qualys test, it appears several sub-tests are disabled in a TLS 1.3 only configuration.) When I started this page, most browsers were unable to access it, but nowadays luckily most browsers support TLS 1.3. This page is accessible with https and many fancy TLS settings through https://fancyssl.hboeck.de and with less strict TLS settings through https://fancynossl.hboeck.de.
TLS 1.3 only
What? Only connections through 1.3 are allowed.
Why? TLS 1.3 deprecates a lot of problematic algorithms and features, and therefore prevents many famous attacks on TLS by design.
- TLS 1.3 does not use insecure hash functions like MD5 and SHA-1. SHA-1 was known to be cryptographically weak since 2005, and eventually broken in 2017. How insecure hash functions can impact TLS has been shown in the SLOTH attack.
- TLS 1.3 does not support CBC mode ciphers. Earlier TLS versions used the CBC encryption mode in a problematic "MAC-then-Encrypt" construction, which led to padding oracles (Vaudenay, 2002, Lucky Thirteen). TLS 1.3 only supports AEAD ciphers, which do not have this problem.
- TLS 1.0 and earlier are vulnerable to the BEAST attack, another issue with CBC mode ciphers.
- TLS 1.3 does not support RC4, which creates a biased key stream.
- TLS 1.3 deprecates RSA encryption modes (it still supports RSA signatures). RSA encryption modes are vulnerable to Bleichenbacher attacks (ROBOT, Marvin).
- TLS 1.3 always uses modes with forward secrecy.
- TLS 1.3 does not support 3-DES, which is vulnerable due to its small block size (Sweet32 attack).
- TLS 1.3 does not support compression. TLS compression led to the CRIME attack. Data can still be compressed on the HTTP layer with HTTP compression, which may also lead to attacks (BREACH), this has to be mitigated on the application level.
Browser support: Usually available these days.
Server support: Can be enabled in current apache with the SSLProtocol directive:
SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 +TLSv1.3
Server Name Indication (SNI)
Not exactly a security feature, but an option to have more than one certificate on one IP. Usually, today's webservers run dozents of virtual hosts on one IP. This made SSL implementation difficult in the past, as traditional SSL requires one IP per certificate and the domain name is fixed in the certificate. The Server Name Indication, available since TLS 1.0, allows to circumvent this restriction (although there were some problems with browsers due to backwards compatibility, see this Mozilla bug).
Server support: Using Apache 2.2.12 or above you can specify a certificate in every vhost with SSLCertificateFile, SSLCertificateKeyFile and, if neccessary, SSLCertificateChainFile.
Certificate from Let's Encrypt with 2048 bit and SHA256 signature
Certificate is signed by Let's Encrypt.
It has a 2048 bit RSA key and a signature with SHA256. (Originally I had a 4096 bit certificate, but it is too much hassle to support this with our certificate automation and 2048 is more than enough.)
RSA keys with 1024 bit are considered insecure against very powerful attackers, keys with 768 bit have been broken in practice and keys with 512 bit can be broken on home hardware. Google, PayPal, Amazon, Yahoo, eBay, Apple, Twitter and a bunch of others still used 512 bit keys in 2012 (for DKIM, not for https). In 2010, the EFF found 512 bit RSA certificates on https with so-called "Extended Validation" (EV), which is forbidden by the EV rules.
Keys with 2048 bit or above are considered secure.
Also, we've correctly installed the certificate chain. This should be obvious, but it is not. Very often, wrongly installed chains can remain undetected for a long time, because browsers are lax when the chain is in wrong order and if it's completely missing, the browser will take intermediate certificates it has cached from other sites.
OCSP stapling
A hughe problems with certificates are revocations. The CRL or OCSP protocols should allow browsers to check certificate authorities if certificates are still valid. However, browsers either disable OCSP or implement it in an insecure way treating "no reply" as "everything's fine". Also, OCSP has privacy issues, because the certificate authority will get all the IPs from users checking their certs. So it's basically broken and useless, but that's the way things are.
With OCSP stapling, the server caches the certificate authorities OCSP reply and bundles it into the SSL connection. This improves performance and privacy when using OCSP.
HTTP Strict Transport Security (HSTS)
We send the HTTP Strict Transport Security header, which tells the browser to access this page only with SSL for a certain timeframe and thus makes SSL stripping attacks less likely. The timeout is set to two years.
The domain is also in the HSTS preload list.
Secure Renegotiation
In 2009, a flaw was found in the SSL/TLS renegotiation feature. A TLS-extension specified in RFC 5746 allows renegotiation without the flaw.
TLS 1.3 has replaced renegotiation with a different rekeying mechanism.
No insecure Diffie Helmann parameters
Apache used fixed parameters for Diffie-Hellman key exchanges with 1024 bit for a while. That's considered insecure, however there's no way in Apache before version 2.4.7 to change this except disabling DH exchanges at all. Apache 2.4.7 and above set the DH size to the certificate key size.
For TLS 1.3, only standardized DH groups are allowed, so this issue is obsolete.
CAA (Certificate Authority Authorization)
The domain uses Certificate Authority Authorization (CAA, RFC 6844) to bind certificate issuance to one certificate authority.
It also uses the Account URI and Method Binding Excensions (RFC 8657) to further lock down certificate issuance.
HPKP (HTTP Public Key Pinning)
HPKP allows a web page to "pin" a set of keys that a client can store and prevent connections with any other key. While in theory this provides strong protection against powerful attackers, it can break pages without a recovery option if a server administrator looses access to his keys.
HPKP has been removed from most browsers. We still send an HPKP header and pin to Let's Encrypt's root and intermediate certificates, including fallbacks.
Certificate Transparency
All certificates used are logged in Certificate Transparency logs. This is the default these days and required by browsers.
Expect-CT
The Expect-CT header allows to signal to a client that it should only accept certificates with Certificate Transparency support.
This is no longer needed, as Certificate Transparency is required by default by modern browsers. We still send an Expect-CT header.
Content Security Policy
Content Security Policy is not directly related to TLS/HTTPS, but it contains one sub-feature that is relevant: The upgrade-insecure-requests flag prevents mixed content and auto-upgrades images and other resources to https if one tries to load them over http.
Subresource Integrity
Subresource Integrity (SRI) allows setting a hash to guarantee the integrity of CSS and Javascript resources. This is primarily useful for third-party resources. This page uses no third-party resources, but we still use SRI for the CSS file.
Cookie
We set a cookie with the secure flag and the __Secure- prefix.
The cookie has no further purpose and is only servers as an example. It expires after a few minutes and contains no personal data.
HTTPS resource record
We use an HTTPS resource record, an alternative HTTPS upgrade mechanism specified in RFC 9460.
Future?
What could be implemented to further improve security:
- DNSSEC - I am not a fan.
- RSA-PSS is now the RSA signature mode used in TLS 1.3 for the connection, hoever certificates these days are still signed with the old and problematic PKCS #1 v1.5 padding. Specifications for PSS signatures for certificates exist, but they are rarely used in practice. If you want to know more about PSS, read my diploma thesis.
- Elliptic Curve (ECDSA) certificates - should be mostly supported. ECDSA has some problems with bad random numbers and can currently only be used with elliptic curves from the NSA.
- Post-quantum cryptography - there have been some experiments with hybrid ciphers, but nothing that is widely available and standardized yet.
This test site was setup by Hanno Böck. You may also want to check out badkeys, an open source tool to detect and break known vulnerable cryptographic keys.
All content may be considered CC0 / Public Domain. The icon is from SVG Repo, also CC0.