13

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?

|improve this question
3

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.

|improve this answer
7

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.

|improve this answer
4

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.

|improve this answer
  • So would you agree that it's a reasonably safe thing to do? – artbristol Apr 29 '13 at 13:14
  • I think it is safe, but not necessarily the best. What do you gain over a self-signed and locally trusted certificate produced on the developer's machine? Locally signed certs could also be used for the developer's machine name. For example, my development box has a self signed cert that is valid for both localhost and mymachine.mycompany.com and is only trusted on my machine since nobody else actually needs to trust it. – AJ Henderson Apr 29 '13 at 13:24
  • All I'm trying to gain is a bit of build simplicity - when you run Firefox in WebDriver, it starts with a clean profile, which in our organisation already trusts the internal CA. I'd have to add a self-signed certificate by hand otherwise. But I like the idea of signing the developer's machine name, maybe I'll look into that. – artbristol Apr 29 '13 at 13:31
  • @Artbristol - I'm trying to remember, does Firefox by default trust certificate's in the Windows Crypto API? It's reasonably easy to write automated code to create certificates and register them to the Crypto API. There is actually even a .Net Library for doing it on CodePlex (though the name eludes me at the moment unfortunately). – AJ Henderson Apr 29 '13 at 13:51
2

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.