I’m developing a product that needs to act as a server over a local network for other client applications to connect to, under the following constraints:
- The data exchanged is very valuable, and we have no guarantee over the security of the users’ network or the machine acting as a server. Therefore any SSL certificate could potentially fall into “the wrong hands”.
- To minimise disruption to the user experience, any non-electronic means of identifying the server to the client should be limited to information that can be written on a post-it (i.e. IP address, passcode rather than exchanging key files).
Given these, our current SSL strategy is:
- Do not install any SSL certificates into any trusted stores or sign any certificates against a CA certificate – this could give a potential attacker a front-door key to all the client machines
- SSL certificates will therefore be self-signed. This offers no man in the middle protection, because we have no way of verifying the server. It does however offer eavesdropping protection to those users who have insecure networks but secure servers.
- Implement a “passcode” system over the top using Rijndael symmetric encryption, so even if the certificate is compromised there is some eaves-dropping protection (I know, many leaky buckets – but better than nothing). This passcode can be regularly regenerated with minimal interruption to the user experience of the clients.
Within these constraints, is there a more secure strategy for the client and server to communicate?
In the end we developed a system where we could generate a new SSL certificate in memory for each channel we were going to support. This cannot provide protection against Man in the Middle but does at least protect against eavesdropping (unless the third party has access to the memory of the server at time of transmission, in which case all security is moot anyway!).