wowana.me

website source; use git clone git://wowana.me/wowana.me.git to clone this repository.

tls-certificates.md (6228B)

 # TLS certificates
 <!--[time 201712051236.50]-->
 
 [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. <q>this key is
 > valid on domain.xyz and www.domain.xyz</q>) 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 <q>this may
 > be insecure</q> warning.
 > 
 > A compromise would be to provide a simple-to-use and
 > simple-to-understand web of trust system that combines the benefit of
 > <q>lazy</q> and indirect trusting (<q>I trust my friend's judgment,
 > therefore I would like to accept all the certificates that he
 > does</q>) 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
 > (<q>I know that this site is what it says it is</q>, similar to the
 > <q>add exception</q> 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 <q>secure</q> option since it is the most
 > important in this scenario. After all, if you want <q>straightforward
 > and unobtrusive</q> without <q>secure</q>, 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.