Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
In our company we have an internal CA certificate for signing various things including the proxied (MITM'd) HTTPS connections.
Suppose we use this CA to sign a key for "localhost" for use in automated testing (so we don't have to mess about with custom Firefox profiles). This key would be distributed to the developers, probably by checking it into the source repo.
What are the dangers of this approach? Suppose an attacker stole the key, and could then sign localhost HTTPS. What could they do?
Two years after the initial question, things seem to have changed a bit. Facing the same issue, I found that the letsencrypt service does not sign certificates for localhost and the reason for that is stated here: https://github.com/letsencrypt/boulder/issues/137 and here: https://cabforum.org/pipermail/public/2015-June/005673.html
In a nutshell, indeed "multiple resolvers (notably, OS X's) send localhost queries to the network" instead of keeping them local, so having a signed certificate for localhost can be a security risk.
With such a certificate, any system who trusts your internal CA will trust a server running on "localhost" as being genuine, i.e. running really on "localhost". But "localhost" can be reached, network wise, only locally, so if your client successfully connects to https://localhost/whatever then it already knows that it is talking with the local machine. Therefore, no extra security issue.
Of course, the certificate only authenticates the host name. It says nothing about whether the server is malicious or benign, only about who the server is.
Mind, though, that if someone modifies the local "hosts" file, then accesses to "localhost" could be redirected elsewhere -- but someone who can do that on your machine already owns it and could insert his own rogue CA in your trust store anyway.
I don't see any more significant threat for localhost than any other certificate. The main abuse of an SSL cert is to convince a system that you are the system they want to talk to when you are not, but an attacker couldn't compromise the traffic going to localhost unless the client computer is already compromised at a fairly low level (at least has access to modify the HOSTS file). At which point, the entire charade is unnecessary since they could simply install their own cert or do whatever else they want.
There's almost no threat at all. Do you trust your own computer not to attempt an MITM attack against you? Then there ought to be no problem.
When you try to access localhost, the network adapter isn't even touched. If someone stole the key, the could use it to convince their own computer that it is itself. Or any computer that they have access to (if they have access to computers, however, you have a bigger problem since they can intercept the unencrypted data before it goes through TLS)
The only danger would be if your hosts file has been tampered with.
