Closed Bug 441742 Opened 14 years ago Closed 8 years ago

Go Daddy CRL update hangs Firefox

Categories

(Core :: Security: PSM, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: mozilla_kiddm2, Unassigned)

References

()

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Attempting to update the Go Daddy CRL causes Firefox to consume 100% of CPU for a couple of minutes and then to hang (does not even service repaint requests). The URL for the CRL is https://certificates.godaddy.com/repository/gdroot.crl, which was automatically imported by Firefox 3 when upgrading from 2.0.0.14. Automatic CRL updating is off for this CRL. So far this seems to be a Go Daddy specific problem; CRL update for VeriSign works fine.

CPU burn appears to occur in nss3.dll!nssHash_Iterate


Reproducible: Always

Steps to Reproduce:
1. Navigate Tools (menu) --> Options (menu) --> Advanced (icon) --> Encryption (tab) --> Revocations Lists (button)
2. Select "The Go Daddy Group, Inc"
3. Press Update button
Actual Results:  
100% CPU consumed for 1-2 minutes, followed by browser hang.

Expected Results:  
CRL is quickly imported.

See attachments:

1. Wireshark capture of CRL network traffic
2. Thread stack traces from WinDbg (I am not good enough with WinDbg to take it much further)

Difficult to assign severity - it is a hang, but one that is unlikely to be encountered by very many users.
I can't confirm this on Mac, where it seems to go basically as expected, and without hang, but nevertheless, transferring to Core, where our crypto stuff lives.
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
Can't confirm this on 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0

Neither the initial download nor the manual update via the CRL manager reproduces this here.
Is this crash still reproducible in Firefox 3.5?  If it isn't, we should resolve it as RESOLVED WORKSFORME.
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
The CRL Manager / Revocation Lists feature was removed.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.