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