Java HTTP的SSL重新协商工作流

我有一个HTTP服务器，运行HTTP和HTTPS，使用JavasNIO和SSL库编写。在HTTPS模式下，它可以使用或不使用客户端证书进行通信。但是，我想进行重新谈判。在这里，客户端将使用HTTPS连接，浏览资源，然后当它们访问高度安全的资源时，服务器向客户端挑战证书。我在这方面遇到了一些问题，需要知道工作流程应该是什么。以下是我对IE 9和Chrome的观察结果

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

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

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

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

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

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

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

（1）是不安全的，因此无需进一步讨论。在你要求出示证件之前，你已经泄露了信息

---

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

初始关闭实际上是工作流的一部分，这样做是为了让浏览器可以弹出一个对话框供客户端选择SSL证书，即使是与RFC 5746兼容的协商。当客户端再次连接时，它执行正常的SSL握手，但不交换证书，服务器必须使用第二个SSL hello请求来质询证书。在这第三次协商中，交换证书。如果客户机不重新协商，这将不起作用，除非第二次连接和质询之间再次接近。