Microsoft, Mozilla and Google Ban Malaysian Intermediate CA 80
Orome1 writes "Microsoft, Mozilla and Google have announced that they are revoking trust in Malaysia-based DigiCert, an intermediate certificate authority authorized by well-known CA Entrust, following the issuing of 22 certificates with weak keys, lacking in usage extensions and revocation information. 'There is no indication that any certificates were issued fraudulently, however, these weak keys have allowed some of the certificates to be compromised,' wrote Jerry Bryant of Microsoft's Trustworthy Computing."
I lol'd at the stock photo (Score:1, Funny)
Every article demands a picture, right.
Not related to the US Digicert (Score:5, Informative)
It might have been nice to mention that in the article summary.
Re: (Score:2)
Oh my goodness, no kidding. How many admins need a defibrillator after reading that headline? I certainly thought for a few minutes that this story would direct my entire weekend.
Re: (Score:2)
Re: (Score:3)
It might have been nice to mention that in the article summary.
Indeed. From the article:
Both Mozilla and Microsoft made sure to note that there is no relationship between DigiCert Malaysia and Utah-based DigiCert Inc., which is a member of the Windows Root Certificate Program and Mozilla’s root program.
Whew!
Re: (Score:1)
yeah, like it's going to happen... and anyway, leave Chinese alone, if it wasn't for them and the Russians i wouldn't be able to watch top gear's latest episodes on youku / rutube
Re: (Score:1)
Re: (Score:2)
Nothing prevents you from installing their certificate yourself if you don't agree with the decision.
Re: (Score:1)
Why would they install the very certificates they want revoked?
Re: (Score:2)
Because you want to? Does it matter? The point is that you can - just like you can import your own CA.
Re: (Score:2)
Apparently yours is that poor. His point is "well we might as well do X since we're already doing Y" meaning he disagrees with Y.
Re: (Score:1)
Lets replace "own citizens" with "foreign nationals" and blacklist USA.
Who generates 512-bit RSA keys these days? (Score:3)
RSA-512 has been known to be weak for a long time.
Who in their right mind would generate such a certificate for (presumably) a production system?
Why didn't the CA have some sort of system to detect such short keys?
The CA I use doesn't allow anything less than 2048-bits to be signed. While the policy may be a bit strict, as 1024-bit keys still have their uses (there's a lot of hardware that only deals with 1024-bit keys), at least they're erring on the side of caution. I'm sure they're not the only one with such a policy.
Re: (Score:2)
This is probably why they are revoking trust for the *entire CA*.
Re: (Score:2)
Understood.
My main curiosity is why any administrator would generate 512-bit RSA keys for their own servers, knowing that they're weak.
I wonder if there's some old Malaysian-language "Guide to setting up SSL" website that they're following? I'd be curious if there's any commonality between all the 512-bit keys. That, or some particular software that has that keylength in the default configuration file.
Re: (Score:2)
Which is a bit of an interesting decision, as it doesn't compromise anyone except the individuals foolish enough to generate insecure RSA keys and submit them, and there are numerous ways they could've screwed up their own security that the CA could never detect anyway. What's even more interesting is that they've allowed big-name CAs to remain as such despite them issuing fraudulently-obtained certificates corresponding to major websites. I think the size of this CA has a lot more to do with this than thei
Re: (Score:2)
That sounds like a problem that should be fixed by the browser makers, not by the CA. Why does the default have to be "everything", and not "nothing", or some minimum set of usages?
Re: (Score:2)
Except in this case its not the browser makers that would need to fix it, its companies like Microsoft who accept these certificates as valid for code signing when they were not explicitly marked with a "can be used for code signing" flag.
Re: (Score:3)
"I have been contacted by Entrust who say that two of the certificates issued by the Malaysian DigiCert Sdn. Bhd. were used to sign malware used in a spear phishing attack against another Asian certificate authority," reports Sophos' Chester Wisniewski.
Re: (Score:2)
Re: (Score:1)
>RSA for example needs two prime numbers as a keypair, so while the key length might be 512 bit, there are actually not that many from those 2^512 numbers to choose from. Also, certain key values are prone to attacks.
How many is not that many? Bruce Schneier in Cryptography Engineering calculates that 1 in 1386 numbers in the 2^2000 bit range is prime. In the 2^512 range primes are even more frequent, according to prime counting estimates. [wikipedia.org]
Re: (Score:2)
That said, RSA is well known to not have key pairs that grow in security in a linear fashion compared with key length. EC fortunately has much better properties, although EC certainly has its own drawbacks. A 256 bit EC key has similar security to a 128 bit AES key (insofar as you can compare those) and 512 bit has about the same as 256 bit AES. You will quickly go to 16K RSA keys to accomplish a similar security level. Try and generate a 16K RSA key pair and do a few signings to see what that means. Try th
Re:Who generates 512-bit RSA keys these days? (Score:5, Informative)
That's a good question. I will attempt to answer it, with the caveat that I'm also not a crypto expert.
Most of the relatively shorter key lengths you see these days, such as 128-bit and 256-bit refer to symmetric encryption algorithms like AES. At this point in time, such keylengths are secure for the foreseeable future. These algorithms tend to be quite fast (AES has hardware-acceleration in many CPUs, which can encrypt or decrypt data at 1GB+/sec in some cases, and around 300MB/sec on many non-accelerated CPUs), but require that both parties exchanging encrypted data share the same key. (Hence the name "symmetric" -- the same key is used for encrypting and decrypting.)
The two parties could previous exchange a shared symmetric key by means of a trusted channel, like a trusted courier, or meeting in person. This can be extremely difficult in the real-world, though.
The longer-length keys you often see (1024-bit, 2048-bit, 4096-bit and, in the case mentioned in the article, the not-very-secure-at-all 512-bit length) are "asymmetric" keys -- when they're created, one creates a "public key" and a "private key" that are linked a certain mathematical way. The public key can be distributed widely, while the private key must be kept secret. If Alice wants to send Bob a secure message, she can encrypt it with Bob's public key, but the message can only be decrypted with Bob's private key -- even if someone intercepts the encrypted message and has Bob's public key, they are unable to decrypt it.
Asymmetric encryption is extremely slow, relative to symmetric encryption (I seem to recall reading that they're about a thousand times slower). Sending large amounts of data over secure connections would be extremely slow. Fortunately, modern cryptosystems use a hybrid model: they use asymmetric keys to exchange a shared secret key that is then used for faster symmetric encryption -- this allows for quick symmetric encryption methods to be used by solving the problem of exchanging the symmetric key without needing to meet in person.
SSL, for example, uses such a method. A simplified description follows: when your browser connects to a secure website the server sends you its public key (which has been digitally signed by a certificate authority who vouches for the identity of the server). Your browser checks the signature to make sure it's actually been issued by the authority and, if it checks out, creates a random symmetric key, encrypts it with the server's public key and sends it to the server. The server decrypts the symmetric key with its private key. Both client and server then encrypt all future communications with the symmetric key.
Because asymmetric and symmetric encryption keys use entirely different mathematical methods to secure data, their keylengths aren't directly comparable. According to NIST [keylength.com], a 3072-bit asymmetric key is about as strong as a 128-bit symmetric key.
See and [wikipedia.org] for more details. [wikipedia.org]
Re: (Score:1)
I am a cryptographic security researcher. I will give some background on this before answering your specific questions. Information security is subject to the same pressures as other forms of conflict. Such pressures are otherwise known as an "escalation", "arms race" or even as "evolution". Cryptography is one such armament in the information security arsenal; and while cryptography is subject to constant pressure of Moore's Law as you quite rightly assert; more cataclysmic changes can occur through leaps
Re: (Score:2)
Thank you Pete and Lexx for explaining more stuff more succinctly than anything I've seen ere now.
Re: (Score:2)
Re: (Score:1)
Thanks to you and Pete for explaining this subject in much closer to layman's terms than I've ever seen it tackled, it does make me think of a couple of follow up questions if you don't mind.
Not at all, you questions are poignant and well-framed.
Since as you pointed out with Enigma (which IIRC there is still a handful of messages they still haven't cracked after all these years) there are gonna be advances coming down the pipe and that both AES 128 and RSA 1024 have expiration dates, wouldn't it be smarter to try to jump a little bit ahead of the curve?by that I mean wouldn't it be smarter to just go ahead and switch to 512 bit AES and 4096 RSA when the previous schema expires? Or is that too computationally expensive with current technology?
Yes, going too far beyond current standards is expensive. As you imply, when computational overhead is considered (particularly in terms of server hardware) the cost of supporting increased key lengths is significant. For ciphers that are embedded in hardware devices there is further pressure to reduce footprint and fabrication costs as well as motivation to build in some amount of redundancy. Economic pressure therefore acts to resist the urge to overs
Re: (Score:2)
Re: (Score:1)
I bet when you see some beautiful security system turned into a mess because of bad policies you feel like I do when i hand over some box i lovingly created only to have them turn it into a spyware/adware laden mess in less than a month, just like that scene in "History of The World part I" where the artist gets his work pissed on by the critic!
Indeed. Apathy, ignorance and laziness are the greatest of all foe.
Malaysia? (Score:1)
That Malaysian DigiCert site is fun (Score:2)
"DIGICERT is in the center of an effective trust model that the government is creating to address the issue of information security and the negative perception that has been painted in association with online transactions." *BREATH*
"Customers won't transact business at your website unless they are certain it's secure."
"The username and static password scheme has been widely used for verification online. Nevertheless, many have recognize this scheme as being obsolete as it can no longer be trusted to provide
Re: (Score:2)
My wife is Malay, and trust me they don't speak Engrish, they speak Manglish.
Re: (Score:3)
I know! I posted my root password on my web site and some asshole hacked into it. And they told me Linux was secure! I'm switching to Windows!
Re:I thought Linux was so secure slashdotters (Score:5, Funny)
I wonder if there's something for Linux that's equivalent to Blizzard's Warcraft password inspector. He contacted me last week, asking to inspect my password to ensure that it's secure. It was kind of embarrassing that my account got hacked, and my credit card maxed out, shortly after I'd sent him my password. Fortunately though I was able to regain access and change my password. I forwarded the new password to the inspector and apologized if he had trouble trying to use the old one. Email the Blizzard guy to see if he knows the Linux password inspector. His address is paswordinspecter@blizzard-account-admin.shulinhost.cn
Re: (Score:2)
Your OS can't help you if you do everything wrong anyway. You can get DOS up and exploitable if you're just the right sort of special (hint, if you miss it: DOS doesn't have a built-in network stack)
Re: (Score:2)
4/5 of the CA's recently breached run Linux:
http://uptime.netcraft.com/up/graph?site=StartCom.com [netcraft.com]
http://uptime.netcraft.com/up/graph?site=GlobalSign.com [netcraft.com]
http://uptime.netcraft.com/up/graph?site=Comodo.com [netcraft.com]
http://uptime.netcraft.com/up/graph?site=DigiCert.com [netcraft.com]
Now, why's that? I thought Linux was secure, hearing it for years here on slashdot??
Wait, there are CAs that don't use Linux?
Company name change request (Score:1)
DigiCert Inc is a major SSL CA used by Yahoo, Facebook and others.
Re: (Score:2)
I hate to piss on your trolling but this CA is not a trusted authority in iOS.
Re: (Score:1)
No it doesn't. You can always reinstall the root cert if you want.
Eliminate Intermediate CA's, restrict root CA's. (Score:3)
The CA model is clearly broken, it is a chain that is too long with too many weak links. We have hundreds of root CA's, and combined with intermediate CA's, that number could be in the thousands. That is too many points of failure, which can bring down the entire system.
The following needs to be done immediately:
First: Eliminate Intermediate CA's:
If an entity does not qualify as a root CA, why should it be allowed to issue trusted certificates?
Second: Restrict Root CA'S by geography:
It is okay to trust the Chinese Post Office for *.cn, *.hk, etc. domains, why should we trust it for *.ca or *.com of Canadian companies? Why not restrict root CA's to geographic zones and also domain prefixes.
Three: Certificate Caching & Monitoring Should be built into browsers:
Certificate Patrol is an excellent addon that does this, why isn't it built into browsers? https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/ [mozilla.org]
Re: (Score:2)
the system is wrong (Score:2)
The CA model is broken. Always has been. Your browser comes with several hundred baked-in CAs, each with complete authority over what your browser thinks is a trustable connection. It's like a RAID 0 array with 600 drives. Just asking for trouble, huh? And it's hard or even impossible to tell when one of those drives is reading or writing bad data. Like the truism about hard drives, "hard drives just fail (so get backups)", CAs fail. Evidently.
Being a CA is a "race-to-the-bottom" business where vendor
Re: (Score:2)
Granted, the browser vendors set standards for accepting CAs. That's a barrier to keep out obviously bad CAs. But that's still just adding QA on hard drive production.
I still don't want to run a RAID 0 array with 600 hard drives, regardless of how high quality they are.
Re: (Score:2)
The reason the CA system is broken is because we're not using the White List Model of "Trust No One". I've had to address this issue in Firefox by going through the entire list of certificates and marking everyone of them as untrusted and the funny thing is, I've only had to create a dozen exceptions to that model. These are websites that I depend such as my bank, merchants (Newegg), Google as I do use their https mode. Seriously, it did suprise me that I only needed 12 exceptions to the rule and each one i
hand-edited CA list (Score:2)
That's fantastic. I never would have expected someone to try this.
Oh, very interesting. Of course this technique wouldn't work for the average user, but it gives us some insight into possibilities.
Seems you've virtually rejected the CA model and instituted your own. Actually, you're probably now closer to a "decide for yourself whom to trust
Re: (Score:1)