Python 会话管理、SSL、WSGI和Cookie

我正在评估在不使用任何现成中间件的情况下实现wsgi应用到浏览器会话管理的可能性和可取性

审议中的一般做法是：

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

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

我对任何人对上述过程的想法都感兴趣。原则上，我觉得这听起来不错，但我对这类功能的经验很少。我已经为一些场景绘制了客户机、服务器和wsgi应用程序之间的交换流程，结果似乎很好，但我不满意我已经涵盖了所有的基础

你的协议怎么了

您可能需要考虑以下内容：

Alice联系您的服务器并获取SSL会话ID

S

。将向Alice发送包含

H（S）

的cookie

Bob正在侦听exchange。SSL会话ID未加密，因此他可以读取

S

Bob将会话cookie设置为

H（S）

，并与您的服务器联系。他的会话ID无法识别，但您的系统将允许他进入Alice的会话（可能也会将Alice踢出！）

然后，解决方案是使用HMAC对会话ID进行签名。但是，您最好首先使用HMAC的会话ID

---

一些细节：

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

HMAC有什么好处 会话Cookies+HMAC已被证明是加密安全的。HMAC是为验证数据而设计的。HMAC背后的逻辑是合理的，到目前为止，协议上还没有任何攻击

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

没有理由不想使用HMAC

---

SSL会话ID最多对负载平衡器有用

永远不要实现自己的加密 你永远不应该再发明密码术。密码算法已经（可能）被成千上万在这个领域有丰富经验的人审查过

每当你觉得你有更好的想法时，你可能会错过一些东西。也许你没有！但是你应该写一篇关于你的算法的论文，并让同行评议

---

遵守标准。

我认为这是一个问题，但首先我想问：在步骤2中，“会话ID未加密”是什么意思？我理解这将作为服务器和客户端之间发送的SSL信息的一部分进行加密。-此外，Bob在这种情况下不需要读取S，如果他可以窃取H（S）从Alice开始，然后启动与服务器的新SSL会话，该方案将允许他继续作为Alice会话？续…我已经提出了这个问题，但答案是“如果您的系统被破坏，bob可以窃取H（S），那么您还有其他不在此范围内的安全问题”？（即，如果有人破坏了你的系统，不管你的答案是什么），MattWarren问题1：SSL会话ID被发送到“清除”中，查看如何提取它，然后在清除中发送。问题2：我所描述的场景被称为“中间人攻击”。，唯一的要求是Bob可以窥探Alice的流量。你会明白，这比Bob能够从Alice处窃取会话密钥的要求要低（而且可能性更大）。@MattWarren继续说：如果Bob能够访问Alice的秘密信息（即，他可以直接从Alice处窃取

H（s）

），您对此无能为力。保护他们的计算机是用户的责任，保护传输和您的服务器是您的责任。例如，使用HMAC+Cookies，如果Bob能够窃取Alice的会话cookie，他将能够窃取Alice的会话。但同样，您对此无能为力。