460890 - If one SSL connection hangs, FF refuses to load another webpage with the same SSL certificate

Status: VERIFIED WORKSFORME

(Core Graveyard :: Security: UI, defect)

Description

[Jesse Thompson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1

I have noticed this behavior as far back as Firefox version 2, first bug filed about it. I have tested this from multiple machines running Windows XP and 2000.

If you open an HTTPS connection to a web page and the page does not complete loading.. for example if the page load takes a very long time or in some cases if you cancel the page load or a network error aborts the page load.. then firefox will no longer load any other pages via that SSL certificate. Even other pages from different domain names on a wildcard certificate, and even from a different web server that shares the certificate. Firefox will "sit and spin" trying to load any other web pages that use the same SSL cert. Web pages via different SSL certs do not appear to be adversely affected.

Other browsers I have tried including MSIE 6, 7, Opera 9.4 and Google Chrome: none of them exhibit this behavior. In fact, while FF is refusing to open https page X due to this bug, other browsers will open page X swiftly which negates the likelihood of this being in any way server related. In case it helps the web servers I have tested this against are Apache 2.0 + openssl on FreeBSD 5.4 and Debian etch, and the ssl certificate is the one which certifies https://www.webformix.com/ .. if time allows I might try to set up a server-side test case for this.

After upgrade from FF 2.0 to FF 3.0, I did notice a slight change in behavior. FF 2.0 would permanently lose it's ability to access pages via the SSL cert until the browser was restarted. FF 3.0 would only lose the ability for a short time, I estimate 15 minutes or so. After not trying to access an affected SSL site for a short interval our ability to do so returns, so it feels as though something in the browser is clearing an SSL related cache periodically. 

I confirm FF3.1b1 still experiences the main problem, I have not yet had time to see if or how long a period of inactivity restores access to affected SSL sites.

Reproducible: Always

Steps to Reproduce:
1. Access an HTTPS webpage that will take a substantially long time to download. Call this "page A".
2. either while the page is loading, or optionally after canceling the page load, perform the rest of these steps.
3. Try to open any other web page secured by the same SSL certificate in another tab. Call this "page B".
4. In yet another tab, open any web page not secured by SSL, or else secured by a different SSL cert. "page C".
5. In any of the other browsers I have mentioned, try to open page B.
6. Ill effects may be escaped from by rebooting FF.
Actual Results:  
FF tab for page B will sit and spin and never load. Even if the page being requested is a short text file.
FF tab for page C will load normally.
Other Browser tab for page B will load normally, and finish while FF tab B continues to sit and spin.

Expected Results:  
FF tab for page B should load normally.

Comment 1

[Jesse Thompson]

PS: Our experience of this bug has not been related to "page A" necessarily downloading data at high speeds, rather the web browser waiting for new data from the web server. For example, on a server-side script that is performing slowly. So it may be easier to reproduce this problem if the script and web server running page A teergrub the client than if page A is a very large file.

Comment 2

[Tyler Downer [He/Him]]

This is a mass search for Firefox General bugs filed against version 3.0 that are UNCO and have not been changed for 200 days.

Reporter, please update to Firefox 3.6.10 or alter. Firefox 3.0 is no longer supported and is no longer receiving updates. After you update, please create a fresh profile, http://support.mozilla.com/kb/managing+profiles, and test to see if your bug still exists. If you still the bug, then please post a comment with the version you tested against, and the problem. If the issue is no longer there, please set the RESOLUTION to  RESOLVED, WORKSFORME.

Comment 3

[Jesse Thompson]

Well, I gave up on the browser a month or two after filing this bug report. I'm sorry to hear that I've cluttered up your mass search a couple years later. I won't let that happen again.

I've just tried 3.6.10. The issue is less pronounced now (Firefox refuses to load Page B for the next five minutes or so, whereas other web browsers simply don't display the phenomenon at all), but whatever.

Comment 4

[timeless]

Jesse: w/o a testcase it's incredibly unlikely that anyone will look at this.

From memory the PSM design has only one crypto thread or something like that, so your experience while unfortunate matches what I'd expect to happen (by design, not as a user).

Could you please set up a testcase for this?

Comment 5

[timeless]

The other thing we'd need to know is whether the certificate hints of a CRL or OCSP.

Comment 6

[Jesse Thompson]

Hello, thanks for having a look nowadays. I'll try to make a test case, I can confirm the behavior still happens in our intranet (which brought the matter to our attention initially) but no longer appears to be triggered by simple test cases such as php sleep or a million <span> tags. The page of ours which does reliably and easily reproduce the problem has loads of personal information in it, so I need to sanitize that thoroughly before using it as a candidate.

So far as the SSL cert, it's visible to the public at https://www.webformix.com/ .. it's a wildcart cert from GoDaddy over *.webformix.com. 

Under the certificate details listed by firefox, in certificate > extentions > authority information access, it says:
Not Critical
OCSP: URI: http://ocsp.godaddy.com/
CA Issuers: URI: http://certificates.godaddy.com/repository/gd_intermediate.crt

I'll get back to you when I've got some test cases to demonstrate. Thank you.

Comment 7

[Jesse Thompson]

Well, I have to say that it appears as though the phenomenon has completely evaporated. Now using 3.6.13. Between October and now I've only caught the effect on our intranet a couple of times, and as of today I cannot purposely reproduce the effect on our intranet even if I load a number of pages simultaneous to our ponderously long report.

If this is due to a change, then congrats folks, and if not well then I'm glad to see it gone but a bit sad to have missed learning why. :)