Finally, we have made the move to host all of our services over TLS only. That means that any website or file that is being downloaded, any email that is being sent or received is being encrypted. Everything is secure now! Well… not really. This is a brief article about TLS considerations and some real-world issues with it.
Up until about two weeks ago, none of the IPFire web services had a certificate – with a few exceptions. If you went onto our main website, you would have just connected over HTTP and that is it. There was no TLS involved whatsoever. It didn’t need it really. At no time any personal data was being transferred. It was just our website which is publicly available for everyone.
For some web services like Bugzilla and some more we used our own CA. That allowed us to issue our own certificates with what ever settings we wanted and we could deploy them very easily. One main incentive was to avoid paying for a number of certificates at a public CA which wasn’t possible for such a number of certificates and being as underfunded as we are it was a wrong place to invest the money. I toyed around with DANE for a little bit, but since no web browser implements this, this is nothing better than a trial.
Let’s Encrypt everything!
But those days are gone now. Over the last weeks I abandoned the IPFire CA and replaced any existing certificates by certificates from Let’s Encrypt. It has been suggested many times by many users but I refused to do it because I do not really see the point of just encrypting everything for the sake of encryption. Encryption is from my point of view very useless in the case of our main website and mirror servers.
What convinced me now to do it is a completely different argument: Integrity. I do not want somebody else injecting some malicious Javascript code into our website. That is the only reason Let’s Encrypt makes sense. Encryption would technically work without a publicly signed certificate and of course in the case of the IPFire forums it is a necessity.
In addition to the sites that already had a certificate, I set up Let’s Encrypt for literally everything else, too. And since this only makes sense if everyone is using TLS, we now redirect every HTTP request to HTTPS first before having our web server replying to it. That means any website, any download is now going over HTTPS.
To enforce that, we use HTTP Strict Transport Security (or HSTS) which lets every browser remember, that “www.ipfire.org” is only available over HTTPS. The next time, you enter that domain into your address bar, the browser will remember to connect over HTTPS only.
Improving TLS performance
Additionally, we use OCSP Stapling, which will help to improve the speed of setting up the first TLS connection. The browser would contact the CA which is Let’s Encrypt in our case and check if the certificate that has been received from the web server is still valid or has been revoked. That takes some time since it is an extra TCP connection and the CA has to respond to a large number of these OCSP requests.
Instead, our web server does this for you and staples the OCSP response to the TLS handshake. It is signed and therefore the browser can trust it without having to contact the CA to verify.
On top of that, we cache TLS sessions to resume them faster.
Securing Encryption
We only allow the browsers to use TLS 1.2. Anything else is not possible since they are considered broken or cryptographically weak.
And finally, we reviewed the list of allowed ciphers and removed anything else but AES256 and AES128 in GCM mode or in CBC mode with SHA384 or SHA256. We introduced using ChaCha20 with Poly1305.
The key handshare is only possible using either the Elliptic Curve Diffie Hellman algorithm or ECDSA. None of which rely on a discrete logarithm.
Downsides of all of this
This is now all new and shiny with icing on top. Latest cryptography. Strongest ciphers. What could go wrong?
We will inevitably kick out a number of users here to enforce these new things. That is at least: Firefox 26 and older, Chrome 29 and older, IE 10 and older, Opera 16 and older, Safari 8 and older and Android 4 and older. Those devices and browser won’t be able to contact our web servers securely and more and since we insist using TLS only, they won’t be able to connect with us at all.
The idea is to try this out now. If you have issues connecting and it should work, please let us know. This will need to be a trade-off of what is good security and what people actually use. But I do have the intention to force you XP users out there to finally upgrade. It’s 2017.
Late spring cleaning in progress
All these things happened during our yearly security review and updating where we check if every part of our infrastructure is using the best possible security that is available to us.
Of course we also added Let’s Encrypt certificates to our other services like Mail and XMPP. But we are not fully done and will need to improve more when ever there is time to do so.