Does distributing an SSL certificate and private key pose a security risk?

Question

I found some applications bundle an SSL certificate and associated private key signed by a public CA for a domain name pointing to 127.0.0.1, probably to bypass the certificate/mixed content warning on their local server. Example

I also found services like https://get.localhost.direct/ that provide a certificate for *.localhost.direct, which points to 127.0.0.1.

Aside from violating the certificate subscriber agreement (which usually requires private keys to be kept confidential), does publicly distributing certificates and their related private key pose security risks other than the attacker being able to spoof the domain name?

Answer 1

It's not a practical risk.

By distributing the private key, they obviously violate the core principle of never distributing private keys. The fact that you as end user can get access to the private key also means that any attacker gain access to it. It's very much possible that the private key is already actively being distributed online.

Therefore, there is a certain risk of Man-in-the-Middle attacks. However, the connections will only ever be made locally. Sites, such as localhost.direct don't resolve to 127.0.0.1, but rather instruct you to add it to your hosts file. Therefore, the chance of an attacker being able to actually get into a Man-in-the-Middle position is very miniscule.

In short: It looks worse than it is and any scenario, in which this can be exploited, is very unlikely to occur naturally.

Answer 2

Yes, this is dangerous (and, frankly, stupid).

Obviously, this is catastrophically unsafe if the app contains a CA certificate with the private key. That would give the attacker complete TLS spoofing capability on any client which trust the CA cert.

If the cert is only for a specific domain, that's less disastrous but still dangerous. At attacker can only hit that specific domain - probably just one app that uses it - but this could potentially be very bad anyhow. Depending on what permissions the app has, and how the domain is used, the attacker might be able to gain control of the app and execute arbitrary code as the user.

Even for an app that is intended to only connect over loopback, there's two threats.

• Over the network: If the app doesn't modify the HOSTS file (no, telling the user to do it for you doesn't count; software shouldn't introduce a massive security hole and then tell you to go edit a weird file to fix it), then the name lookup will fall back to DNS, which is (usually) trivial to spoof.
• Local attacker: Even if the app successfully ensures that only loopback addresses will be used, using a publicly-known private key means an unprivileged attacker on the same machine could potentially spoof the server (or client, for that matter) to attack a different user (potentially with greater privileges, certainly with different ones). There are ways that the app might detect such tampering (for example, trying to start the server first, and not continuing if it can't bind the port) but there are ways that an attacker might bypass that (for example, finding a message that crashes the server, and sending it as soon as the server starts, then starting their own in its place). People tend to forget about local EoP attacks, but they shouldn't; even if you're the only human user of your machine, local EoP can be used to break out of sandboxes for untrustworthy or high-risk apps (browsers, store apps, etc.).

---

The thing is, there's just never any good reason to do this. For most inter-process communication, you should use almost anything except network sockets, TLS-protected or not. Named pipes, mapped memory, local (Unix domain) sockets, any of the many platform-specific options... there's no lack of choices that are faster, more reliable, more capable, AND more secure.

The only exception is if you're using a webview in a local app for some reason, and need to point it at an HTTPS server specifically. In that case, you should do the same thing that you should do any time you need to trust a local TLS server: generate a CA cert + private key locally, install the CA cert locally (typically only for the current user!), and then generate a private key + certificate signed by your locally-generated CA's private key. This doesn't even require elevated privileges (unlike modifying the HOSTS file), no two installs will use the same private key, no other users on the machine have access to either private key (indeed, once the CA key is used to sign the domain-specific cert, it can be deleted entirely), and you aren't at any risk of your CA revoking your certificate for flagrant misuse of its private key!