Closed Bug 134735 Opened 19 years ago Closed 7 years ago
warn about server RSA keys less than 1024 bits
With the recent Bernstein advances in factoring, there are claims that 512-bit RSA keys can be broken in days using readily available hardware. This suggests that Mozilla should warn about sites using 512-bit server keys, as such sites are vulnerable to impersonation.
Two issues I see with this patch: 1) The current wording of the STATE_SECURE_LOW pop-up warning only refers to low-grade encryption. In the case of a weak authentication key, it might be too misleading. 2) The "view cert" button off of the page info window doesn't display the cert's key size.
In your suggested fix, you arbitrarily chose "900" as the limit to separate the "someone might be able to impersonate" from the "no risk to impersonate at all" case. But are we really sure, there is NO entity on earth that is able to impersonate sites using a higher crypto key? The lifespan of an application installation might be long. The number "900" might change any day. Imagine a user who is still using 2 two year old client. For some web sites the "impersonating" warning is shown, the user feels bad, and decides to go to a different web site not showing that warning. Now the user would feel completely safe that there is no impersonating risk involved at all. However, since the release of the application the keysize in use might have been broken by advances in science, and the user's assumption might be wrong. I agree it is good to warn about low key sizes. But my point is: Are we able to make the decision which bit number is approriate for the impersonating risk for the application life cycle? I'd argue, the conclusion about the security of a page could be left to the user. If we report the key sizes and crypto algorithms to the user, users can combine this info with their knowledge about the current cipher safety situation.
The vast bulk of users won't have any knowledge of the current cipher safety situation. The mozilla code will normally have much better knowledge of current cipher safety than the user, so it makes sense for the application to make this decision. As there are advances in cryptanalysis, applications will have to be replaced. This is the nature of the technology. The best an application can do is pick key sizes that can be reasonably expected to last for the time they have to. I believe we have sufficient information about factoring to know that 512-bit RSA keys are too weak.
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
I agree that it is appropriate to warn against too-weak authentication. I'm glad to see that this patch uses SSL_GetChannelInfo to get more detailed info than was previously available with SSL_SecurityStatus. Another "new" function that provides more info than SSL_SecurityStatus is SSL_GetCipherSuiteInfo(). I encourage PSM to use these functions. The new functions were developed for PSM. As for the question of whether 900 bits is good enough, and for how long, maybe we should make it a preference, with 900 being the initial default. But a 900 bit floor is better than no floor, which is what we have now.
For ECC keys, we'll need a lower cutoff than 900.
John, You created this bug, and added a patch. Now that you're the PSM owner, why not take this bug and finish it?
I believe the certificate viewer needs to display the key size before the user would have a comprehisible UI. Thus, I marked it blocked by bug 154641. But I do indeed intend to work towards fixing this bug.
Assignee: nobody → jgmyers
This is a duplicate of 78837.
In reply to comment 9, this is not a duplicate of bug 78837. This bug asks for an active warning to the user. Bug 78837 asks for more info in a rarely used dialog. Now, here's more motivation for this bug. https://www.hapoalimusa.com/questlogin.nsf?open&login is a bank login page with a 512-bit private key. Johnathan, here is another security UI enhancement worthy of your consideration.
I suggest raising the priority of this and handling it along with bug 587407. 512-bit keys can be broken very inexpensively and at basically no cost. From http://lukenotricks.blogspot.com/2009/08/solo-desktop-factorization-of-rsa-512.html: "Moody used public source factoring software on a dual-core Athlon64 at 1900 MHz. Just under 5 gigabytes of disk was required and about 2.5 gigabytes of RAM for the sieving process [which took 73 days]." From http://forum.disk.net/security-services/10-factoring-rsa-512-service.html: "Factoring up to RSA-512 services / price indication 5000$ / Estimation on calculating the private key is 2 weeks. (we have 2 seperate clusters running, sometimes its rented to another company)"
(In reply to comment #11) > I suggest raising the priority of this and handling it along with bug 587407. > > 512-bit keys can be broken very inexpensively and at basically no cost. Please see bug 587407 comment 30 and 36. We don't currently have an error code that indicates a weak RSA key. Wan-Teh had renamed the error code, so it's clear that disabling DH is the correct path when automatically retrying. In other words, if you wanted to automatically retry and disable RSA, we would have to introduce an additional error code specifically to report a weak RSA key.
Assignee: jgmyers → nobody
From http://listserv.nodak.edu/cgi-bin/wa.exe?A2=ind1001&L=nmbrthry&T=0&F=&I=-3&S=&P=719: We are pleased to announce the factorization of RSA768, the following 768-bit, 232-digit number from RSA's challenge list: 12301866845301177551304949583849627207728535695953347921973224521517264005 07263657518745202199786469389956474942774063845925192557326303453731548268 50791702612214291346167042921431160222124047927473779408066535141959745985 6902143413. The factorization, found using the Number Field Sieve (NFS), is: 3347807169895689878604416984821269081770479498371376856891 2431388982883793878002287614711652531743087737814467999489 * 3674604366679959042824463379962795263227915816434308764267 6032283815739666511279233373417143396810270092798736308917 We cannot rely on CA policy to enforce this because (a) some CAs in our root cert database have issued certificates with weak keys, (b) the user can trust certs that aren't signed by CAs in the root cert program.
Summary: warn about 512-bit server keys → warn about server RSA keys less than 1024 bits
http://technet.microsoft.com/en-us/library/cc751157.aspx >RSA greater or equal to 2048-bit modulus I would sleep better at night knowing < 1024 was a hard fail.
Reason for hard fail: 512bit keys have been proven to be easily crackable. end of 2010 (from memory) was the deadline for all root ca to move to 2048bit roots with SHA1 or better.
Duplicate of this bug: 134156
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1049740
You need to log in before you can comment on or make changes to this bug.