2

Context of Problem

I am writing a piece of middleware. The middleware runs on a client machine. It downloads material from a server (using normal SSL), decrypts the material using a private key on the client machine, and provides a standard interface for third-party applications to access. The third-party applications expect an SSL certificate, even when they are configured to connect my middleware on localhost. I don't want my users to have to click through security exceptions, and these days not all applications even allow for security exceptions to be made.

Therefore, after installation my application needs to support an SSL connection without the user having to fight against a self-signed certificate, but obviously without opening the user to MITM attacks.

Proposed Solution

This is the best plan I have right now for the client installation process:

  1. Generate a CA locally
  2. Generate a certificate locally for domain localhost
  3. Use the CA to sign the certificate
  4. delete the .key file from the CA so it can never be re-used
  5. install the CA .cert file to the system's trusted CA list

Question

  • Are there security holes in this plan?
  • Is this strategy in use anywhere else?
  • Is there a better way to approach the problem?

Clarification

Let me be really clear, the server does have an SSL certificate. When the middleware talks to the server, it uses SSL. That is not in question. It is the connection between the 3rd party client and the middleware (which are both on the client machine) that is in question.

What needs to work: I need 3rd party clients to connect to my middleware as if it were a remote server in a seamless fasion. If the 3rd party client were a browser, it would look like a little green lock icon next to the https. The user should not to have to accept security exceptions. Some 3rd party clients will not allow security exceptions at all, resulting in outright rejection of self-signed certificates. That is obviously obnoxious for my users.

What I am trying to protect against: I do not want to add a CA to the client machine that allows anyone who gains access to the machine to execute MITM attacks. That is why I would be deleting the CA .key file as soon as the localhost certificate was signed. Theoretically, a MITM attack could be launched with just the generated localhost certificate, but only against localhost connections, and not against www.mybank.com.

What I do not see as a threat: Anyone who has access to the client machine will already have access to everything passed between the 3rd party client and the middleware, as most 3rd party clients don't encrypt the materials they recieve from the middleware. Therefore I don't see the security of the generated localhost certificate as being particularly relevant.

2

The question you need to clarify is what you're trying to protect against. Your solution is fine if all you need is the little green lock icon in the browser, but it gets significantly more complicated as you start requiring more.

For instance, are you trying to protect the application from attack (what attacks?), or are you trying to protect the user from an attacker reusing the localhost certificate for other reasons?

In any case, an attacker on the machine can get access to the raw private key of the localhost certificate, or access to use the private key, regardless of the state of the CA.

This can be made more difficult by running the service as a separate service account, and locking the key to that user, but any administrator on the machine can bypass this. You can then mitigate this further by making sure the human users aren't running as admin (this naturally turns out to be the hard part).

  • I went ahead and edited in some clarity about what I am I trying to protect against and what I am not concerned about. Honestly though, part of the reason I am asking here is because I don't trust myself to think through all possible vulnerabilities on my own. – rexroni Oct 5 '17 at 18:24
0

It depends on your relationship to the the people who will be consuming the service you are designing. What you describe means that you can't revoke the issued certificate. How would you (or someone else) go about removing the trust for the certificate?

Is there a better way to approach the problem?

Go buy a certificate from an existing public certificate authority (or get a free one from let's encrypt).

  • I think you may have misunderstood my problem. I added a clarification to my question statement. Because it is a localhost-to-localhost connection on the client machine in question, it is impossible for my server's SSL certificate to be used, as I would have to compromise my key to every client. With regards to revoking, the local CA would be removed by the uninstaller, and since it can never be used to sign another key it isn't clear to me that there would be a need to revoke it by other means. – rexroni Oct 5 '17 at 13:02
  • You're right, I don't understand, but I'm even more confused now - "Because it is a localhost-to-localhost connection" - if that's exclusively the access model, then it removes the revocation issue. But why does that stop you using a cert supplied by a third party? – symcbean Oct 5 '17 at 16:43
  • You mean that every installation of the middleware would have its own SSL key signed by a real CA? Because doesn't the server side of an SSL connection (in this case the middleware on localhost) have to have the key to the cert that it uses? So it can't be my server's key. And if the middleware on every client machine needs its own key, each signed by a real CA, then every client needs to own a unique domain name, because that is part of what is necessary get a key signed by a CA. That seems like a completely unreasonable requirement for my users. – rexroni Oct 5 '17 at 18:27
  • 1
    I'm getting even more confused. Your suggestion of creating a certificate for the hostname "localhost" is dangerous. You can use the loopback interface with any name you choose - but use something other than localhost for ssl connections. – symcbean Oct 5 '17 at 18:36
  • What are you more confused about? And why is it dangerous? If I am planning it wrong, that is exactly the sort of thing I need to know. – rexroni Oct 5 '17 at 19:06

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.