Java中的安全通信 - 序列化CipherText-对象与传输层加密与SSL上的RMI

Question

我想在两台JAVA服务器之间实现加密通信，两者都在我的控制之下。我有三种架构，想要了解它们的优缺点。

架构1： 每当我调用远程方法时，我都不会将参数作为纯文本传递，而是作为序列化的CipherText-Object传递。我将使用ESAPI库，但实际的实现并不重要。重要的是CipherText-Object包含使用对称密钥加密的任意数据，包括用于身份验证的MAC。对称密钥可作为两个服务器上的预共享密钥使用。

架构2： 我不关心应用程序级别的加密，而是将其委托给传输层。这可能是VPN-Tunnel或支持的某种服务器到服务器加密。我目前没有太多关于现代应用服务器上可用内容的信息。对此的投入也很受欢迎。

架构3： 使用javax.rmi.ssl通过SSL使用RMI。

感觉架构1很复杂，实施起来很痛苦。架构2将加密保留给应用程序服务器。作为应用程序开发人员，我无法控制这些功能的配置。这很糟糕，因为我想确保在没有适当加密的情况下无法使用该应用程序。架构3似乎是最好的方式，但我对此技术没有经验。

您如何评价这三种架构？我是否错过了更好的实施方法？主要目标是确保安全的加密通信，但结果源代码的复杂性，性能问题等当然也是一个问题。

Answer 1

首先，安全解决方案并非一刀切。您必须评估威胁（谁会对攻击/攻击感兴趣），风险（如果攻击者成功将会失去什么）以及实施和使用的成本。

其次，安全解决方案通常不是排他性的。您可以同时实现所有3个解决方案（通过带有编写参数的RMI-SSL调用的VPN通信）。问题在于实施成本和开销。

现在提出问题：

1）我不喜欢它，因为：

• 即使他不知道传递了哪些数据，它也允许某个人知道调用了哪些方法。
• 据我所知，MAC可以被欺骗
• 您必须现在和将来控制您的服务器，以便不会发现共享密钥。也许下个月你的一台服务器被带到另一个位置/分支/部门，更多人开始访问它。或者他们可能会在不改变秘密的情况下将您的服务器部署在另一个商店中。

2和3）或多或少相同。但是，对于2，您必须确保您的服务器仅接受来自OpenVPN的连接，而不是来自其他NI的连接。我不太清楚SSL上的RMI，但如果它没有任何隐藏的漏洞，它看起来还不错。

恕我直言，我会选择3（标准，集成在服务器中，更灵活）。 2也是一个不错的选择，更容易实现，但需要您更好地控制服务器。 1是重新发明已经有效选项的轮子，我会丢弃它。

Answer 2

架构4：SSL上的标准套接字I / O.