1

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

9
  • Why are you not just using plain http? You are effectively downgrading https to http (except for passive sniffing in case of ephemeral keys). What is the threat model for your system?
    – domen
    Dec 6, 2018 at 17:16
  • Your application design seems backwards. Why not create an application that runs on the desktop, normally, and occasionally connects to your website? Otherwise, I believe most modern systems all have a localhost certificate - can you just use that one (or generate a self-signed certificate and install it to the proper store)? Dec 6, 2018 at 18:29
  • @domen Browser block mixed content.
    – AEonAX
    Dec 7, 2018 at 4:28
  • @Clockwork-Muse Users generally use the webapplication, only some operation require communication with the client application. Can you give source for localhost certificates? Self-signed certificate are generally not trusted by the browsers
    – AEonAX
    Dec 7, 2018 at 4:34
  • 2
    Side note, hilariously relevant: letsencrypt.org/docs/certificates-for-localhost Dec 7, 2018 at 5:09

2 Answers 2

6

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…

1

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.
2
  • Regarding point 1. Isnt that just a misconfiguration? Or are their genuine reasons for localhost to point to something else
    – AEonAX
    Mar 2 at 5:37
  • I don't think "misconfiguration" is the correct description of the problem. It's the slightly more extreme version of when websites were only tested for IE and if anybody used other browsers, that was their "misconfiguration" (or alternatively, programs that don't work if not installed in C:\Program Files\<NAME>). Saying any machine where that isn't true is misconfigured is presuming a "correct" configuration that just means "what I expect". There are correct ways to specify loopback (lots of them, even; the entire 127.0.0.0/8 subnet is loopback even though people usually use 127.0.0.1).
    – CBHacking
    Mar 2 at 9:55

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.