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?
[Update]
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:
(delta-time)
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
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.
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
Googlers, just disable the OCSP setting: