【问题标题】:Secure Communication in Java - Serialized CipherText-Objects vs. Transport-Layer-Encryption vs. RMI over SSLJava 中的安全通信 - 序列化密文对象与传输层加密与基于 SSL 的 RMI
【发布时间】:2011-08-16 02:29:40
【问题描述】:

我想在两个 JAVA 服务器之间实现加密通信,两者都在我的控制之下。我想到了三种架构,希望得到您的意见,了解它们的优缺点。

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

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

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

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

您如何评价这三种架构?我是否错过了更好的实现方式?主要目标是确保安全的加密通信,但生成的源代码的复杂性、性能问题等当然也是一个问题。

【问题讨论】:

  • 如果允许啦啦队,那么我同意你关于#3 的结论。

标签: java security encryption ssl rmi


【解决方案1】:

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

其次,安全解决方案通常不是排他性的。您可以同时实现所有 3 种解决方案(通过 VPN 进行 RMI-SSL 调用与加密参数的通信)。问题在于实施成本和开销。

现在到手头的问题:

1) 我不喜欢它,因为:

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

2 和 3) 或多或少是等价的。但是,使用 2,您必须确保您的服务器只接受来自 OpenVPN 的连接,而不接受来自其他 NI 的连接。我不太了解基于 SSL 的 RMI,但如果它没有任何隐藏漏洞,它看起来还可以。

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

【讨论】:

    【解决方案2】:

    架构 4:基于 SSL 的标准套接字 I/O。

    【讨论】:

      猜你喜欢
      • 2015-01-06
      • 2011-07-17
      • 1970-01-01
      • 1970-01-01
      • 2015-07-17
      • 2010-09-17
      • 2010-10-30
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多