我想在两个JAVA服务器之间实现加密通信，两者都在我的控制之下。我想到了三种架构，希望您能就它们的优缺点发表意见。
架构 1: 每当我调用远程方法时，我都不会将参数作为纯文本传递，而是作为序列化的 CipherText-Object 传递。我将为此使用 ESAPI 库，但实际的实现并不重要。重要的是 CipherText-Object 包含使用对称 key 加密的任意数据，包括用于身份验证的 MAC。对称 key 可作为两台服务器上的预共享 key 使用。
架构 2: 我不关心应用程序级别的加密，而是将其委托(delegate)给传输层。这可能是 VPN 隧道或某种受支持的服务器到服务器加密。目前我没有太多关于现代应用程序服务器上可用的信息。也欢迎对此提出意见。
架构 3: 使用 javax.rmi.ssl 通过 SSL 使用 RMI。
感觉架构1很复杂，实现起来很痛苦。体系结构 2 将加密留给应用程序服务器。作为应用程序开发人员，我无法控制这些功能的配置。这很糟糕，因为我想确保应用程序在没有适当加密的情况下无法使用。架构 3 似乎是最好的方式，但我没有使用该技术的经验。
您如何评价这三种架构？我错过了更好的实现方法吗？主要目标是确保安全的加密通信，但生成的源代码的复杂性、性能问题等当然也是一个问题。
最佳答案
首先，安全解决方案并不是万能的。您必须评估威胁(谁会对窥探/攻击感兴趣)、风险(如果攻击者得逞，您会损失什么)以及实现和使用的成本。
其次，安全解决方案通常不是排他性的。您可以同时实现所有 3 种解决方案(通过带有加密参数的 RMI-SSL 调用的 VPN 进行通信)。问题在于实现成本和管理费用。
现在回答手头的问题:
1) 我不喜欢它，因为:
- 它允许窃听者知道调用了哪些方法，即使他不知道传递了哪些数据。
- 据我所知，MAC 可以被欺骗
- 你现在和将来都必须控制你的服务器，这样共享的 secret 就不会被发现。也许下个月您的一台服务器被转移到另一个位置/分支机构/部门，并且更多人开始可以访问它。或者，他们可能会在不更改 secret 的情况下将您的服务器部署到另一家公司。
2 和 3) 或多或少是等价的。但是，对于 2，您必须确保您的服务器只接受来自 OpenVPN 的连接，而不接受来自其他 NI 的连接。我不太了解 SSL 上的 RMI，但如果它没有任何隐藏的漏洞，它看起来还不错。
恕我直言，我会选择 3(标准、集成在服务器中且更灵活)。 2 也是一个不错的选择，更容易实现，但需要您更好地控制服务器。 1 正在重新发明已经有有效选项的轮子，我会放弃它。
关于java - Java 中的安全通信 - 序列化密文对象与传输层加密与 SSL 上的 RMI，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5842622/