会话管理、SSL、WSGI 和 Cookie

Question

我正在审查将 wsgi-app 实施到浏览器会话管理的可能性和可取性，而不使用任何现成的中间件。

正在考虑的一般方法是：

在浏览器和服务器之间使用 SSL。 将 SSL 会话 ID 公开给 WSGI 或 OS.environment，用作会话 ID 以启用应用程序级别的持久性和身份验证。 由于如果服务器+浏览器再次握手，SSL 会话 ID 可能随时更改，因此我们的想法是使用 cookie 来保存生成的 SSL ID 的散列版本。 如果他们握手并且检测到 SSL ID 的变化（暴露给环境的 SSL 会话 ID 与客户端返回的 cookie 不匹配），则可以检查散列的 cookie 以查看它是否包含先前已知的会话 ID，如果它那么我们应该继续当前会话并将 cookie 中使用的 SSL 会话 ID（并存储在后端数据库中）更新为新生成的通过握手 SSL 会话 ID。因此，即使 SSL 会话 ID 在我们脚下发生变化，我们也能继续会话。

据我了解，这个想法是让 SSL 生成会话 ID，并做一些比仅依靠 cookie+hmac 来保存会话 ID 更安全的事情。

我会对任何人对上述过程的想法感兴趣。原则上这对我来说似乎是合理的，但我对这种功能的经验很少。我已经为一些场景绘制了客户端、服务器和 wsgi-app 之间的交换流程，看起来效果很好，但我不太满意我已经涵盖了所有基础。

Answer 1

你的协议有什么问题

您可能需要考虑以下几点：

1. Alice 联系您的服务器并获取 SSL 会话 ID S。包含H(S) 的 cookie 将发送给 Alice。
2. Bob 正在监听交流。 SSL session ID 没有加密，所以他可以读取S。
3. Bob 联系您的服务器，并将会话 cookie 设置为 H(S)。无法识别他的会话 ID，但您的系统无论如何都会让他进入 Alice 的会话（并且可能也会将 Alice 踢出去！）。

然后解决方案是使用 HMAC 对会话 ID 进行签名。但是，您不妨一开始就使用 HMAC 的会话 id。

---

一些细节：

• 要知道他应该发送的 Cookie 的名称，Bob 可以联系您的服务器。
• Bob 也可以这样做来了解您正在使用的哈希算法

HMAC 的优点

会话 Cookies + HMAC 已被证明是加密安全的。 HMAC设计是为了验证数据。 HMAC 的逻辑是合理的，截至今天，该协议不存在任何攻击。

更好的是，事实证明，对底层哈希算法的攻击并不意味着存在对 HMAC 的攻击（但这并不意味着您应该使用 MD5！）。

没有理由您不想使用 HMAC。

---

SSL 会话 ID 充其量对负载平衡器有用。

永远不要实现自己的加密技术

您永远不应该重新发明密码学。 （可能）数千名在该领域具有丰富经验的人已经审查了密码算法。

每当您觉得自己有更好的想法时，您可能错过了一些东西。也许你不知道！但是你应该写一篇关于你的算法的论文，并让它进行同行评审。

坚持标准。