I want to implement encrypted communication between two JAVA servers, both are under my control. There are three architectures I have in mind and want to get your input on the pros and cons of them.
Architecture 1: Whenever I invoke a remote method, I do not pass the parameters as plain text but as a serialized CipherText-Object. I will use the ESAPI-library for this, but the actual implementation does not matter. What's important is that the CipherText-Object contains arbitrary Data encrypted with a symmetric key including an MAC for authentication. The symmetric key is available as a pre-shared secret on both servers.
Architecture 2: I don't care about the encryption on application level but delegate it to the transport layer. This could be a VPN-Tunnel or some sort of server-to-server encryption that is supported. I don't have too much information about what is available on modern application server at the moment. Input on this is welcome as well.
Architecture 3: Using javax.rmi.ssl to use RMI over SSL.
It feels like architecture 1 is complicated and a pain to implement. Architecture 2 leaves the encryption to the application server. As an application developer I have no control over the configuration these features. That's bad because I want to ensure that the application cannot be used without proper encryption. Architecture 3 seems to be the best way but I have no experience with this technology.
How would you rate those three architectures? Did I miss an even better way to implement this? The main goal is to ensure secure encrypted communication, but the complexity of the resulting source code, performance issues and the like are of course a concern as well.
First of all, security solutions are not one-size-fits-all. You must evaluate threats(who would be interested in snoping/attacking), risks (what would you lose if an attacker succeeded) and cost of implementation and use.
Second, the security solutions usually are not exclusive. You could implement all 3 solutions at the same time (communication over VPN of RMI-SSL calls with encripted parameters). The issue would be cost of implementation and overhead.
Now to the question at hand:
1) I do not like it, because:
2 and 3) are more or less equivalent. With 2, though, you have to get sure that your servers only accept connections coming through the OpenVPN, and not from other NI. I do not know RMI over SSL well, but if it has not any hidden vulnerability it looks OK.
IMHO, I would go for 3 (standard, integrated in the server and more flexible). 2 is a good option too, easier to implement but requires you have a better control of the server. 1 is reinventing the wheel where there are already valid options, I would discard it.