September 4, 2017
At some point after I discovered Linux and the joys of running my own Internet services, I began wanting security assurances. No matter where in the world I was, I wanted to guarantee that I was communicating with exactly the network endpoints that I had originally configured, and that no-one could casually intercept network messages to my servers.
This is how most people are introduced to the realities of TLS certificates in the Web’s Public Key Infrastructure (PKI). But certificates and signing are either a deep rabbit-hole or a bottomless pit! To truly comprehend the lifecycle of a certificate in the Web PKI, you’ll find yourself creating your own Certificate Authority, rather than simply purchasing certificates from an online third-party.
Managing my own personal CAs has been a non-trivial side project. The most difficult part is not technology or tooling, but understanding the spectrum of design choices and cohesively reasoning and documenting all of them. Hopefully this series on PKI design helps you understand one of the Internet’s foundational technologies, even if you decide that building your own PKI is better left as a thought exercise!
When you trust a server’s certificate, you are allowing your computer to begin an encrypted network connection to that server. Having trusted communications is valuable, but more important are the standards for how businesses securely store data on their servers. Web PKI and Transport-Layer Security standards have nothing to do with the security of data at rest on a server. Even an Extended-Validation certificate could easily be issued to someone who’s server has been secretly compromised without either the server admin or the issuing authority’s knowledge.
PKI trust only refers to the security of the network communication to a server. While this trust ends up being weak, it’s still better than having no assurance you’re actually communicating to, say, your bank. A good metaphor for PKI trust is checking someone’s driver’s license and saying “you resemble the person in this photo — carry on!” As a random observer, you’re not trained in how to validate the details of a license, though you can judge on appearance and fit/finish that a cheaply-made fake ID might lack.
If your computer shipped without a pre-installed set of trusted certificates, all Internet trust decisions would be similar to the “gut” decision around validating a driver’s license. Fortunately, operating systems or browsers make trust decisions on your behalf by including a set of default-trusted Certificate Authorities. Trusting your OS is one component of the indirect trust involved in the Web PKI. To understand the others, I’ll need to discuss how signing chains work in a future installment.
Conceptually, indirect trust is very weak, only one level above “gut trust”. And the more levels of indirection, the more fragile the trust. However, it’s possible to manage your trust chains and certificate issuance more directly, by creating your own Certificate Authority, and managing your OS’s list of CAs. For signing chains, the more you control the keys and system security of each step of the signing, the more you can trust the server certificates in the chain.
With all that indirection, the green lock in your browser starts feeling pretty fungible! Your OS trusted a third-party CA, and you trust your OS, therefore you should trust the remote server is the rightful recipient of your web traffic. But the remote server might be compromised, and the remote service’s data security practices might be questionable, and the OS vendor or CAs may have shady dealings with governments or institutions you don’t personally trust. Heaven forbid that a CA owner decides to sell their service to a new company — should you just trust that the new company has the same interests in managing the CA they purchased? Who knows!?
PKI trust can be modelled like any series of trust relationships between institutions, where any link in the chain appears brittle under the microscope, and yet there is great public and economic value in maintaining the chains and offering some definition of trust, even a weak one. Crucially, the social and political management of PKI services should be the basis of whether you trust a section of the Web PKI or not. Trust and risk management cannot be automated or programatically solved in the same way that other computer science and data management tasks can.