134735 - warn about server RSA keys less than 1024 bits

Status: RESOLVED DUPLICATE of bug 1049740

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

Description

[John G. Myers]

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.

Comment 1

[John G. Myers]

Attachment: Proposed fix

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.

Comment 2

[Kai Engert [:KaiE:]]

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.

Comment 3

[John G. Myers]

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.

Comment 4

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 6

[John G. Myers]

For ECC keys, we'll need a lower cutoff than 900.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

John,  
You created this bug, and added a patch.  Now that you're the PSM owner,
why not take this bug and finish it?

Comment 8

[John G. Myers]

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.

Comment 9

[ghost16825]

This is a duplicate of 78837.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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)"

Comment 12

[Kai Engert [:KaiE:]]

(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.

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.

Comment 14

[Steven Roddis]

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.

Comment 15

[Steven Roddis]

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.