1 files changed, 170 insertions, 0 deletions
diff --git a/content/blog/201609-letsencrypt.rst b/content/blog/201609-letsencrypt.rst
new file mode 100644
index 0000000..a4ec1d6
--- /dev/null
+++ b/content/blog/201609-letsencrypt.rst
@@ -0,0 +1,170 @@
+Let's encrypt it all
+####################
+
+:date: 2016-09-28 20:00
+:modified: 2016-09-29 20:00
+:tags: archlinux, letsencrypt, openssl
+:category: admin
+:slug: lets-encrypt-it-all
+:summary: A short review on half a year of using |website-letsencrypt| for my services.
+:authors: David Runge
+
+| For a couple of months now I have been using |website-letsencrypt| to generate free and valid certificates for all the services I run.
+| In many places the free |wiki-certificate_authority| (short CA) has spread like wild-fire. From small to large scale services, many adopted it and |blog-letsencrypt-1_million_certificates|.
+| As a visitor to this website you have probably noticed the small green lock sign next to the address bar. The certificate used for this website is accepted to be valid by your browser (and also by your operating system).
+|
+
+Certificate Authority
+_____________________
+| *"So, what's so interesting about* |website-letsencrypt| *and why would I want to use it?"* you might ask now.
+| To understand the answer to this, you need to learn about the status-quo and how things have been done before |website-letsencrypt| was around.
+|
+| While anyone can create a certificate and use it for their service, CAs are there to ensure - as a trusted third-party - to your computer, that the certificate, which has been created and is used by you, was really yours to begin with.
+| If someone else created a certificate in your name and used it in front of your service (e.g. |wiki-man_in_the_middle|), there would be no way for you to tell, whether you are actually talking to the service you wanted to talk to and the attacker could easily use that certificate to read your traffic (steal your passwords and private data, etc.).
+|
+
+Big players
+-----------
+| Because of this obvious flaw in the design of how encryption is taking place between computers over a network, CAs have been installed as a way to *validate* your certificate by signing it and thus telling your computer, that the certificate in use is *trusted*, because *they know you*.
+| The *they know you* part of it usually meant, that you payed money to a company (CAs up to last year, with the exception of |website-cacert| were private companies), to let it start a script (which i.e. is part of the |website-openssl| software bundle) to sign a certificate or even generate it and afterwards sign it for you.
+| Many of them do only casual checking of identity and/or ownership of domains applicated for (e.g. measures such as sending to certain mail addresses on a host are not necessarily secure ways of validating ownership).
+| As you can imagine though, this is a money machine.
+|
+
+More Flaws
+----------
+| This is the moment, where you should ask yourself: *"Well, what if one of the CAs is a bad boy or messes up in such a way that it issues certificates for anyone without checking or even for services that don't belong to the applicators?"*
+| Well... it will come to no surprise: |blog-turktrust_fiasko| and will happen (again).
+| In a way this would also be a perfect time to ask yourself, if encrypted traffic is all that secure after all. A little paranoia never hurt.
+|
+| The certificates with which the CAs sign other certificates and thereby *trust* them are called **root certificates** and are usually shipped by your operating system and/or your web browser. These bundles are used by all applications that understand encrypted traffic to check whether the connection they are about to make is trusted by a CA.
+| Now, there is no way of telling whether your CA bundle is sufficient or harmful, but at some point you have to trust your operating system. You do trust your operating system, don't you? Well, |news-microsoft_certificate_blacklist|.
+| To circumvent this flaw in turn, Google and Mozilla introduced |wiki-certificate_pinning| in their browsers, which can detect fraudulent certificates for some domains by checking against checksums (derived from a |wiki-hash_function|) of the root certificate with which these domains are signed. These checksums (or sometimes called *hashes*) are shipped with the browser, which should make you wonder, if you can trust those either.
+| If you learned more about how this all works, you would probably consider moving to the woods far away from all this.
+|
+
+Self-sign
+---------
+| For people or associations, that wanted to use their services encrypted, but not go to the lengths of spending a lot of money on top of their hosting costs, it was a typical move to just |wiki-self-signed_certificate| their certificates. I've done it myself and basically, there's no harm in being your own CA.
+| Unfortunately (or luckily) browser became more restrictive about whom and how they trusted over the years and made it increasingly painful to use self-signed certificates. In Firefox you could *add an exception* for your certificate and that was that. Chrome/Chromium introduced an annoying red warning page that you had to endure each time you encountered a self-signed certificate.
+|
+
+Teaming up
+----------
+| In 2003 |website-cacert| emerged as a community driven project to become a free and non-profit CA. Unfortunately its root certificate was never properly accepted in all operating systems or browsers.
+| Although its |wiki-web-of-trust| system for user validation was a neat idea, the association struggled for acceptance due to its insufficient auditing and verification mechanisms for a long time and finally lost to Mozilla's CA certificate policy, which led to a poor |wiki-cacert_inclusion_status| overall. 
+|
+
+Encrypt the interwebz
+---------------------
+| In 2014 another player entered the stage to make all that pain go away. I was very excited to see a |stream-31c3-letsencrypt| on |website-letsencrypt| amongst the content for |wiki-31c3|.
+| Their goal was (and still is) to achieve a maximum throughput in encrypted traffic and for that they were teaming up with some big players (|website-mozilla|, |website-eff|, |website-cisco|, |website-akamai|, |website-university_of_michigan|) to develop their automated validation system, that would offer trusted certificates to anyone running a website for free.
+|
+| While self-signed and |website-cacert| certificates were becoming increasingly limiting and the sometimes high costs of buying a trusted certificate kept many from encrypting their traffic all together, the services *certified* by the usual CAs on the other hand stood in the light of false pretense to be *more secure* than the formerly named.
+| |website-letsencrypt| has indeed come to restore the balance and free what should be free: Encrypted traffic.
+| By issuing |wiki-intermediate_certificate|, which were cross-signed by |website-identrust|, |website-letsencrypt| is able to sign and thereby trust certificates it deems valid according to its |github-letsencrypt| validation system.
+|
+
+Using letsencrypt
+_________________
+| Their software is by now packaged for all major Linux distributions (and as a matter of fact, the Internet runs on Linux), so acquiring a valid certificate for your website has become so easy, it's insane.
+| Let me tell you about how I do things on |website-archlinux| on this very server.
+|
+|
+
+.. |blog-letsencrypt-1_million_certificates| raw:: html
+
+  <a href="https://letsencrypt.org/2016/03/08/our-millionth-cert.html" target="_blank">the amount of issued certificates has grown over 1 million in just four months</a>
+
+.. |website-letsencrypt| raw:: html
+
+  <a href="https://letsencrypt.org" target="_blank">Let's Encrypt</a>
+
+.. |wiki-certificate_authority| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Certificate_authority" target="_blank">Certificate Authority</a>
+
+.. |wiki-man_in_the_middle| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack" target="_blank">man-in-the-middle attack</a>
+
+.. |website-cacert| raw:: html
+
+  <a href="http://www.cacert.org/" target="_blank">CAcert</a>
+
+.. |website-openssl| raw:: html
+
+  <a href="https://openssl.org" target="_blank">OpenSSL</a>
+
+.. |blog-turktrust_fiasko| raw:: html
+
+  <a href="https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ssl-certificate-fiasco-what-happened-and-what-happens-next/" target="_blank">This has happened</a>
+
+.. |news-microsoft_certificate_blacklist| raw:: html
+
+  <a href="http://www.pcworld.com/article/2897992/microsoft-blacklists-fraudulently-issued-ssl-certificate.html" target="_blank">that's too bad</a>
+
+.. |wiki-certificate_pinning| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning" target="_blank">certificate pinning</a>
+
+.. |wiki-self-signed_certificate| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Self-signed_certificate" target="_blank">self-sign</a>
+
+.. |wiki-hash_function| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Hash_function" target="_blank">hash function</a>
+
+.. |wiki-cacert_inclusion_status| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/CAcert.org#Inclusion_status" target="_blank">inclusion status</a>
+
+.. |wiki-web-of-trust| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">web-of-trust</a>
+
+.. |stream-31c3-letsencrypt| raw:: html
+
+  <a href="https://media.ccc.de/v/31c3_-_6397_-_en_-_saal_6_-_201412301400_-_let_s_encrypt_-_seth_schoen" target="_blank">presentation</a>
+
+.. |wiki-31c3| raw:: html
+
+  <a href="https://events.ccc.de/congress/2014/wiki/Main_Page" target="_blank">31C3</a>
+
+.. |website-mozilla| raw:: html
+
+  <a href="https://mozilla.org" target="_blank">Mozilla</a>
+
+.. |website-eff| raw:: html
+
+  <a href="https://eff.org" target="_blank">EFF</a>
+
+.. |website-university_of_michigan| raw:: html
+
+  <a href="https://www.umich.edu/" target="_blank">University of Michigan</a>
+
+.. |website-cisco| raw:: html
+
+  <a href="https://www.cisco.com/" target="_blank">Cisco Systems</a>
+
+.. |website-akamai| raw:: html
+
+  <a href="https://akamai.com/" target="_blank">Akamai</a>
+
+.. |wiki-intermediate_certificate| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Intermediate_Certificate_Authority" target="_blank">intermediate certificates</a>
+
+.. |website-identrust| raw:: html
+
+  <a href="https://identrust.com" target="_blank">IdenTrust</a>
+
+.. |github-letsencrypt| raw:: html
+
+  <a href="https://github.com/letsencrypt" target="_blank">openly developed</a>
+
+.. |website-archlinux| raw:: html
+
+  <a href="https://archlinux.org" target="_blank">Arch Linux</a>
+