Communications between the Octopus Deploy server and Tentacles are secured using X.509 certificates. When Octopus is installed, a new self-signed certificate is generated. When Tentacles are installed, they also generate a new, self-signed certificate. In this post I'd like to discuss why we use self-signed certificates - after all, isn't that bad?
Background
When the Tentacle is registered in Octopus, the thumbprints (which identify the public key of the certificates) are exchanged - that is, you manually paste the Octopus thumbprint into the Tentacle setup wizard, and you manually verify the Tentacle's thumbprint in the Octopus UI. This screenshot is from Octopus 1.0 but the same concept exists in 2.6:
When Octopus connects to a Tentacle, it verifies that the Tentacle presents a certificate with the thumbprint it expects. Likewise, when Tentacle handles a connection, it verifies that the connection is from an Octopus server that it trusts. Both sides abort the connection if the other side isn't who they think it is.
Why self signed?
A question sometimes comes up around why we use self-signed certificates - isn't that a bad practice? To answer this, let's reverse the question: why use a certificate authority?
Suppose you want to do some online banking. You go to your bank's website, and are redirected to their HTTPS site.
You don't actually know if this is Bank of America or not. But your browser trusts Symantec (who own VeriSign), and Symantec tells you "When someone ordered a certificate for BankOfAmerica.com, we phoned them and did some other checks, and we're pretty sure it's really Bank of America. And you trust us because we're Norton, right?"
Here's a more secure alternative to relying on certificate authorities (CA's) like Symantec: when you were in the bank branch setting up your account, shaking hands with the bank manager, they gave you a thumbprint for their website certificate. You write it down on some paper, and when you get home, you plug it in to your computer. You then wouldn't need any certificate authorities: your computer would trust BankOfAmerica.com only, without the need for any third parties.
We have certificate authorities for convenience, because expecting people to write down public keys for every site they plan to visit is too much effort. We don't have certificate authorities for security: they actually reduce the security. CA's get compromised: remember DigiNotar?
If Octopus used CA's
If CA's were used with Octopus, there are two ways we could use them:
- We just trust anything issued by a CA. Instead of checking whether the Octopus/Tentacle was trusted, we'd just assume that if they present a certificate issued by YourCompanyCA, then it must be OK to communicate.
- We verify the thumbprints anyway and use those to establish trust.
Approach #1 is dangerous because if the CA is compromised, then every machine on the network is effectively compromised, since anyone with a valid certificate could pretend to be anyone else. This applies whether the CA is internal to your organization, or a trusted third party. With our current approach, since we verify certificates individually, it's not possible for machine A to pretend to be machine B without having machine B's private key.
Approach #2 is better, except we're effectively ignoring the CA anyway. What value does the CA provide in this case if we are verifying thumbprints ourselves?
The argument could be made that Octopus should support use of CA's to issue certificates just for the 'feel good' factor as we've been conditioned to think that self-signed certificates are somehow intrinsically bad. You can use Tentacle.exe import-certificate to make Tentacles use a CA-issued certificate (but there's no way to do this on the Octopus Server currently), but I think the argument is driven by company policy ("Self-signed certs are forbidden!") rather than by sound reasoning.
The only argument we can think of as to why a CA would make sense from a security point of view in Octopus is for revocation lists. But you can always tell Octopus/Tentacle to no longer trust a given certificate without needing CRL's, so I think that argument falls down too.
We take security seriously in Octopus, and we also try our best to make it easy to use. We think the exchanging of thumbprints and use of self-signed certificates is the best solution from a security point of view, and adding any extra layers of CA support seems to make the software more complicated than necessary, and either adds no value, or creates an attack vector depending on how it would be implemented. I hope this post sheds some light on our reasoning.
Thanks to OJ from Beyond Binary for reviewing a draft of this post
