1

我正在审查将 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 之间的交换流程，它似乎工作得很好，但我不太舒服，因为我已经涵盖了所有的基础。

4

1 回答 1

3

你的协议有什么问题

您可能需要考虑以下事项：

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

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

一些细节：

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

HMAC 有什么好处

Session Cookies + HMAC 已被证明是加密安全的。HMAC 是为验证数据而设计的。HMAC 的逻辑是合理的，到目前为止，该协议不存在任何攻击。

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

您没有理由不想使用 HMAC。

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

永远不要实现自己的密码学

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

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

坚持标准。

于 2012-12-07T12:01:13.097 回答