Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer
    
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. –  Evan Anderson Dec 1 '09 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. –  Michael Graff Dec 1 '09 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. –  Evan Anderson Dec 1 '09 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. –  Michael Graff Dec 1 '09 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.

share|improve this answer

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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