JSON RPC over TLS 是不是足够安全？

Posted 2023-02-16

【中文标题】JSON RPC over TLS 是不是足够安全？

【英文标题】：Is JSON RPC over TLS secure enough?JSON RPC over TLS 是否足够安全？

【发布时间】：2012-12-28 12:27:57

【问题描述】：

我打算让 php Web 服务接受 JSON-RPC over TLS (HTTPS)。每个客户端都有一个 API 密钥，我将用于识别目的。是否足够安全，是否有 JSON-RPC 安全特定标准？

【问题讨论】：

我阅读了有关 tls 的信息，我发现它可以提供足够的安全性来防止窃听和消息的一致性，所以我在 ws 方面看到的主要是真实性（alice 是 alice，并且绝对不是 bob）

【参考方案1】：

这是一种很好的做事方式。下面概述了您的安全方案中的要求和组件：

清单

以下是需要哪些安全措施以及如何解决的清单：

第三方无法窃听您的通信。 HTTPS 提供了这一点。 第三方无法篡改您的通信。 HTTPS 也提供了这一点。 客户端可以验证服务器。 HTTPS 提供此功能 (*)。 服务器可以对客户端进行身份验证。

客户端认证

有很多方法可以验证客户端。以下是一些例子：

使用 API 密钥计算请求的 HMAC，并将 HMAC 作为标头包含在请求中

。 (**) 最安全，但设置起来更复杂。关键优势在于，如果您的服务器遭到入侵，API 密钥将不会泄露。

在请求中包含 API 密钥本身

。设置更容易，根据您的要求可能足够安全。 ...

---

(*)：只要客户端库可以。 HTTPS 要求您使用证书来验证您的站点是否与域名相对应。不幸的是，许多 HTTPS 库默认情况下不验证这一点。 (**)：您还应该使用 nonce 来防止重放攻击。

【参考方案2】：

您可以使用秘密盐签署请求（+哈希算法，MD5 会很好），因为这样窃听者无法获取“API 密钥”并伪造他自己的请求。使用很长的盐。

盐还可以防止成功窃听者故意更改消息。

中间怎么会有人？除非您为每个客户端颁发白名单证书，否则 TLS(SSL) 对中间人攻击的安全性并不高。例如，中间的服务器（攻击者）获得了有效的证书，或者客户端应用程序没有检查各种证书的有效性设置（到期日期等）。如果不在您的控制之下，您的 RPC 服务器的客户端很可能会在不进行任何类型的安全检查的情况下进行连接。这是一个普遍的问题。 窃听通常意味着访问您（或您的客户）的网络，因此这可能意味着受毒的 DNS 流量重定向到流氓服务器。

您或您的客户端的网络连接是否足够安全以排除 DNS 中毒的可能性，或者您的客户端正在检查证书的有效性，或者您强制客户端使用列入白名单的 SSL 证书，这些只有您可以影响或决定上。

您可能还希望通过为每个请求分配一个唯一编号来防止重放攻击（如果这些 API 调用只是为了读取，则可能会过度使用）以拒绝重复请求。

您提到的 API 密钥通常在涉及浏览器端 javascript 客户端来跟踪使用情况时使用。 API 密钥在被盗时会重新颁发，以识别和禁用未经授权的应用程序（并且可能会自动列出欺诈性域名，以便采取进一步的 [诉讼] 行动）。

【讨论】：

对帖子进行编辑时要小心 - 您刚刚删除了一些更正！

如果不是密钥，什么是秘密盐？ MD5真的不适合签名。单独使用散列算法并不能防止散列扩展攻击（您应该使用 HMAC）。 HTTPS 确实可以防止 MITM，尽管许多客户端库没有实现这种安全性。

是的，许多客户端库（主要是客户端自定义代码）没有为 SSL 启用足够严格的安全性。这就是我在答案中所说的。秘密盐不是 Fabio 所指的密钥类型。 “API 密钥”通常是指客户端 ID（同样，正如我在我的帖子中解释的那样），而不是密码，当然也不意味着散列。

我的帖子探讨了 JSON RPC over TLS 是如何不安全的，因为问题是：“JSON RPC over TLS 是否足够安全”。另外，我看不出您的评论与我的回答或问题有何关联。我的回答自动否定了您的评论。

@Tiberiu-IonuțStan 我的评论旨在指出您的答案中我不同意的特定部分，希望您能澄清（例如，什么是“秘密盐”？）或更正（HMAC + SHA1 ,256）比这里的 MD5 更合适）。我不会反驳你的整个答案，我觉得总体上很好。