在 TLSv1.2 中，客户端能够使用 SSLSessionID 恢复。此 ID 在多个恢复的 session 中保持不变。
在我修改过的 apache Web 服务器中，我有一个逻辑，用于根据 SSLSessionID 检查 session cookie。如果同一个 cookie 的 SSLSessionID 发生变化，我会放弃该请求。
现在我如何在 TLSv1.3 中实现这一目标。 ( session 的恢复不是问题，这有效。)
问题是，SSLSessionID 对于每个请求都会更改，在恢复 session 中也是如此。
显然我的机制不再起作用，因此我需要一个在恢复的 session 中保持不变的标识符。
最佳答案
TL;DR:没有严格的等效项，因为该功能已被删除。但为了类似的需求引入了新的 session 票证。
RFC 8446在 TLS 1.3 上这样说:
2.2. Resumption and Pre-Shared Key (PSK)
[..]
In TLS 1.2 and below, this functionality was provided by "session IDs" and "session tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.
关于 ClientHello 的第 §4.1.2 节也描述了此扩展:
legacy_session_id:
Versions of TLS before TLS 1.3 supported a "session resumption" feature which has been merged with pre-shared keys in this version (see Section 2.2). A client which has a cached session ID set by a pre-TLS 1.3 server SHOULD set this field to that value. In compatibility mode (see Appendix D.4), this field MUST be non-empty, so a client not offering a pre-TLS 1.3 session MUST generate a new 32-byte value. This value need not be random but SHOULD be unpredictable to avoid implementations fixating on a specific value (also known as ossification). Otherwise, it MUST be set as a zero-length vector (i.e., a zero-valued single byte length field).
您能找到的最接近的是新的“ session 票证”，请参阅§4.6.1
但是如果你去像 https://ssl-config.mozilla.org/ 这样的东西您将看到所有配置都是在禁用 session 票证的情况下完成的。
您可以查看https://timtaubert.de/blog/2017/02/the-future-of-session-resumption/ 1.2 和 1.3 之间的变化的解释
关于apache - TLS1.3 session 的 SSLSessionID 等效项是什么，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60115179/