跟踪模式 SSL 与 COOKIE 相比有何优势？

Question

我正在创建一个部署在 Tomcat/EE（带有 CLIENTCERT）中的 JSF 应用程序。默认情况下，jsessionid（使用 SecureRandom 生成，因此看起来很安全）设置在 URL 中，我通过更改 SessionTrackingMode 禁用了 security reasons。

现在我正在尝试找出使用的安全优势/劣势：

<tracking-mode>SSL</tracking-mode> 与 <tracking-mode>COOKIE</tracking-mode>

（考虑到安全性几乎总是会对性能和其他变量产生影响）。问题之一可能是我不知道 SSL tracking-mode 到底是做什么的。 This API documentation不是很清楚。

我应该什么时候使用其中一种？

PS：我知道这不是 Tomcat 或 JSF 特有的，但我需要给出问题的上下文

Answer 1

出于以下几个原因，我建议使用基于 cookie 的会话跟踪而不是 SSL 会话跟踪：

1. 使用 SSL 会话跟踪可以防止显式（用户启动）注销
2. 使用 SSL 会话跟踪可以防止会话因不活动超时而终止
3. 使用 SSL 会话跟踪可能会导致意外注销（由于 TLS 重新协商，这会更改 TLS 会话 ID）
4. 使用 SSL 会话跟踪将使调试、故障排除以及在必要时通常操作您自己的应用程序变得更加困难（告诉客户端清除其 cookie 比要求他们使 TLS 会话 ID 过期更容易且更简单）

FWIW，IBM WebSphere has dropped support for SSL-based session-tracking 7.0 版（大约 2008 年）。

我认为使用基于 SSL 的会话跟踪没有任何优势。

Answer 2

我想在@Christopher Schultz 的回答中添加一些细节。

• 如果您的应用程序不使用客户端证书，那么使用 cookies 可能更方便。正如克里斯托弗指出的那样，原因是会话可能无效。不过，我没有对此进行测试，这只是一个理论上的印象。
• 如果使用客户端证书，我已验证通过 SSL 连接跟踪会话完全有效。我已经这样做了一段时间，我没有发现任何问题，也没有发现意外的错误/注销，也没有发现用户必须再次登录的繁琐过程。在我看来，在某些情况下，SSL 甚至可能是一种更清洁的方式来保持 会议。请注意，开发人员可能必须保持一些安全性 使用 cookie 时的注意事项（例如 HttpOnly、cookie secure flag...）。我并不是说这是选择 SSL 的理由 跟踪，因为开发人员可能必须保持一些安全性 SSL 跟踪会话的注意事项，我只是说我是 目前不知道它们，而我知道 cookie 的。
• 如果您选择 SSL 跟踪并且您正在使用 JSF (Java EE)，例如@ViewScopeds，那么你在使用不安全的 HTTP 时会遇到问题，因为如果没有 TLS/SSL，JSF 将无法跟踪会话。因此，如果您需要具有需要跟踪会话的范围的 JSF，并且需要对您的应用程序进行 HTTP 访问，那么您应该使用 COOKIE 跟踪。另一方面，如果您总是使用 HTTPS，或者不需要，例如@ViewScoped，那么 SSL 跟踪就完全没问题了。