TLS certificates

[two blog posts in one week, but this was on my mind today so I figured I'd publish it now]

another thing I wrote back in 2016:

I use self-signed certificates for all TLS-enabled servers I set up. I know there are freely-available certificates being handed out by authorities, and I know that Let's Encrypt exists. I do not refrain from requesting a CA-signed certificate because I am too lazy to do so; if I wanted, I would ready a CSR right away and get that taken care of. There is only one key reason I abstain from getting my certificate signed by a root signing authority: they are too centralised.

Let's take it from the top: when you install a new operating system, be it Windows or Linux or Mac or a mobile device firmware, the system will most likely come preloaded with root certificate trusts. Who decides to trust these? You haven't hand-picked them, and most people don't even bother looking at the list of authorities their system trusts. Not to mention, most people don't even recognise half the companies and organisations that provide certificates. So, you're at the whim of others – all you can do is hope they have your best interests at heart and that they aren't screwing you over, accidentally or on purpose. In reality, quite a few authorities are lazy with checking if a CSR is valid or just a spoof attempt. As long as they profit, they don't really have your security at heart.

And of course, high-profile companies can and do get hacked. This holds true for certificate authorities as well. And the more widely used a CA is, the more susceptible to attack it will be. Also, while this does not apply to everyone, there are workplace, school, and governmental filters that are put in place to censor certain sites deemed to be unacceptable for access, as well as to detect obscene or unsafe (malware) content. In order for a filter to be effective for these purposes, it must intercept all your traffic; HTTP is straightforward, but HTTPS requires the firewall to strip, analyse, and re-encrypt the content that passes between you and the webserver. In doing so, it relies on each computer in the network having its own certificate installed and accepted. End users may not be fully aware that this is going on, and they may believe they are completely safe because their browser is not warning them at all. This may be acceptable if everyone understands what this filter does and if the filter is configured correctly, but that isn't always the case. My high school's filter made no distinction between valid and invalid certificates, so I could unknowingly be put at risk for accessing an unsafe site that appears to my browser to be safe. Plus, if people wanted to use their own devices on the school network, they were required to install the root certificate even though they were not made aware of the consequences this would have.

So that's one issue: most people don't even explicitly trust the certificates installed on their system. Even if you are aware of the root certificates you trust, you cannot fully trust that they will remain uncompromised and trustworthy in the future. Let's Encrypt was proposed as a solution to the skimpy checks most authorities put their customers through; Let's Encrypt uses a cryptographic proof to verify that you are the owner of your server. While this is a great step in the right direction, it does not change the fact that Let's Encrypt is still a centralised certificate authority, and thus is fallible to the same issues as every other authority.

In contrast to the common SSL/TLS methods of verification, SSH actively encourages you to accept key fingerprints on a per-server basis. There is no metadata attached to this (e.g. this key is valid on domain.xyz and www.domain.xyz) that can be changed to fool you into accepting the certificate – there's just an arbitrary fingerprint that tells the complete truth about who the server is, straight to the point and no bullshit. PGP operates in much the same way, except that there is certain metadata on keys that describe the owner and their E-mail address. With both of these, the key owner can disclose the fingerprint via whatever channels he deems secure, meaning that an adversary has a harder time compromising this information. TLS certificates have fingerprints as well, but most client software obscures this in favour of a less helpful this may be insecure warning.

A compromise would be to provide a simple-to-use and simple-to-understand web of trust system that combines the benefit of lazy and indirect trusting (I trust my friend's judgment, therefore I would like to accept all the certificates that he does) with the benefit of decentralisation (points of weakness are smaller and more dispersed, making damage caused by compromise much more tolerable than if a large CA was compromised) and direct trusting (I know that this site is what it says it is, similar to the add exception function already available in most client software). Right now we do not have the luxury of a well-thought trust system that is straightforward, unobtrusive, and secure. So for now, I will opt only for the secure option since it is the most important in this scenario. After all, if you want straightforward and unobtrusive without secure, why don't you just use HTTP?

to put my money where my mouth was, I did create my own CA to use with all my websites, and that worked relatively well for about a year. but lately I have found that some XMPP servers will not federate with servers that have untrusted certificates, so it was time for me to make a decision: compatibility or security. I bit the bullet and now I'm using Let's Encrypt certificates on all my websites and servers, forced TLS on websites/E-mail/XMPP (and soon IRC), and overall I guess it's a good move even though I'm upset with the CA system. hopefully one day we have a better system in place to address the flaws of the CA system.