跟踪模式 SSL 与 COOKIE 相比有何优势？
What are the advantages of tracking-mode SSL vs. COOKIE?
我正在创建部署在 Tomcat/EE 中的 JSF 应用程序（使用 CLIENTCERT）。默认情况下，jsessionid（使用 SecureRandom, so it looks safe) was set in the URL, which I disabled for security reasons by changing the SessionTrackingMode.
生成
现在我正试图找到使用 advantages/disadvantages 的安全性：
<tracking-mode>SSL</tracking-mode> 对比 <tracking-mode>COOKIE</tracking-mode>
（考虑到安全性几乎总是会对性能和其他变量产生影响）。可能的问题之一是我不知道 SSL 跟踪模式到底是做什么的。 This API documentation不是很清楚
我什么时候应该使用其中之一？
PS：我知道这不是 Tomcat 或 JSF 特有的，但我需要为问题提供上下文
出于以下几个原因，我建议使用 cookie-based session-tracking 而不是 SSL session-tracking：
- 使用 SSL session-tracking 可能会阻止显式 (user-initiated) 注销
- 使用 SSL session-tracking 可能会阻止会话因 inactivity-timeouts
而终止
- 使用 SSL session-tracking 可能会导致意外注销（由于 TLS 重新协商，这会更改 TLS session-id）
- 使用 SSL session-tracking 将使调试、故障排除以及在必要时通常操纵您自己的应用程序变得更加困难（告诉客户清除他们的 cookie 比要求他们使他们的 TLS 过期更容易和更神秘 session-ids)
FWIW，IBM WebSphere has dropped support for SSL-based session-tracking 7.0 版（大约 2008 年）。
我看不出使用 SSL-based session-tracking 有什么好处。
我想在@Christopher Schultz 的回答中添加一些细节。
- 如果您的应用程序不使用客户端证书，那么使用cookies可能更方便。正如克里斯托弗指出的那样，原因是 sessions 可能失效。不过，我还没有测试过，这只是理论上的印象。
- 如果使用客户端证书，我已验证通过 SSL 连接跟踪 sessions 完全有效。我这样做已经有一段时间了，我没有发现任何问题，也没有意外 error/logout，也没有让用户不得不重新登录的繁琐过程。在我看来，在某些情况下，SSL 甚至可能是一种更简洁的方式来保持
session秒。请注意，开发人员可能必须保持一定的安全性
使用 cookie 时的注意事项（例如 HttpOnly、cookie secure
标志...)。我并不是说这是选择 SSL 的理由
跟踪，因为开发人员可能必须保持一定的安全性
SSL 的注意事项也跟踪 sessions，我只是说我是
目前不知道它们，而我知道 cookie 的。
- 如果您选择 SSL 跟踪并且您使用的是 JSF (Java EE)，例如
@ViewScopeds，那么在使用不安全的 HTTP 时就会遇到问题，因为如果没有 TLS/SSL，JSF 将无法跟踪 session。因此，如果您需要具有需要跟踪 session 范围的 JSF，并且需要对您的应用程序进行 HTTP 访问，那么您应该进行 COOKIE 跟踪。另一方面，如果您总是使用 HTTPS，或者不需要，例如@ViewScoped，那么 SSL 跟踪就完全没问题了。
我正在创建部署在 Tomcat/EE 中的 JSF 应用程序（使用 CLIENTCERT）。默认情况下，jsessionid（使用 SecureRandom, so it looks safe) was set in the URL, which I disabled for security reasons by changing the SessionTrackingMode.
现在我正试图找到使用 advantages/disadvantages 的安全性：
<tracking-mode>SSL</tracking-mode> 对比 <tracking-mode>COOKIE</tracking-mode>
（考虑到安全性几乎总是会对性能和其他变量产生影响）。可能的问题之一是我不知道 SSL 跟踪模式到底是做什么的。 This API documentation不是很清楚
我什么时候应该使用其中之一？
PS：我知道这不是 Tomcat 或 JSF 特有的，但我需要为问题提供上下文
出于以下几个原因，我建议使用 cookie-based session-tracking 而不是 SSL session-tracking：
- 使用 SSL session-tracking 可能会阻止显式 (user-initiated) 注销
- 使用 SSL session-tracking 可能会阻止会话因 inactivity-timeouts 而终止
- 使用 SSL session-tracking 可能会导致意外注销（由于 TLS 重新协商，这会更改 TLS session-id）
- 使用 SSL session-tracking 将使调试、故障排除以及在必要时通常操纵您自己的应用程序变得更加困难（告诉客户清除他们的 cookie 比要求他们使他们的 TLS 过期更容易和更神秘 session-ids)
FWIW，IBM WebSphere has dropped support for SSL-based session-tracking 7.0 版（大约 2008 年）。
我看不出使用 SSL-based session-tracking 有什么好处。
我想在@Christopher Schultz 的回答中添加一些细节。
- 如果您的应用程序不使用客户端证书，那么使用cookies可能更方便。正如克里斯托弗指出的那样，原因是 sessions 可能失效。不过，我还没有测试过，这只是理论上的印象。
- 如果使用客户端证书，我已验证通过 SSL 连接跟踪 sessions 完全有效。我这样做已经有一段时间了，我没有发现任何问题，也没有意外 error/logout，也没有让用户不得不重新登录的繁琐过程。在我看来，在某些情况下，SSL 甚至可能是一种更简洁的方式来保持 session秒。请注意，开发人员可能必须保持一定的安全性 使用 cookie 时的注意事项（例如 HttpOnly、cookie secure 标志...)。我并不是说这是选择 SSL 的理由 跟踪，因为开发人员可能必须保持一定的安全性 SSL 的注意事项也跟踪 sessions，我只是说我是 目前不知道它们，而我知道 cookie 的。
- 如果您选择 SSL 跟踪并且您使用的是 JSF (Java EE)，例如
@ViewScopeds，那么在使用不安全的 HTTP 时就会遇到问题，因为如果没有 TLS/SSL，JSF 将无法跟踪 session。因此，如果您需要具有需要跟踪 session 范围的 JSF，并且需要对您的应用程序进行 HTTP 访问，那么您应该进行 COOKIE 跟踪。另一方面，如果您总是使用 HTTPS，或者不需要，例如@ViewScoped，那么 SSL 跟踪就完全没问题了。