Nathan Grubb

Creating an easy to update personal website

2019-12-10T00:00:00+00:00

This post will go over how to setup a personal website that’s really easy to update and see your changes. The end goal here is being able to make a change on a GitHub repository that’s automatically reflected live on a test/staging page, then if that looks good being able to merge that to the real page.

Why do this?

Initially I just setup a simple resume type website. It was primarily just for fun so I just spun up an EC2 machine, installed nginx and pointed it to a static page that was configured on that box. When I wanted to make changes, I’d have to SSH to that box and manually make the changes and then view them live. Obviously this isn’t good practice for a production website, but the risk for making a bad change wasn’t that serious since it’s not like my page is actually used for anything productive, after all it was just fo fun.

However, over time this became kind of a hassle as I wanted to make little tweaks. I’d have to remember where I put that SSH key, remember what the username was for that box and then remember the path to where I put the static content. What started as fun, quickly just became annoying and I also wanted to host similar type pages for my wife and also a friend so the nginx configuration grew in complexity. In my head, I thought wouldn’t it be nice if I could just modify something on git and see it live?

Step 1: Containerize your website

I will write another article on how to do this, but the just of this is when you are done with this step you should be able to easily host your website locally with two commands:
- Build your container: docker build -t website .
- Run your container: docker run -t website -p 8080:80
Visit http://localhost:8080 in your browser and this works then you have finished this step.

Step 2: Publish on GitHub

Put everything on from Step 1 in a Git repository and push to GitHub.

Step 3: Register with Docker Hub

Create a free account on https://hub.docker.com.
Create a repository on Docker Hub.
Under Build Settings, connect your GitHub account and chose the repository your made from Step 2.
Create two build rules both based on branches. One for “master” and another for “staging”. You can make the Source and Dokcer Tag the same.
Now every time you make changes to either of those branches in GitHub, DockerHub will attempt to build a new container. It will take a while for Docker Hub to do this, but when it’s done you should be able to run something like docker run -p 8080:80 <docker_account_name>/<docker_repository_name>:<tag> (i.e. docker run -p 8080:80 silentsnowman/resume-website:staging) locally and visit http://localhost:8080 to see your website.

Step 4: Getting a Domain Name

The very first thing you need for this is to buy a domain name. You only need to buy one domain as you can use a sub domain for the staging environment. I purchased this through Route 53 on AWS.

Step 5: Setting Up A Web Server

As you’ll later find out this is a little bit more than a web server, but rather more a docker container host. For this setup, I decided on using AWS EC2 with the latest version of Ubuntu. At the end of this setup we will have nginx running on the host machine which will proxy the request to either our production container or our staging container.

Create a Ubuntu 18.04 EC2 Machine on AWS.

Run the following to install nginx, docker:

# Install Nginx
sudo apt install nginx
# Install Docker
sudo apt install docker.io

Configure nginx:

# TODO: Write this
# Reload nginx configuration
nginx -s reload

Run two docker containers
- docker run -d -p 8000:80 <docker_account_name>/<docker_repository_name>:<tag> (i.e. docker run -p 8000:80 silentsnowman/resume-website:staging)
- docker run -d -p 8000:80 <docker_account_name>/<docker_repository_name>:<tag> (i.e. docker run -p 9000:80 silentsnowman/resume-website:production)
Create a watchtower container (this will keep your other two containers above up to date)
- docker run -d --name watchtower -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower
You probably want to consider telling Docker to start all these containers on boot or restart when they crash. See https://docs.docker.com/config/containers/start-containers-automatically/ for more details.

Step 4: Configure your Domain Name

Now that you have a server and a domain, you need to configure your domain to map to your server. Since I purchased my domain through Route 53 on AWS, I also configured it there.

Create a “A” record with the name of your domain (i.e. nathangrubb.io) and with the value of your EC2 machine’s IPv4 address (i.e. 3.80.251.117)
Create a “CNAME” record with the name of your domain with www. prepended (i.e. www.nathangrubb.io) and the value without the www. prepended (i.e. nathangrubb.io). This will make your website work regardless of if someone uses www. when visiting your site or chooses to exclude it.
Repeat 1 & 2 for a staging subdomain (i.e. staging.nathangrubb.io).

