HTTP 的 SSL 重新协商工作流

Question

我有一个运行 HTTP 和 HTTPS 的 HTTP 服务器，使用 Javas NIO 和 SSL 库编写。在 HTTPS 模式下，它可以使用或不使用客户端证书进行通信。但是，我想重新协商。在这里，客户端将使用 HTTPS 连接，浏览资源，然后当它们遇到高度安全的资源时，服务器会向客户端质询其证书。我遇到了一些问题，需要知道工作流程应该是什么。以下是我在 IE 9 和 Chrome 中观察到的情况。

1) 当客户端请求安全资源时，我完整响应 HTTP 请求。然后我在完成后向客户挑战他们的证书

engine.setNeedClientAuth(true);  
engine.beginHandshake();

结果是来自客户端的 TCP FIN（它关闭了其一侧的连接），并且重新协商失败。

2) 当客户端请求安全资源时，我在响应之前挑战证书。在这种情况下发生交换，两个浏览器都会弹出一个对证书的请求，但是一旦弹出提示，就会从客户端发送 TCP FIN 并终止重新协商。然后客户端发送另一个最终拥有证书的请求，有时我必须挑战两次。

所以我的问题是，应该发生什么？最初的浏览器连接应该保持打开状态，还是像这样正常终止？

注意：这里另一个非常有趣的观察是，在场景 2 中，当浏览器关闭 TCP 连接时，它会在您选择证书后重新连接。但是它不会重新发布请求，它只是坐在那里并期望服务器响应？在 NIO 术语中，它等待 OP_READ，这意味着套接字输入缓冲区上没有数据。浏览器是否期望响应终止连接的原始消息？

奇怪的是，这个工作流程绝对没有文档或规范，但对于我测试过的所有浏览器，它们似乎都遵循这个工作流程。

Answer 1

(1) 是不安全的，因此进一步讨论毫无意义。你甚至在要求提供凭据之前就已经泄露了信息。

(2) 是执行此操作的正确方法。客户端不应该关闭连接如果它被配置为允许重新协商。由于去年左右的 SSL 安全问题，暂时存在一个默认情况下不允许 SSL 重新协商的阶段。你可能会遇到这种情况。在这种情况下，您应该首先发出 HTTP 重定向，然后关闭连接以强制客户端使用新连接，并且新连接应该请求客户端证书。如何在代码中安排它取决于您。