SSL Certificates

Explanation: Internet

Introduction

Making sure you're connecting to the site you think you are is a big deal. It's honestly not that hard for someone to hijack your DNS so the address google.com sends you to some virus-ridden phishing server in Madagascar. The main tool to prevent this from happening is the SSL (Secure Sockets Layer) Certificate. Using publickey cryptography, you can generate keys (private) and certificates (public) that both encrypt the connection and confirm that you're connecting to the real google.com. Any site involving sensitive data, such as a password, should have a certificate. As a side note, that lock you see to the left of the address bar in your web browser when you load a web site is telling you about the site's certificate.

Certificate Authorities

In order for this scheme to work, you need to trust that the certificate being supplied by the website is authentic. This is achieved using a CA (Certificate Authority) who adds their own "root" certificate to a website's certificate. All modern operating systems, web browsers, and mail clients ship pre-loaded with a list of trusted CA certificates. If your browser encounters a certificate signed by any of these trusted CAs, it trusts the connection and confirms that the site is who they say they are.

Self-Signed Certificates

All of that is great, but getting a CA to sign your certificates generally costs a few hundred dollars a year. For a personal webserver like ~grandline, that's honestly not worth it, since there is a second option. You can sign your own certificates, which then requires visitors to trust you, rather than trust a CA that signed it. So basically, I'm acting as my own CA, and using a "Root" certificate that I created to sign all of my other certificates. A self-signed certificate is equally as good at encryption as a CA-signed certificate. As mentioned previously, the only difference is trust. With a CA-signed certificate, the visitor trusts the CA, and therefore trusts certificates signed by the CA. This is meaningful because CAs require some form of application or background check in an attempt to make sure that the applicant is truthful about their identity. With a self-signed certificate, the visitor has no choice but to trust whatever random stranger runs the random website they are currently viewing.

Requirements for Security

In order for the SSL paradigm to ensure the security and identity of a website, two requirements must be met. First, the CA's privatekey must remain secret and never be shared with anyone. If a third party had the CA's privatekey, they could sign whatever certificate they wanted, and everyone who trusts the CA would automatically trust any certificates created by the third party and signed with the stolen key. Second, the visitor needs a copy of the CA's certificate, so that when they encounter a website with a certificate signed by the CA, they can identify it as trustworthy. The common solution to this problem is including a bunch of CA certificates in internet-enabled software. All major operating systems, web browsers, and mail clients ship with a selection of trusted CA certificates.

Distributing a Self-Signed Certificate

This is actually a non-trivial problem, given how the system works and past attacks. For example, it is not uncommon to encounter sites that provide downloads of web browsers with malicious CA certificates included. Installing such a browser could then flag the real google.com as fraudulent, and identify the malware server in Madagascar as the true Google. The problem is worse with self-signed certificates, since making them available via this website defeats the entire purpose. Let's say I include a link right here to download my root CA cert. If someone manages to hijack your browser and send you to a fake ~grandline, then they can change that link to a fake certificate that then guarantees you will trust the fake and distrust the true. While this is honestly incredibly unlikely for a server as small and lightly-trafficked as ~grandline, in order to be as secure as possible, I need to get my certificate to you via some communication channel completely external to this website. My current solution is to e-mail my certificate to every user when they join, hopefully guaranteeing its authenticity.

How to Get ~grandline's Root CA Certificate

While I maintain that the best practice (balancing ease of use and security) is for me to attach it to an e-mail and send it to you, you can also find it in the places listed below. The list is in order of security, from most secure to least secure. Also check out this tutorial for instructions on adding the certificate to common programs.

  1. Get it from me in person on a thumb drive.
  2. Ask me to e-mail it to you. Only accept it if it comes from admin@jahschwa.com, the SPF check passes, and the DKIM check passes. You can see these results with "View Original" or similar.
  3. Get the certificate from my GitHub repository.
  4. Use ssh, but make sure you are connecting to the correct IP address by checking with an external DNS server. Example: host jahschwa.com should show the same IP address as host jahschwa.com 8.8.8.8. The certificate is at /home/share/jahschwa.crt.
  5. Download the certificate from here.
  6. Choose "Add exception" or "Import certificate" when warned by your browser or other program.