使用 wireshark，我发现 Firefox v3.0 每次在建立 SSL 会话时在“客户端密钥交换、更改密码规范”阶段之前都会卡住。
具体来说，Firefox 发送“客户端密钥交换”请求需要 0.8~1.8 秒。由于我们的应用程序仅支持 HTTPS，因此这是不可接受的。
我在 IE6 和 IE8 上测试过，都运行良好。有什么线索吗？
[更新]
最后，我通过在Wireshark中显示所有捕获的数据包找到了卡住1~2秒的原因。在“server hello”阶段之后，Firefox会向ocsp.verisign.com发出请求，并对该域进行额外的DNS查找。Firefox必须等待OCSP的撤销状态才能进入SSL的下一阶段。取决于DNS缓存是否有效，此过程需要1~2秒。
一个有趣的观察是，包含“客户端密钥交换”的 IP 数据包具有可能性很高丢失，因此需要进行 TCP 重传。发生这种情况时，该过程最多可能需要 3 秒钟。我不确定这是巧合还是错误。无论如何，这是 Wireshark 的结果：
（时间增量）
0.369296 源 IP 目标 IP TCP [ACK] Seq=161 Ack=2741 Win=65340 Len=0
2.538835 src-ip dst-ip TLSv1 客户端密钥交换，更改密码规范，已完成
2.987034 源 IP 目标 IP TLSv1【TCP重传】客户端密钥交换，更改密码规范，已完成
Firefox 和 IE 的区别在于：Firefox 3 启用了 OCSP 检查默认情况下而 IE 只支持它。所以 IE6 和 IE8 都没有问题。这确实是“证书撤销”问题。谢谢
答案1
IE 是否已配置为检查已撤销的证书？与 Firefox 是否在同一个位置？您可以尝试禁用两者，看看是否能解决问题吗？
如果是这样，那么“证书撤销”位置已关闭或 DNS 出现问题。
答案2
这只是一种预感，因为我不熟悉 Firefox 的源代码。
您描述的 SSL 握手中的点是 Firefox 的 SSL 实现必须运行一些“繁重”数学运算（生成加密安全随机数、非对称密钥加密）的地方。我想知道您是否在那时看到客户端的 CPU 使用率很高。
我认为 IE 在相同硬件上可能会更快，因为它使用加密 API（Windows CryptoAPI），与 Firefox 相比，它更适合利用硬件加密加速，而我相信 Firefox 使用其自己的加密实现。
答案3
问题出在 OCSP 而不是 CRL 上。Firefox 默认检查 OCSP和CRL 确定证书的有效性。IE 支持 OCSP，但默认情况下只检查 CRL。您可以通过 about:config 页面禁用 Firefox 中的 OCSP。这样做完全消除了我在 SSL 页面上 20-30 秒的等待时间。同样的问题也存在于 OS X 和 Linux 中，并且（根据我的测试）与硬件或加密 API 无关。
有关 OCSP 的更多信息，请访问http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
答案4
Google 员工，只需禁用 OCSP 设置：
