security - SSL session 持久性和安全 cookie

Question

我目前有一个在我的企业中运行的自己开发的应用程序安全服务，并且在很大程度上满足了业务需求。

我目前面临的问题是，该服务传统上(天真地)依赖于用户的源 IP 保持不变，作为对冲 session 劫持的对冲——企业中的 Web 应用程序不能直接对公众开放，它在过去，我完全可以接受要求用户的地址在整个给定 session 中保持不变。

不幸的是，情况已不再如此，因此我被迫切换到不依赖源 IP 的解决方案。我更愿意实现一个真正实现原始设计者意图的解决方案(即防止 session 劫持)。

到目前为止，我的研究已经出现 this ，它实际上是说“用 SSL session key 加盐您的身份验证 token 散列。”

从表面上看，这似乎是一个完美的解决方案，但我一直怀疑这个方案在现实世界中的实现是不切实际的，因为客户端和服务器可能随时 - 有效地任意- 选择重新协商 SSL session 并因此更改 key 。

这是我设想的场景:

1. 建立 SSL session 并商定 key 。
2. 客户端在应用程序级别向服务器进行身份验证(即通过用户名和密码)。
3. 服务器写入包含 SSL session key 的安全 cookie。
4. 某些事情 发生导致 session 重新协商。例如，我认为 IE 在计时器上这样做是有原因的或没有原因的。
5. 客户端向包含旧 session key 的服务器提交请求(因为没有重新协商的应用程序级别知识，所以没有机会将新的、更新的哈希写入到客户)。
6. 由于散列匹配失败等原因，服务器拒绝客户端的凭据。

这是一个真正的问题，还是由于(至少可以说)对 SSL 工作原理的理解不够完美而造成的误解？

Answer 1

查看与 SSL persistence 相关的所有主题。这是负载均衡器领域中经过深入研究的问题。

简短的回答是:您不能依赖 SSLID——大多数浏览器会重新协商，您仍然必须使用源 IP。如果 IP 地址可能会在 session 中更改，那么您可以强制进行软重新身份验证，或者使用 SSLID 作为两个 IP 更改之间的桥梁(反之亦然，即只有在两者 IP 地址和 SSLID 同时更改，如服务器所见。)

2014 年更新

只需强制使用 https 并确保您不会受到 session fixation 或 CRIME 的攻击。不要费心用任何客户端信息来添加您的身份验证 token ，因为如果攻击者能够获得 token (前提是所述 token 不仅仅是简单的猜测)然后使用任何手段来获取它(例如 cross-site scripting ，或完全破坏客户端系统)还将允许攻击者轻松获取可能已进入 token 的任何客户端信息(并在需要时在辅助系统上复制这些信息)。

如果客户端很可能只从几个系统连接，那么你可以为客户端连接的每个新客户端系统设置 generate an RSA keypair in the browser(公共(public)部分提交到你的服务器，私有(private)部分保留在希望的位置) 保护 客户端存储)并重定向到使用 two-way (peer/client certificate) verification 代替基于密码的身份验证的虚拟主机。