Closed Bug 134735 Opened 19 years ago Closed 7 years ago

warn about server RSA keys less than 1024 bits

Categories

(Core Graveyard :: Security: UI, defect, P3)

1.0 Branch
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1049740

People

(Reporter: jgmyers, Unassigned)

References

()

Details

(Whiteboard: [kerh-ehz][psm-tcpip])

Attachments

(1 file)

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.
Attached patch Proposed fixSplinter Review
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.
Keywords: nsbeta1
Priority: -- → P3
Version: 2.0 → 2.4
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Blocks: 134156
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.
Depends on: 227101
For ECC keys, we'll need a lower cutoff than 900.
Depends on: 154641
No longer depends on: 227101
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.
Product: PSM → Core
Whiteboard: [kerh-ehz]
QA Contact: junruh → ui
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.
Version: psm2.4 → 1.0 Branch
Depends on: 307319
No longer depends on: 154641
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
Whiteboard: [kerh-ehz] → [kerh-ehz][psm-tcpip]
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1049740
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.