website source; use git clone git:// to clone this repository. (6228B)

      1 # TLS certificates
      2 <!--[time 201712051236.50]-->
      4 [two blog posts in one week, but this was on my mind today so I figured
      5 I'd publish it now]
      7 another thing I wrote back in 2016:
      9 > I use self-signed certificates for all TLS-enabled servers I set up. I
     10 > know there are freely-available certificates being handed out by
     11 > authorities, and I know that Let's Encrypt exists. I do not refrain
     12 > from requesting a CA-signed certificate because I am too lazy to do
     13 > so; if I wanted, I would ready a CSR right away and get that taken
     14 > care of. There is only one key reason I abstain from getting my
     15 > certificate signed by a root signing authority: they are too
     16 > centralised.
     17 > 
     18 > Let's take it from the top: when you install a new operating system,
     19 > be it Windows or Linux or Mac or a mobile device firmware, the system
     20 > will most likely come preloaded with root certificate trusts. Who
     21 > decides to trust these? You haven't hand-picked them, and most people
     22 > don't even bother looking at the list of authorities their system
     23 > trusts. Not to mention, most people don't even recognise half the
     24 > companies and organisations that provide certificates. So, you're at
     25 > the whim of others – all you can do is hope they have your best
     26 > interests at heart and that they aren't screwing you over,
     27 > accidentally or on purpose. In reality, quite a few authorities are
     28 > lazy with checking if a CSR is valid or just a spoof attempt. As long
     29 > as they profit, they don't really have your security at heart.
     30 > 
     31 > And of course, high-profile companies can and do get hacked. This
     32 > holds true for certificate authorities as well. And the more widely
     33 > used a CA is, the more susceptible to attack it will be. Also, while
     34 > this does not apply to everyone, there are workplace, school, and
     35 > governmental filters that are put in place to censor certain sites
     36 > deemed to be unacceptable for access, as well as to detect obscene or
     37 > unsafe (malware) content. In order for a filter to be effective for
     38 > these purposes, it must intercept all your traffic; HTTP is
     39 > straightforward, but HTTPS requires the firewall to strip, analyse,
     40 > and re-encrypt the content that passes between you and the webserver.
     41 > In doing so, it relies on each computer in the network having its own
     42 > certificate installed and accepted. End users may not be fully aware
     43 > that this is going on, and they may believe they are completely safe
     44 > because their browser is not warning them at all. This may be
     45 > acceptable if everyone understands what this filter does and if the
     46 > filter is configured correctly, but that isn't always the case. My
     47 > high school's filter made no distinction between valid and invalid
     48 > certificates, so I could unknowingly be put at risk for accessing an
     49 > unsafe site that appears to my browser to be safe. Plus, if people
     50 > wanted to use their own devices on the school network, they were
     51 > required to install the root certificate even though they were not
     52 > made aware of the consequences this would have.
     53 > 
     54 > So that's one issue: most people don't even explicitly trust the
     55 > certificates installed on their system. Even if you are aware of the
     56 > root certificates you trust, you cannot fully trust that they will
     57 > remain uncompromised and trustworthy in the future. Let's Encrypt was
     58 > proposed as a solution to the skimpy checks most authorities put their
     59 > customers through; Let's Encrypt uses a cryptographic proof to verify
     60 > that you are the owner of your server. While this is a great step in
     61 > the right direction, it does not change the fact that Let's Encrypt is
     62 > still a centralised certificate authority, and thus is fallible to the
     63 > same issues as every other authority.
     64 > 
     65 > In contrast to the common SSL/TLS methods of verification, SSH
     66 > actively encourages you to accept key fingerprints on a per-server
     67 > basis. There is no metadata attached to this (e.g. <q>this key is
     68 > valid on and</q>) that can be changed to
     69 > fool you into accepting the certificate – there's just an arbitrary
     70 > fingerprint that tells the complete truth about who the server is,
     71 > straight to the point and no bullshit. PGP operates in much the same
     72 > way, except that there is certain metadata on keys that describe the
     73 > owner and their E-mail address. With both of these, the key owner can
     74 > disclose the fingerprint via whatever channels he deems secure,
     75 > meaning that an adversary has a harder time compromising this
     76 > information. TLS certificates have fingerprints as well, but most
     77 > client software obscures this in favour of a less helpful <q>this may
     78 > be insecure</q> warning.
     79 > 
     80 > A compromise would be to provide a simple-to-use and
     81 > simple-to-understand web of trust system that combines the benefit of
     82 > <q>lazy</q> and indirect trusting (<q>I trust my friend's judgment,
     83 > therefore I would like to accept all the certificates that he
     84 > does</q>) with the benefit of decentralisation (points of weakness are
     85 > smaller and more dispersed, making damage caused by compromise much
     86 > more tolerable than if a large CA was compromised) and direct trusting
     87 > (<q>I know that this site is what it says it is</q>, similar to the
     88 > <q>add exception</q> function already available in most client
     89 > software). Right now we do not have the luxury of a well-thought trust
     90 > system that is straightforward, unobtrusive, and secure. So for now, I
     91 > will opt only for the <q>secure</q> option since it is the most
     92 > important in this scenario. After all, if you want <q>straightforward
     93 > and unobtrusive</q> without <q>secure</q>, why don't you just use
     94 > HTTP?
     96 to put my money where my mouth was, I did create my own CA to use with
     97 all my websites, and that worked relatively well for about a year. but
     98 lately I have found that some XMPP servers will not federate with
     99 servers that have untrusted certificates, so it was time for me to make
    100 a decision: compatibility or security. I bit the bullet and now I'm
    101 using Let's Encrypt certificates on all my websites and servers, forced
    102 TLS on websites/E-mail/XMPP (and soon IRC), and overall I guess it's a
    103 good move even though I'm upset with the CA system. hopefully one day we
    104 have a better system in place to address the flaws of the CA system.