Slashdot Mirror
Mozilla 1024-Bit Cert Deprecation Leaves 107,000 Sites Untrusted
msm1267 writes: Mozilla has deprecated 1024-bit RSA certificate authority certificates in Firefox 32 and Thunderbird. While there are pluses to the move such as a requirement for longer, stronger keys, at least 107,000 websites will no longer be trusted by Mozilla. Data from HD Moore's Project Sonar, which indexes more than 20 million websites, found 107,535 sites using a cert signed by what will soon be an untrusted CA certificate. Grouping those 107,000-plus sites by certificate expiration date, the results show that 76,185 certificates had expired as of Aug. 25; of the 65 million certificates in the total scan, 845,599 had expired but were still in use as of Aug. 25, Moore said.
that slashdot wasn't affected by this.
It sounds from the writeup like most of the sites in question are defunct and that's why they're using out of date crypto. Few sites that people actually visit would appear to be affected.
I read the internet for the articles.
hackers, start your engines...
if this is supposed to be a new economy, how come they still want my old fashioned money?
“All major browsers will alert users of a site using an expired certificate, and of the 107k affected, only 30k were not expired, and so would no longer be trusted by Mozilla as a result of their recent change,”
So not 107K, only 30k. And that's not a real issue. The browsers are correct, the connection isn't secure at 1024. People can complain as much as they want, trust is not something that is eternally granted without condition.
Well.. maybe. Or Maybe not. But Definitely not sort of.
An unavoidable side effect of trusting less is that you trust less. In this case, ancient websites using outdated crypto, won't be trusted. Most of which already are no longer trusted due to expired certificates.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
1. If all these sites renew or get proper certificates it'll be a big improvement in cash for the Certificate Authorities.
2. Maybe most of these un-certificated sites will disappear, though it won't mean much for internet congestion if most are not accessed anyway.
3. Maybe swschard's comment that hackers will have a field day is true, although to what benefit to hackers or detriment to site users?
In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
A browser not trusting something that's not to be trusted is a positive thing. Yes, some old sites will suffer. That's how it's supposed to work. They'd better up their game. People expect security to be take more seriously these days, as there is more at stake and more muppets with a lot of time on their hands trying to attack you.
Firefox doesn't support the OS's built in certificate stores, which makes it a really big pain in the ass to manage certs yourself (like if your managing certs for firefox users at your company) - you basically have to compile certutil and write all kinds of fun scripts for client devices.
If firefox let me co-manage certs I could just re-add the deprecated cert :).
you'll never know how many you can't trust.
"Grouping those 107,000-plus sites by certificate expiration date, the results show that 76,185 certificates had expired as of Aug. 25"
So, the headline should really say 31,000, since 76,000 shouldn't be trusted regardless of what Mozilla does.
"National Security is the chief cause of national insecurity." - Celine's First Law
Anyone but self-signed Certificate providers.
All certs effectively do is provide encryption. The whole "provides identity" thing is a myth because there is *no* way to ensure such a thing. There's about a zillion ways to fake that identity. Encryption is guaranteed. Unbreakable encryption is not. That's all you get. That's all you'll *ever* get.
Browser "trust" warnings are nothing more than scare tactics designed by the cert manufacturers, in collusion with browser manufacturers, designed to build a completely unnecessary industry for scamming web site owners out of a huge amount of completely wasted money. Wasted other than funding the cert provider parasites, that is.
Using your reasoning, I could very well be living my life in an NSA created virtual world, so any conversation I have in any capacity at all could be monitored at any time. Even my thoughts! So there is no reason for any of this security what-so-ever and it's all a scam by evil virtual corporations to steel my fake virtual money. Right?
I'm going to go out on a limb and suggest (and this is just a hunch) that you don't know what you're talking about.
systemd is Roko's Basilisk.
Symmetric and asymmetric keys are different things and have different key lengths. One cannot directly compare key sizes between two wholly different classes of ciphers. There are numerous reasons, mostly involving arcane mathematics, why asymmetric ciphers require longer key lengths than symmetric ciphers to offer similar levels of protection.
For example, a 1024-bit RSA key (RSA is an asymmetric cipher) is essentially equivalent to an 80-bit symmetric key (AES, 3DES, etc. are symmetric ciphers). SHA1, a hashing algorithm, provides less than 80 bits of security; those wishing stronger signatures are switching to SHA-256 (which offers 128 bits of security) and SHA-512 (which offers 256 bits).
A 2048-bit RSA key, such as those used by most CAs and web servers these days, has the same strength as a 112-bit symmetric key. NIST says they should be good enough until around 2030.
3072-bit RSA keys offer the same strength as a 128-bit symmetric key. A whopping 15,360-bit RSA key would be needed for 256-bit security; the same level of security could be achieved with a 512-bit elliptic curve key, which would be much, much faster than such a large RSA key.
So basically the net effect will be another warning page to click through when visiting the sites in question? Do end users really know what any of this stuff really menas?
Seriously, how does this effect web browsing for the average Joe?
I was thinking the same, and I'm no expert in cryptography. After all distributed.net have spent 12 years trying to brute-force a 72-bit key and have only managed to test 3% of the total keys. 2^1024 is such a mind-bogglingly large number the entire world's computers couldn't crack it in a billion lifetimes.
Anyway, wiki to the rescue:
As of 2003 RSA Security claims that 1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys and 3072-bit RSA keys to 128-bit symmetric keys. RSA claims that 1024-bit keys are likely to become crackable some time between 2006 and 2010 and that 2048-bit keys are sufficient until 2030. An RSA key length of 3072 bits should be used if security is required beyond 2030.[6] NIST key management guidelines further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys.
For all intensive porpoises your a bunch of rediculous loosers
RSA-1024 are still safe, despite what many fearmongers have been preaching for years. It was only a few days ago
(http://www.newscientist.com/article/dn26135-factorisation-factory-smashes-numbercracking-record.html?cmpid=RSS|NSNS|2012-GLOBAL|online-
news#.VAXRfDzYvyF) that a new factorization record was announced. It is a roughly 1,024-bit integer - but it took 2000 high end-PC years, and it is a Mersenne integer - orders of magnitude easier to factorize than an integer of similar size obtained as the product of two large primes, which is what one does in the RSA algorithm.
Short of sudden, unexpected and dramatic breakthroughs in the fields of mathematical integer factorization, or quantum computing, RSA-1024 keys still have quite a few years of usefulness ahead.
... the same level of security could be achieved with a 512-bit elliptic curve key, which would be much, much faster than such a large RSA key.
It'd be faster for the NSA too - it's a win-win!
#DeleteChrome
Is this alteration specific to self-signed appliances, like a NAS? Or would this bypass for all self-signed certificates?
Also, this sounds like a good thing to keep a record of, with regards to documenting changes in your about:config.
[End Of Line]
Comment removed based on user account deletion
try being in business and signing your own cert.
Let me know how many tech calls you get because Norton deletes your web delivered exe.
scare or not - It's a money problem unfairly placed on developers.
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
And that's probably why they don't, captcha prorate
The sites got certificates and installed them several years ago, before thw current "https everywhere " trend. In other words, they decided that because they were handling sensitive information, they needed a secure connection. Maybe they have an order form,that accepts credit cards, whatever. For some reason, they needed to be more secured than most sites. The URL in the address bar says "https", indicating that it is secured. We know that although they publicly declared that their site should be secured, it isn't.
Contrast xkcd.com. Randall didn't get a certificate, because you don't need a secured connection to look at nerd comics. Which site presents a security risk? The site that has no need of tls, or the site that needs to be secured, but isn't?
* xkcd might actually have a cert, if they sell stuff on the site or whatever. I didn't bother checking because it's beside the point whether that specific site uses a cert.
You're confusing the cost of legitimate operations with the cost of searching the key space. You don't want legit users to bear too much cost since everyone ends up paying that over and over, but you do want the cost of searching to be high since that's not something that people should be doing.
"Little does he know, but there is no 'I' in 'Idiot'!"
Remember that the exponential math in DH and RSA is called a HARD problem, not and impossible one. Consider that regarding key strength 1024 bits of RSA is not very secure in today's world. I'm not saying it's cracked... Just weak.
While GP's statement was over the top, it isn't ENTIRELY off base. Lets consider, you connect to a site via. https and look at the cert.
According to the cert, ajaxco says the site is example.com (as expected). But wait, who the hell is ajaxco? Ever heard of them? Any idea how quality oriented they are? How do they KNOW example.com is the one and only example.com? Did they send an investigator? Did they do a corporate records search (for a personal web site, yeah sure)? Or did they make the person who requested the cert pinkie swear?
For all you know, ajaxco, a division of fly-by-night industries gave the cert to the owner's brother-in-law with no concern for correctness whatsoever.
Or perhaps the CA means to be legit but failed to secure their signing key (it HAS happened) and the cert was actually signed by none other than the Russian Mafia.
Perhaps a government somewhere ordered a CA in their jurisdiction to sign the bogus cert. That government may or may not be corrupt.
But you have the ILLUSION that you know who you are talking to.
As for the costs, the market has had 20 years to work that out and it has failed.
DANE seems very nearly pointless to me. Maybe I'm mising something. The victim goes to Paypal.com. Their browser checks the certificate to make sure it's really Paypal.com, as opposed to a MITM or someone who hijacked Paypal's DNS. That's the typical use for TLS, right?
So checking the cert is supposed to protect the user from an adversary who can intercept packets addressed to Paypal.com and send back bogus responses. That means the adversary can intercept DNS packets intended for Paypal.com and respond wuth a bogus cert record. Nothing has been gained unless you can independently verify the DNS records using some other mechanism. It's proposed that DNSSEC be used for this. DNSSEC basically means the DNS record is signed, so to trust the DNS we need to validate the cert used to sign the DNS. Okay, soall we have to do is find a way to validate a DNS signing cert. If we can validate that cert, we can trust the ssl cert.
Hmm, we validate someone's cert by first validating their cert? I don't think we've made any progress toward solving the problem.
DANE is mostly to guard against rogue CAs. CA #1 cannot sign a certificate claiming to represent the domain that was actually certified by CA #2. So it limits the amount of damage that a rogue CA can get away with.
It may also eliminate the need for CAs and certificate altogether. You just store the public half of your certs in the DNS system.
Wolde you bothe eate your cake, and have your cake?
-> It may also eliminate the need for CAs and certificate altogether. You just store the public half of your certs in the DNS system
That's the problem. By the time a TLS certificate comes into play, the DNS must have already been compromised (directly or via mitm). The certificate is designed to alert you if the server you're talking to isn't who you think it is - based on DNS.