Mitigations with TLS
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: