(正确)通知 TLS 服务器放弃与 clientAuth 的 TLS 会话的方法

信息安全 tls
2021-09-01 04:53:12

TLS 客户端是否有办法通知服务器它不再打算恢复其经过身份验证的会话?

例子:

客户端与提供其证书的服务器建立了经过身份验证的会话,并使用 clientAuth 密钥,然后执行所有应用程序级工作,现在希望告诉服务器类似:

不再需要保留我经过身份验证的会话;下次你会在客户端看到这个 sessionID 你好 - 不要恢复会话,因为我已经完成了我的工作

有没有办法这么说?据我所知, close_notify 警报并不意味着这个,它只是通知连接将被关闭或未受保护的数据将通过它传输。

1个回答

TLS 客户端是否有办法通知服务器它不再打算恢复其经过身份验证的会话?

是的,通过发送具有致命严重性的警报。

来自RFC 5077

5.1。使会话无效

TLS 规范要求发生错误时使 TLS 会话无效。

这是对RFC 5246中以下文本的明显引用* (强调我的):

7.2. 警报协议

TLS 记录层支持的内容类型之一是警报类型。警报消息传达消息的严重性(警告或致命)和警报描述。 具有致命级别的警报消息会导致连接立即终止。在这种情况下,该会话对应的其他连接可能会继续,但会话标识符必须失效,以防止失败的会话被用于建立新的连接。

实际上,选择使用致命警报而不是使用警告 close_notify 警报来终止 SSL 会话可能不会导致比服务器上的日志条目更糟糕的任何事情。因为在数据交换结束之前您不会关闭,因此致命警报不太可能会影响到它。这相当于用 RST 而不是 FIN 终止 TCP 连接。

(我认为你实际上可以发送一个带有致命严重性而不是警告严重性的 close_notify 警报,但我想先在网络上测试它)。

当然,如果您对客户端有足够的控制权来影响它关闭会话的方式,那么您就有足够的控制权在后续连接中不发送先前的会话 ID,这将实现相同的目标。除非客户端首先提出该会话 ID,否则服务器将永远不会尝试恢复会话。但是,如果您担心第三方会以某种方式获取并重新使用您的 Session ID,那么触发服务器清除它可能是合理的。


* 当我说 5077(2008 年 1 月)引用 5246(2008 年 8 月)时,它实际上是在引用 TLS 规范的早期版本;我只是拖出最新的规范供您查看。事实上,“7.2 警报协议”的语言等同于TLS 1.1 (RFC 4346)TLS 1.0 (RFC 2246)