Risks of deploying a server authentication certificate along with a client application

Question

What are the risks of deploying a client application with server authentication certificate (private + public key) so that a client application can host a webserver. Which is accessible via HOSTS redirect through the browsers.

What are the risks with the following approach?

Assume

1. I own the "example.com" domain.
2. I get a valid server authentication certificate for "app.example.com", say for e.g. from Comodo.
3. I have a web application hosted at "https://www.example.com".
4. Users are supposed to do some action which requires me to send some requests to an application running on their system and get a response.
5. I do this by installing a client application on user's system.
6. This application has the server authentication certificate for "app.example.com" issued above. It can host a locally accessible web server.
7. During installation, I add an entry to C:\Windows\System32\drivers\etc\hosts for a redirect from "app.example.com" to "127.0.0.1"
8. When user is using the Web application at "https://www.example.com" it also connects to "https://app.example.com" which is actually the client application running on users system.
9. Browser can send requests to an application running on their system and get a response.

Things I would like to know: Risks, Fixes, Alternative Approaches etc.

Update: Additional Question: Certificates for localhost, MITM Attack

I preparing a list for why not to do this as asked in the question. As well as for my understanding.

Update: 3 Years down the line Localhost is now recognized as secure context. You no longer require SSL certificate for the same. https://w3c.github.io/webappsec-secure-contexts/#localhost

Answer 1

You are publishing a certificate for https://app.example.com along your app. Thus this private key is no longer "private". Someone will find out and publish it. This will lead to the CA revoking your certificate for app.example.com (they MUST revoke it). This has happened in the past, you are not the first one to have such idea, companies like Cisco, Blizzard, EA, Spotify, mega… used to do this.

This is more a procedural issue, but it will bite you quite quickly (do remember that the CA have 24h to revoke it once they are made aware that the certificate is compromised).

A MITM could extract the certificate from your app and impersonate app.example.com on someone which don't have the hosts entry, but it isn't worth listing the risks with that given that your approach won't work for too long.

If you really need to use a certificate for https://app.example.com, create a certificate locally (so that each client have a different certificate), properly constrained, and add it to the client certificate store.

Plus, obviously, the server running in the client shouldn't do silly things such as allowing launching arbitrary programs, or exfiltrating client files. That local server is a security boundary, so it shall be very careful validating any input…

Answer 2

Definitely better to generate and install a certificate (and private key) than to use a published one.

However, whether or not you use a certificate at all, and definitely without using a published "private" key, there's still problems with this idea.

1. Don't use "localhost". It's merely convention that this points to the loopback address; I've seen machines where it wasn't configured to do so and thus caused a DNS request, the response to which could be spoofed (we encountered this because, yes, we were trying to do something similar to you. Don't be like we were). Using actual loopback IP addresses avoids that problem.
2. This isn't safe for multi-user machines. An attacker can either spin up their own server on the expected port, or connect to the legit server as though they're the legit browser or whatever. While machines with multiple mutually-untrusted users are relatively rare today, they still exist, and breaking the inter-user security boundary is bad for other reasons too (e.g. it could make it much easier for an exploit in sandboxed code or a low-privilege service account to elevate privileges). If at all possible, use secure IPC channels (or just use a single thick client, rather than a browser + a server). You might be able to solve this with authentication, but it would need to be authentication that the server and client (browser?) both know, but that an attacker can't know.
3. If you're not using HTTPS, then you risk interception of the traffic. While the loopback interface is obviously safer than talking to a remote host, it's not perfectly safe; an attacker might have access to a poorly-secured network tap or similar. In theory this applies to all IPC channels, but in practice network taps are far more common than other sorts, and it's fairly common to install them with relatively weak security so people can e.g. run Wireshark as a standard user.