Using wireshark, I discovered that Firefox v3.0 gets stuck every time before "client key exchange, change cipher spec" stage when establishing a SSL session.

Specifically, it takes 0.8~1.8 second before Firefox send "Client Key Exchange" request. This is unacceptable since our application is HTTPS only.

I tested this on IE6 and IE8, both works well. Any clues?


Finally, I found the reason of 1 ~ 2 seconds stuck by displaying all captured packets in Wireshark. After the "server hello" stage, Firefox makes a request to ocsp.verisign.com combined with an additional DNS lookup for that domain. Firefox must wait the revocation status from OCSP before entering the next stage of SSL. Depends on whether DNS cache is in effect, this process takes 1 ~ 2 seconds.

A interesting observation is that the IP packet contains "client key exchange" has a high possibility to get lost and thus a TCP retransmission is necessary. When this happens, the process can take 3 seconds at worst. I'm not sure if this is a coincidence or a bug. Anyway, here is the result from Wireshark:


0.369296 src-ip dst-ip TCP [ACK] Seq=161 Ack=2741 Win=65340 Len=0

2.538835 src-ip dst-ip TLSv1 Client Key Exchange, Change Cipher Spec, Finished

2.987034 src-ip dst-ip TLSv1 [TCP Retransmission] Client Key Exchange, Change Cipher Spec, Finished

The difference between Firefox and IE is this: Firefox 3 enables OCSP checking by default where as IE only supports it. So, there is no problem with both IE6 and IE8. This is indeed a "certificate revoke" problem. Thanks

3 Answers 3


Is IE configured to check for revoked certs? In the same place as Firefox? Can you try disabling both and see if that fixes it?

If so, either the "certificate revoke" location is down or DNS is having problems.

  • I was dubious of certificate revocation list (CRL) checking being the culprit because the poster was watching the conversation with Wireshark and, presumably, not seeing any CRL checking-related traffic. I suppose they could be heavily filtering their capture, though, and might not be seeing that. Dec 1, 2009 at 16:14
  • Yea, same here, but I can't imagine what else would be causing this issue. Firefox doesn't do anything unusual in the code that I've seen, but I last looked 4 years ago. Still, I don't think this is somewhere major changes have occurred. Dec 1, 2009 at 16:16
  • All I could come up with was a radically slower code-path for Firefox SSL setup than for IE SSL setup, and that's a poorly-aimed shot in the dark. Dec 1, 2009 at 16:20
  • If that's the case, it would have been seen more globally, and global slowness like this would have been fixed if only to compete in numbers. Dec 1, 2009 at 16:22

This is all just a hunch, because I'm not familiar with the source for Firefox.

The point in the SSL handshake that you're describing is where Firefox's SSL implementation has to run some of the "heavy lifting" math (generating cryptographically secure random numbers, assymetric-key crypto). I wonder if you're seeing high CPU usage on the client in that time.

I would suspect that IE could be faster, on the same hardware, because its using an crypto API (the Windows CryptoAPI) that is much more apt to take advantage of hardware crypto acceleration than Firefox, which I believe uses its own crypto implementation.


The problem is with OCSP not CRL's. Firefox, by default, checks OCSP and CRL's to determine a certificate's validity. IE supports OCSP but, by default, only checks CRL's. You may disable OCSP in Firefox through the about:config page. Doing so has completely eliminated the 20-30 second wait times for me on SSL pages. This same problem exists in OS X and Linux and is not related (according to my testing) to hardware or crypto API's.

More on OCSP at http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.