Step 5: Add Security with Certbot

Run the following to install certbox:

# Add Certbot PPA
sudo apt update
sudo apt-get install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt update
# Install Certbox
sudo apt install certbot python-certbot-nginx

Run certbot on command line and follow instructions to create certs for your main domain and staging subdomain.

Step 6: Visit your domain!

Type and/or staging. in a browser! (You can also go to your GitHub repository on your staging branch and make changes. When you commit them, it'll be about an hour before they go live to your staging domain though).

ASN.1 - Common crypto encoding schemes

2018-06-12T00:00:00+00:00

What is ASN.1 and how can I read something that’s encoded with “asn.1”? I’m not going to go into too much detail as there’s other online resources that do this. However, I will link to those resources that do a good job of explaining the details of these standards. Also I’m not an expert, this is just what I have learnt so far (some of which may be wrong).

ASN.1 (Abstract Syntax Notation number One)

I wouldn’t get caught up too much on ASN.1, it’s just an IDL and not an extremely useful thing to know unless you were defining some new key structure (which you probably shouldn’t be doing). As the name suggests this actually isn’t an encoding or even a way to encode but an abstract syntax. The easiest way to relate to this is Apache Thrift or Google Protocol Buffers. These technologies themselves don’t offer anything concrete, but they are the frameworks on which to create new encodings and object types. Two common encoding types of ASN.1 for cryptography are DER and PEM. There are various object types such as public keys, private keys, signatures, curve parameters, etc. To learn more about ASN see Introduction to ASN.1.

Also I know you could use ASN.1 for other things outside of cryptography, but there are IDLs with much better tooling and support like Apache Thrift or Google Protocol Buffers. It’s sort of like saying you can still use SOAP, but why would you when better things exist like JSON API?

DER (Distinguished Encoding Rules)

ASN.1 defines a bunch of different encoding rules like BER, CER, PER, and DER. However, by far the most common is DER. There’s a pretty good write up about DER on MSDN that goes into detail about DER: Distinguished Encoding Rules so I won’t talk about it too much. However, it’s a pretty simple encoding of Tag, Length, Value (or TLV for short). This is a pretty common encoding scheme across computer science to describe nested data. Just off the top of my head I can think of four other places this scheme is used: Apache Thrift, Google Protocol Buffers, Bluetooth Service Discovery Protocol (SDP), and Bluetooth Low Energy Advertisements. I’m sure there are many others as well.

Again MSDN has some good write ups on DER’s TLV encoding scheme:

PEM (Privacy-enhanced Electronic Mail)

One thing I’ve noticed when learning about cryptography is that a lot of the standards are based and designed around email. Since a lot of web standards rely on text encoding such as JSON and XML, it makes sense to re-use email standards like PEM designed around text encoding. PEM is nothing more than base64 encoded DER with some extra metadata. The extra metadata is literally a string at the start and end to describe the base64 encoded DER such as -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- for certificates.

Putting it all together and playing in bash (on macOS)

Now that I have gone over the basics, we can play around with some commands to solidify this understanding.

First I created some handy bash commands in my ~/.bash_profile to make what’s going on a little bit easier to read:

In ~/.bash_profile:

#!/usr/bin/env bash
function remove-first-and-last-line {
  sed -e "1d" -e "$ d"
}

function remove-line-endings {
  tr -d \\n
}

function hex-to-bin {
  xxd -r -p -
}

function bin-to-hex {
  hexdump -v -e '/1 "%02X"'
  #OR
  #xxd -p | remove-line-endings
}

function parse-der {
  openssl asn1parse -inform der
}

function parse-pem {
  openssl asn1parse -inform pem
}

Next, lets create a folder for playing around:
```
cd ~
mkdir crypto-fun
cd crypto-fun
```

Lets generate a private key using the prime256v1 curve.

openssl ecparam -name prime256v1 -genkey -noout -out key.pem

Now we have a elliptic curve private key in PEM format so lets see what it looks like in ASN.1:
```
cat key.pem | parse-pem
```

Given what I described above lets try to manually convert the PEM file to DER to make sure the output is the same:

# First dump the file contents to stdout with cat key.pem
# Next remove the PEM metadata lines: -----BEGIN EC PRIVATE KEY----- and -----END EC PRIVATE KEY----- with remove-first-and-last-line
# Next remove al the line endings to get one full blob of base64 with remove-line-endings
# Next decode the base64 into binary with base64 --decode
# Finally save the output to key.der with > key.der
cat key.pem | remove-first-and-last-line | remove-line-endings | base64 --decode > key.der
cat key.der | parse-der

Lets even diff them just to make sure

diff <(cat key.pem | parse-pem) <(cat key.der | parse-der)

Extra Information

Note that the above experiment in bash was only to solidify an understanding of ASN.1, PEM and DER. There are much better commands for parsing specific types of cryptographic objects. For instance, objects like x509 Certificates often contain DER encoding inside of a DER encoding. Thus instead you should use specific commands for parsing those objects. Here’s a couple examples (I also save these as functions in my ``~/.bash_profile`):

Parsing elliptic private keys (like `key.pem` or `key.der` we created earlier):

cat key.pem | openssl ec -noout -text

# Must specify the input type for OpenSSL as PEM is the default
cat key.der | openssl ec -noout -text -inform der

Parsing elliptic public keys

# First lets create the corresponding public key to our private
cat key.pem | openssl ec -pubout -out pub.pem

# Parse the PEM public key
cat pub.pem | openssl ec -pubin -noout -text

# Now lets use openssl to convert the encoding
cat pub.pem | openssl ec -pubin -pubout -out pub.der -outform der

# Parse the DER public key
cat pub.der | openssl ec -pubin -noout -text -inform der

There’s very similar commands for parsing all types of objects in openssl basically with this same format. There are some exceptions like public keys where you have to specify it’s a public key:

cat file | openssl <object_type> -noout -text -inform <der/pem>

Unfortunately OpenSSL is not the smart to read the context given by PEM and automatically parse that given structure. However, a plus side to that is that it’s symmetrical for parsing PEM and DER files of the same object type.

Final Notes

Hopefully you can parse any PEM or DER file with OpenSSL. You can even deconstruct it down to its rawest form in bytes and dig through the RFC specifications to map the values. I hope if you read this far that this was informative and not a huge waste of time. If it was, well sorry.

Mitigations with TLS

2018-01-14T00:00:00+00:00

Transport Layer Security TLS) puts a lot of trust on the Certificate Authorities (CAs) and the Domain Name System (DNS). Thus you may want to mitigate some of the risks with TLS rather than just assumpting that because something supports TLS it is secure.

TLS can be summarized into two parts: authenticity and privacy. Authenticity is given with two dependencies: one that there is a certificate authority that is trusted and two that you actually talking to a server that owns the domain name you’ve resolved. Privacy is after you’ve established your endpoint is established, you created an encrypted channel to prevent eavesdropping. This writting focuses on the authenticity aspect of TLS and why you may think about adding additional security ontop of it if you can.

Lets dig into DNS a bit. DNS isn’t secure at all and wasn’t designed to be secure. All DNS looks like is finding the first entry for a given domain name (i.e. nathangrubb.io) to an IP address. DNS servers are often chained together so if I configure my DNS server as DNS Google’s Public DNS (8.8.8.8) and the entry isn’t found for nathangrubb.io at 8.8.8.8 chances are it’s chained to another server in which it can continue the search until it either resolves nathangrubb.io to an IP address or runs out of options. Thus DNS can be view as giant hash tables of domain names to IP addresses chained together. Note at no point is there any security to establish that when you do find an IP address that is indeed the server or endpoint owned by the owner of the nathangrubb.io domain. There is Domain Name System Security Extensions (DNSSEC), but it’s not widely implemented at least at the time of this writing.

Alright so with this knowledge that traditional DNS has no security, before we talk about Certificate Authorities (CAs) we need to briefly talk about asymmetric cryptography. Asymmetric cryptography is the idea that is very easy to do a mathematical operation one way that’s very difficult to do in reverse. I don’t want to dig into it too much but for the sake of this writting lets just simplify it so say asymmetric cryptography is the idea that I can do something with a secret (private key) that can be verified with something that is public knowledge (public key). This is known as cryptographic signing or signatures.

Now we can dig into what a Certificate Authority is and how they contribute to TLS (FYI these aren’t specific details, this is just very high level explanation). Most browsers and operating systems come installed with a certificate store. This certificate store is all the root certificates that the browser and/or operating system trusts. A certificate is nothing more than a signed public key and some other metadata such as the signer/issuer, common name, expiration, and zero or more domain names. There’s some other metadata in here like what the certificate can be used for and algorithms, but this is the jist. A root certificate means that it is self-signed (i.e. it was signed by the private key corresponding to the public key that’s in it). These root certificates are each a representation of a Certificate Authority or “trustable entity”.

Going back to TLS, after I’ve resolved a domain name to an IP address, the next step in this is to ask for a certificate at the endpoint for that endpoint. The assumption here is that the owner of the domain name has a private key on their server that corresponds to the public key in this certificate. This certificate will have an issuer and we can see if that issuer is in our certificate store. If it is, then we can take the public key from that certificate in the certificate store and verify the signature of the certificate we downloaded from the endpoint. Next we can verify the domain name in the certificate is the one we resolved to an IP address. The next step in this is issueing a random piece of data to the endpoint so they can sign it with the private key they have on the server. This ensures that I know I’m talking to the right endpoint and not just some random server returning the public certificate (after all the public certificate is just public information).

There’s a pretty big hole here. What if a certificate authority doesn’t do all the checks when it issues a certificate to the “owner” of a domain or any of the Certificate Authorities is compromised. There’s a lot of trust put on the certificate authority to only sign certificates that are “valid” and keep their private keys well protected (ideally offline). The criteria for determining if you own a domain name isn’t standard and different CAs have different protocols for doing this. Thus say I know a certificate authority isn’t that great and I can get them to sign a certificate saying I own “google.com”. Now all I have to do is handle requests as if I’m a public DNS like 8.8.8.8 and give out my IP address for my google.com server which has the private key to the signed certificate which I shouldn’t have. Thus I’ve hacked a TLS endpoint so you may think you are talking to google.com and it shows secure in your browser, but you’re actually talking to my endpoint. I may even feed the requests to google and act as a man in the middle so you don’t even notice that I’m there. Except maybe I save your username and password when you login ;0.

With this all in mind, what are some of the mitigations I can implement if I want to develop a secure ecosystem?

If you control just the client side of things, you can limit the certificate store to just the certificate authorities you rely on. However this can be pretty dangerous if you just control the client side and don’t have any backend system to update that certificate store. For instance, say I’m developing a client that relies on Facebook.com and I limit my certificate store to “DigiCert High Assurance EV Root CA” on that client I deploy. If Facebook decides they want to switch CAs, the client you’ve deployed out in the field won’t be able to talk to Facebook.com anymore.

If you control the full ecosystem, this is where you really can safely mitigate against TLS. There’s a few ways you can do this such as the above point of limiting your certificate trust store and also implementing a system for renewing/refresing that certificate store. However to do this, you probably want to act as your own certificate authority to do so. Thus you could rely on TLS for most things, but you can provide additional security within your own ecosystem by taking advantage of a certificate chain you control. For instance, you could install your public certificate root on your clients and develop a system which clients can download a certificate chain that chains back to the public root installed on your clients and a new certificate trust store that’s signed with a certificate in that certificate chain.

If you do decide to act as your own Certificate Authority, you should use a Hardware Security Module (HSM) for managing your root private key. The idea with an HSM is that the private key never leaves the hardware but can perform actions with the private key on the hardware. This provides a physical barrier and also audit trail when anyone accesses that root private key. Also you can keep that HSM completely offline and only use it to sign other certificates. In fact most Certificate Authorities do this and when they are fullfilling a signing request they are using an intermediate certificate’s private key.

What if I don’t control the full ecosystem?

If you don’t control the full ecosystem, you can still mitigate some other attack vectors with TLS but only allowing strong ciphers and the newest version of TLS. For instance TLS supports many different encryption ciphers and algorithms for signing and you can have your client deny anything that’s not GCM-256 bit AES encryption or better and only trust signatures with prime256 Elliptic Curve signatures or better. This tends to all come down to what your dependencies are and what they support. Security is just about raising the minimum bar, you never have a completely secure system. Even if it was impossible to break from a technological point of view, there’s always social engineering :).

Links: