Certificate Blunders May Mean the End For DigiNotar 128
Certificate Authority DigiNotar is having a rough time of it. dinscott writes with these words from Help Net Security: "After having its SSL and EVSSL certificates deemed untrustworthy by the most popular browsers, around 4200 qualified certificates — i.e. certificates used to create digital signatures — issued by the CA are currently in the process of being revoked and their holders notified of the fact by the Dutch independent post and telecommunication authority (OPTA). Starting from yesterday, OPTA has terminated the accreditation of DigiNotar as a certificate provider for 'qualified' certificates. The revocation of this accreditation also makes DigiNotar unqualified to issue certificates under the PKIoverheid CA."
Re: (Score:1)
If only our (US) lawmakers would have had the balls to do the same thing with the banks.
Remember Arthur Anderson Accounting? (Score:2)
They were the ones who certified Enron's accounts, claiming their books weren't cooked. Oops, it turned out that the books were cooked, and the company whose trade was supposed to be giving you an honest estimate of a company's financial status was exposed as not doing that, and they vanished nearly overnight. (There are leftovers, like their consulting business, but even they changed their name.)
On the other hand, of course there are the bond rating agencies like Moody's and S&P who rated AIG and the
In other, unrelated news... (Score:1, Interesting)
In other, unrelated news, a certificate authority was compromised and it's taken months before customers were able to protect themselves. Meanwhile, the government who profited from the breach continues to smile, wave, while Microsoft complies with its request to not invalidate its unethically-obtained certificates for its own citizens.
What's not news and should be: Why the hell we're not moving to ipv6 and telling these corporations to eat a bag of dicks, and our privacy and security is not for sale anymor
Re: (Score:1)
uhm.. ssl as a wrapper was swiped from the early ipv6 spec to add security to ipv4
it's just built in
ipv6 actually has ALOT more security by default, just liein about.
Re: (Score:2)
IPv6 has an alot [blogspot.com]? How nice.
Ummm, No. (Score:2)
IPSEC as a wrapper is closely related to the early IPv6 security models. It does provide eavesdropping protection and/or session integrity protection, but it doesn't solve the problem of identifying the party at the other end of the connection - it leaves that to other applications, typically hand-installed pre-shared passwords or else password tokens.
Not only does SSL operate at a different level of the protocol stack, but the important problem it's trying to solve isn't just the eavesdropping, it's prim
Re: (Score:1)
Re: (Score:2)
it doesn't solve the problem of identifying the party at the other end of the connection - it leaves that to other applications, typically hand-installed pre-shared passwords or else password tokens.
Maybe we could figure out some system of signed certificates in order to validate identity. Nah - the trouble with that is that I'd never be able to get the actual certs from the people I wanted to authenticate - it'd be a real PITA to have to pull them onto a USB key from my bank (or whomever) every time.
Aha - what if we had a few, highly trusted, centralized "authorities" who I could trust, whose public key information was widely available through a vast array of sources (to widely ensure that it wasn't
Re: (Score:1)
I'm not sure the parent post should really be moderated up, as it is now, since it seems to be reasonably misinformed.
Firstly, Microsoft has invalidated the cert (at least to my knowledge).
Secondly, it is not at all clear how moving to ipv6 tells the corporations to eat a bag of dicks while informing them that our data is not for sale anymore. The concepts (ipv6, dicks, and our data) all seem mutually exclusive.
Re: (Score:2, Interesting)
Firstly, Microsoft has invalidated the cert (at least to my knowledge).
Your knowledge is incorrect [google.nl]. At the request of the Dutch government, Microsoft deliberately did NOT patch its systems from that country... until several weeks later when the government's request was made public and they retracted their request.
Secondly, it is not at all clear how moving to ipv6 tells the corporations to eat a bag of dicks
Perhaps not to you, but to the rest of us who have read the standard... end to end encryption means no man in the middle attacks, no certificate authorities, etc. Every organization has access to its own key in DNS, and if someone tries to replace it, anyone who has c
Re: (Score:2)
Firstly, Microsoft has invalidated the cert (at least to my knowledge).
Your knowledge is incorrect [google.nl]. At the request of the Dutch government, Microsoft deliberately did NOT patch its systems from that country... until several weeks later when the government's request was made public and they retracted their request.
But Microsoft HAS pulled the cert, whereas your comment was written as if they have not yet done so. And my knowledge of this is not incorrect unless you are still implying that Microsoft has yet to invalidate those certs.
Secondly, it is not at all clear how moving to ipv6 tells the corporations to eat a bag of dicks
Perhaps not to you, but to the rest of us who have read the standard... end to end encryption means no man in the middle attacks, no certificate authorities, etc. Every organization has access to its own key in DNS, and if someone tries to replace it, anyone who has connected to it previously would know.
It does not mean no man in the middle attacks. Even with IPSec you still have to trust, whether you are trusting a CA or the DNS, you are still trusting. If your ISP is your DNS provider, and they are also the best positioned to implement MITM attacks, then unless you have a shared secr
You got many things wrong in two sentences! (Score:4, Informative)
IPv6 security options can give you end-to-end encryption similar to what IPSEC gives you, if you always turn it on.
End to end encryption means that nobody can eavesdrop on connections that you've set up to the party on the far end. If that party is actually the party you think they are, and they're somebody you should trust, that's a Good Thing - if they're a Man In The Middle, you lose (though it reduces the number of ankle-biters who might be trying to eavesdrop on you, and it's kind of comforting to know that your credit card is only being stolen by the Russian Mafia and not by the other people in the coffee shop with you.)
End to End Encryption doesn't give you a way to authenticate connections to people you don't already know. That's a job for certification authorities, or somebody doing a similar job. If you do already know the party at the other end, and have an authenticated connection of some kind (like a pre-shared key or a SecureID token or a courier with a briefcase handcuffed to his arm or a yellow sticky note or a PGP key on a business card that somebody who wasn't an impostor handed you ), end-to-end encryption systems can do things like Diffie-Hellman key exchange to bootstrap that into a full connection.
"Every organization has access to its own key in DNS" is an assertion about the DNS system, not the network or transport protocols. It sounds like you're thinking about DNSSEC, which _should_ have been deployed decades ago (but among other problems, they were blocked by the US ITAR anti-crypto mafiosi.) If DNSSEC had been deployed properly along with the DNS system, you could be sure that if you had the correct IP address for microsoft.com, you'd also have the correct public key for setting up connections to microsoft.com's web site, and if you have the correct IP address for m1cr0s0tf.com, you'd also have the correct public key for setting up connections to m1cr0s0tf.com, which might or might not be somebody you want to talk to.
Re: (Score:1)
Excellent spin. You should find an ambitious governor or lawyer to work for.
At the request of the Dutch government, Microsoft deliberately did NOT patch its systems from that country
Both Mozilla and Microsoft received a request from the Dutch government not to remove the Staat Der Nederlanden root, of which DigiNotar was a CSP. The rationale was based on two mitigating factors:
- there was no evidence of fraudulent certificates issued under this root
- the Dutch citizens were not under immediate threat
Both Mozilla and Microsoft complied initially. Mozilla fucked up their whitelisting (only kept SdN root, removed
Re: (Score:1)
Re: (Score:2)
same article mentioned that Apple has yet to send out an update to invalidate the certs on OSX browsers...
Bzzt. http://support.apple.com/kb/HT4920 [apple.com]
But not the end for the CA system? (Score:4, Insightful)
Re: (Score:2)
So what would you replace it with?
Re: (Score:2)
Re: (Score:2)
There are lots of problems with that.
Let's see:
It depends on the availability of a third party. SSL works fine with just the server you connect to, but for this you need to talk to the same set of servers for any certificate check. That makes it easy to block. Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.
It doesn't do many of the duties of a CA. It will happily mark as valid a certificate for gma1l.com, with the metadata copied from the gma
Re:But not the end for the CA system? (Score:4, Insightful)
The main benefit from this system is "trust agility". If someone hacks and obtains a root cert from Verisign, what are you (or the browser vendor) going to do? Keep the cert on the browser and risk being MITMed, or removing it and break half of encrypted websites? Diginotar was just a small CA, but what if a big one is hacked?
Convergence/Perspectives lets you have more than one notary verifying each cert, which means you won't break anything if you need to remove trust on one of them. By itself this makes it much better than the CA system, in my opinion.
Re: (Score:2)
I suggested an alternative in an earlier article: Change to a system of having multiple CA signatures on a cert, so that a CA can revoke without invalidating a certificate. Eg, min 3 s
Re: (Score:2)
Yes, but the notaries are much less safe. A CA at least verifies that you control the domain/email address the cert is for, notaries don't even do that, let alone checking that the metadata is correct.
Maybe the existing ones don't, but you could perfectly have ones that do, and you could trust just those. Or have them with different trust levels.
Also, being able to untrust a notary is nice, but how do you know when you need to? It's a run your own if you want deal. I can imagine what will happen: enthusiastic people will set up their notary, forget about it 3 months later, and soon enough there will be lots of unmaintained ones. Your list of notaries will eventually include those running on a forgotten 486 in a closet, insecure multiuser systems, unreliable connections, and so on. Some of that can be policed intentionally, but security can't.
Anyone can run a CA too, doesn't mean most people will trust their signature. Why would you (or your browser's vendor) add some random guy's notary to the trust list?
Re: (Score:2)
Re: (Score:2)
One thing I like about Convergence is that I can ask it to validate the cert with n+1 notaries which I hope would make it more likely that a "faked" cert and MITM would create an alert at my end. This way, as long as I am using notaries in different countries, I should be able to detect if my country has forced some CA to create wildcard cert for them to listen in to my SSL traffic.
Re: (Score:2)
I don't mind the idea of it in general, I think it can be an useful tool for somebody who knows what's going on, and what the results those systems produce mean.
But I don't think they Covergence or Perspectives should replace the CA system. They can augment it, but they lack too many of the functions of a CA to be a good replacement.
notary systems aren't hard to understand (Score:2)
It depends on the availability of a third party. SSL works fine with just the server you connect to, but for this you need to talk to the same set of servers for any certificate check. That makes it easy to block. Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.
Re: (Score:2)
That's a lot harder to abuse, though. Revocations are rare. A site that keeps using a revoked cert for very long is even rarer.
But to exploit that, you need to find a site that has something valuable, that's still using a compromised cert, to have the private key to that cert, and to replay OCSP. That's pretty t
REALLY, notary systems ARE NOT hard to understand (Score:2)
What exactly is the threat model you're positing?
Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.
You're on such a compromised net and you visit an HTTPS site...
Re: (Score:2)
Imagine I travel to an untrustworthy country. Let's say I go to China, and try to check my mail from there. Now, the government wants to know for whatever reason what I'm up to.
With the CA system, if they block OCSP that's not very significant for reasons I outlined before. They can block gmail.com, but then I can't get to my mail and never even send the password, so they don't
Re: (Score:2)
Remove the Chinese CA? That idea is "trust agility". You're suggesting you have some ability to change who you trust with modifying browser CA lists. It's quite minimal, really:
Did you remove the Diginotar cert? Or did you wait for your browser or OS to get an updat
Re: (Score:2)
I didn't say it was perfect, my point here is that in a worst case situation, a CA system still can work acceptably, even if not in an user friendly manner or using the default settings.
Yes, all of them
Re: (Score:2)
If we're getting down to the level of manually removing CAs, there's a lot of security inconvenience that's "acceptable".
That would certainly be an improvement.
Re: (Score:2)
Self signed certs work fine
Self-signed certs are effectively without identity assertions, since the creator can say anything they want in them. The only way you can trust them is if you either learn the true content of the certificate by some other method (copying the file via a known-good mechanism is the simplest way) or get someone else to assert that the certificate is indeed valid (i.e., they're a bodged-together CA). Without those, you simply don't have any way to tell if the server certificate is valid or not, as one certifica
The Browser-trusts-many-CAs system (Score:4, Interesting)
The current system is that your browser ships with a bunch of CA's listed in it, many of which are currently in business, and some of which are trustable, and some of which are random corporate leftovers run by shadowy anonymous figures, and if you're like most people you haven't bothered listing them (or if you did, it was years ago.) So from a technical standpoint, perhaps you're in deep trouble, but it's your own fault because you didn't look. See figure 1.
From a business/financial standpoint, it's different. Many of those CAs are run by reputable firms, whose business models are that they'll give a certificate to anybody who pays them $100 (or whatever the going rate is this year), and they'll certify that the payer's credit card was good, and maybe, just maybe, they'll only deliver the SSL certificate to an email address or web site that matches the keys they just certified, or do some similarly minimal level of validation. Some of the CAs, of course, require more documentation, charge more money, and provide methods for a user to validate one of their certificates other than using it and seeing if their browser flagged it. But not everybody uses those CAs - Microsoft.com probably does, and Microsfot.cm probably doesn't. So from a business/financial standpoint, you're in sort of the same condition you were in in the previous paragraph, except that you can rely on the financial guarantees that the CA gave you, the user of a browser that trusted their certificate, unless you didn't pay them anything, in which case you should also see figure 1.
Back to technology, there's the problem of whether a certificate is still good. That's backed by three things, expiration dates on the certificates, ability to validate a certificate chain, and revocation lists that the CAs provide to deal with the problem of certificates that were compromised before they expired. Expiration dates on most certificates tend to either be the remaining fraction of one year (because the CA is charging for them on an annual bases) or "already expired". And that certificate chain's useful, if the CAs on it are still in business and their certificates haven't already expired, unless their certification system has been compromised without being detected, in which case see figure 1.
And then there's the user interface issue - if you're directly using a browser, and everything's good, it'll probably turn a little lock icon green, which you won't notice. Otherwise, it'll give you a dialog box, "Security problem - See figure 1 [Click OK]", and you'll click OK, and you'll either feel fine, or you'll have this little nagging feeling that something was wrong, but you're not sure what.
And then there's the financial layer again. If the certificate was protecting your credit card number, and you're in the US, you're liable for at most $50 if it got stolen, and otherwise it was probably just protecting your Facebook account, in which case the worst that'll happen is somebody posting rude notes to your friends, or overwatering the shrubbery in your farm. So fundamentally, you don't care that the CA system is broken.
One of the advantages of having been one of the early cypherpunks is that I got to watch a lot of this stuff develop, see many of the things that were done right or wrong, and know a lot of people who are either much smarter than I am (too many of them to list here) or who went out and Did The Right Thing at the Right Time (special shout-out to the Netscape folks, who went and shipped encryption for free even though the legality was dubious, which not only catalyzed the internet commerce business but broke the government's anti-crypto stronghold.) Lots of the solutions that shipped weren't perfect, and lots of the solutions that were Perfect never shipped, and lots of the solutions people spent time on didn't have problems associated with them, but it did still transform the world.
Re: (Score:2)
I good post, but I really thought in paragraph 3 you were going to mention how CRLs are fundamentally broken (essentially advisory in nature due to implementation) -- or do you disagree with that?
Re: (Score:2)
Yeah, I probably should have gone into more detail. They're ok when they work, except when they're broken, which they often are, but the better alternative is short-expiration-time certs, unless you're also trusting already-expired certificates, which most people do, in which case both common approaches are broken.
Re: (Score:2)
Sorry. It's classic Intermet jargon from the days that figures were typically ASCII art. Here's the first example [googleusercontent.com] I found on Google.
DNSSEC could have been a better solution (Score:2)
If we had shipped DNSSEC back before web commerce became widespread, we'd be in a lot better shape. You'd be able to know that the public key you had for microsoft.com was owned by the people who'd registered the name microsoft.com with the .com domain registry, and that the public key you had for www.microsoft.com was certified by the people who owned the name microsoft.com. It's not perfect - you'd have just as much certainty that the public key you had for mocrosoft.cm was owned by the people who'd re
Re: (Score:2)
TSA Agents!
Re: (Score:2)
It's not like we have reason to think that other CAs have not had unreported blunders.
If they had, then someone should have copies of the fake certificates and could demonstrate that the CA was broken; any widespread use would have handed the cerfiticate to so many people that it should easily be provable.
Otherwise that's about as logical an argument as saying there's no reason to think that I have not slept with Natalie Portman.
Re: (Score:2)
problem is - for the people who break the CA's there is ALOT of money to be made. Very few people who that that chance would pass up the money to show the world that xCorp is corrupt.
Re: (Score:2)
problem is - for the people who break the CA's there is ALOT of money to be made. Very few people who that that chance would pass up the money to show the world that xCorp is corrupt.
They're not the ones who would be showing it. If you hack into xCorp and generate a fake certificate it's useless to you unless you then hand that certificate to your victims. Those victims can then show that certificate as proof that xCorp is handing out fake certificates.
Since no-one has shown such certificates for CAs who aren't yet known to be compromised, we can be fairly sure the others haven't been.
Of course that may be luck rather than good security practices.
Re: (Score:2)
Re: (Score:2)
if you have successfully created a fake cert from a CA - the only people who can verify that it is rouge are:
A) the CA via audit on what they have issued (which might not show it as fake as it might be in their logs)
B) the domain it says it's for, who ever owns it should be able to audit against their requested certs (for some places this might take awhile)
C) the person who faked it.
Notice NONE of the people are the end users, a actual faked cert from a CA is indistinguishable from an authentic cert from th
Re: (Score:2)
B) the domain it says it's for, who ever owns it should be able to audit against their requested certs (for some places this might take awhile)
Exactly. If I produce a certificate for www.google.com signed by BadCA, then you can easily verify that it's not the certificate that www.google.com is sending to you over SSL, and then Google can verify that it's a certificate they've never used. And if it's a CA that Google don't use then a simple 'there's something odd going on here' check is trivial ('why is www.google.com sending me a certificate from a CA in Nowhereistan?').
Re: (Score:2)
i'm sorry but do you not understand the basics of a Man In The Middle attack? and the value of a fake cert in that scenario?
in any decent MITM attack - if i'm trying to spoof google for you - then any request from you for google will go through me and i will respond with the right answer, currently under this scenario the 3rd party trusted CA on your local machine is the only way an end user has to verify that what i say is true or false.. compromising the CA in this case allows me to make a cert that you
Re: (Score:2)
Mandatory DNSSEC with public keys stored in the DNS record would achieve the exact same level of security without adding all sorts of unnecessary P2P traffic.
The only thing that the CAs ostensibly offered was some indication that the site was owned by an actual brick-and-mortar identity at some physical address, and when they switched to domain validation, even that advantage went away. Thus, they're basically vestigial. I similarly see no reason why a scheme like the one linked above would be any better
Re: (Score:2)
Doesn't DNSSEC still require a point of trust, the root dns providers in this case? How is that any better than we now have with SSL CA's?
Re: (Score:2)
it isn't - DNSSEC in it's current incarnation has the exact same single point of failure as the current CA system.
Also DNSSEC is useless to a local MITM as long as clients support normal DNS as you can arp poison clients to believe you are their DNS server and respond with no DNSSEC records for the host and use your faked CA cert.
the point of the p2p traffic is that for a MITM to work they would have to intercept all points of trust, which while not impossible is far more difficult than exploiting a single
Re: (Score:2)
Care to enlighten us? I don't believe that is even remotely true.
Assuming that in the future, all browsers treat a DNSSEC-secured address result and key in the same way as it currently treats a CA cert (such that a URL specified as https requires DNSSEC to prevent stripping of the security during the lookup process), then the DNSSEC model can only be compromised by compromising the domain itsel
Re: (Score:2)
so your saying that just because you are reducing the number of CA's (global trusted CA's now to the domain registrars) that while it makes the # of targets less does not remove the single point of failure?
i'd like to point out to you your own "Microsoft" example.. VeriSign who is Both a CA and a registrar has already in the past, before we had nearly as many registrars and ca's, given a code signing cert to unknown people for "Microsoft Corporation".
http://technet.microsoft.com/en-us/security/bulletin/ms [microsoft.com]
Re: (Score:2)
sorry you didn't point out "Microsoft" that was another poster above you sorry - but my point still stands.
Re: (Score:2)
I'm saying that it dramatically changes the equation. With DNSSEC, I (as the owner of a domain) only need to worry about whether my choice of registrar is secure. With the current CA scheme, I have to worry about whether every CA is secure.
More to the point, someone compromising a registrar can compromi
Re: (Score:2)
i will agree with you - but for now DNSSEC is only useful against MITM once users stop supporting traditional DNS.
Re: (Score:2)
Not really. The OS doesn't hide whether a response was encrypted or not from applications. The way Chrome supports DNSSEC is that a DNSSEC response is valid for https, but an unencrypted DNS response is invalid unless the site is signed by a CA cert. I'm assuming that all browsers supporting DNSSEC will do the same.
So it's more correct to say that DNSSEC is only useful against MITM once browsers stop accepting certs from traditional CAs. :-)
Re: (Score:1)
this is true.. really a faked cert from a CA.. isn't fake.. it's real. it's like getting your "fake" ID from the DMV..
Re: (Score:2)
Otherwise, it's like getting your "fake" ID from whatever the DMV is called in the Netherlands.
Re: (Score:1)
Re: (Score:2)
But it is two (A LOT) and /. doesn't let you edit posts..
I'm so glad that a single missing space is more important to you then the discussion of weather the CA's we use to trust transactions on the internet are, well trustworthy.
Re: (Score:1)
ALOT ISNOT AWORD
no but as has been proven, with your support and less than 15 cents a day.. it could be. that's not alot.
http://news.yahoo.com/merriam-webster-adds-tweet-other-words-095422189.html [yahoo.com]
Re: (Score:2)
I care about this Alot [blogspot.com].
Re: (Score:2)
I am soooo jealous.
I assume you are truthful in all your statements.
Re: (Score:2)
Unless nobody happens to have noticed because the the browser display for a fake (but "valid") cert and the genuine article are identical unless you right click-page info-security just to be sure, exactly like practically nobody ever does.
Excellent (Score:3)
Hopefully this will get the others CAs worried and motivate them to get better security.
Re: (Score:2)
Why?
They had a good run with no security at all and could pocket lots of money because of that. Clearly the lesson here is to not do any security, fold up shop if you lose accreditation and start up another CA.
Re: (Score:2)
Your argument only works if several conditions are met:
A) They made more money than the fallout is going to cost them. It isn't cheap to close down a major business, there are lots of bills to be paid and lots of backseat accountants from both the creditors and the government making sure you don't fudge the math in your favor.
B) The people who profited DigiNotar have enough capital or credit left over to start another major corporation
C) Most doubtful of all, that they can convince people to trust them aga
Re: (Score:2)
A) the CxOs will get their golden parachutes first, and that will be legal since employees are paid before anyone else.
B) See A
C) They will then buy up a small CA to get its trusted status. For profit colleges do this all the time. They buy up small struggling universities/colleges just to get their accreditation.
Re: (Score:2)
Re: (Score:2)
In a free market, if you can sell certificates for $5 with lousy security and $10 with decent security, and you have a 10% risk of losing everything with lousy security and 0% with decent security, the companies with decent security go bankrupt rapidly. After all, why pay $10 when you get the same for $5? A breach of ANY registrar is as bad as a breach of YOUR registrar.
The Price Of Trust (Score:5, Insightful)
And good riddance to them... (Score:5, Insightful)
If you won't properly separate your security-critical systems from your Internet-facing systems, or cannot even keep them from being rooted multiple times, you have no business being a CA.
Honestly, it's understandable DigiNotar didn't want this information out: bankrupcy is inevitable now, and that's bad for shareholder value.
Re: (Score:2)
Yeah, it's pretty hard to avoid bankruptcy when your primary business has been shut down.
Re: (Score:2)
I wonder why they don't just wind down all activities and give up. That has to be the cheapest way to resolve this. I don't think even a name change will help them now.
Re:And good riddance to them... (Score:4, Informative)
The Dutch government took over operation of the company more than a week ago. It is basically already defunct.
http://www.govcert.nl/english/service-provision/knowledge-and-publications/factsheets/factsheet-fraudulently-issued-security-certificate-discovered.html [govcert.nl]
Re: (Score:2)
Well, in SCOs case it took some time....
Re: (Score:2)
By chance I walked by their HQ the other day (it's across the street from our obstetrician's office). Place looked like a ghost town. No activity or people visible inside (not that I went up and stuck my face to the glass), no comings or goings.
Re: (Score:2)
Nope, it's owned by VASCO [wikipedia.org], which is publicly traded.
Re: (Score:2)
If I were a bankruptcy judge - I would NOT grant protection. Throw them to the wolves. The individuals should be held personally liable.
Unfortunately... (Score:2)
Re: (Score:2)
Or, to look at it from a business perspective, no meaningful liability until someone can press some kind of human-rights-related lawsuit. Whereas if money had been lost, LOOK OUT.
Sounds like Diginotar came out ahead in the client liability front.
"Certificate Blunders May Mean the End.." (Score:4, Insightful)
I'm sure they're already working on this (Score:2)
This is a popular Dutch comic: http://foksuk.nl/nl?cm=79&ctime=1315260000 [foksuk.nl]
The guy on the left says something like "Don't panic, people. In about three months..." and the other guy continues: "...we'll have a different name and a different corporate identity!"
revolving door (Score:2)
it's good to know that crows are equally black everywhere [yahoo.com]
Re: (Score:1)
What did they think was going to happen? (Score:1)
Having your product proved defective spells the end for most companies, GM almost went under and they are 1000x the size. PR and image > everything.
Shame certs are set up in a manner where it is very difficult to fix... anything wrong with them. I believe in the whole handshake principle, but why are there root certs on my computer by default? I feel I should have to sign a EULA for those outside of the windows EULA.
Sure it's inconvenient, but I really really really don't need MS or DigiNotar
More hush hush (Score:1)
So if this happened to one CA who got compromised what makes you think others will now disclose they were hacked?
If it happens again to someone else they sure as hell wont announce it as any CEO will want to keep his job more than protect the web. If anything this could make the web less safe
Re: (Score:1)
Already dead (Score:5, Interesting)
This is just going through the motions. DigiNotar has been dead since August 30, when Google, Mozilla, and Microsoft all revoked trust in their certificates. Anyone with at least two brain cells (which seems to exclude a large number of managers, unfortunately) could see the writing on the wall. No one would ever buy a new DigiNotar certificate, since it would always pop up a scary warning to the user in a web browser. Why bother with buying a certificate from DigiNotar and dealing with the resulting end-user support issues, when you can buy from someone else and not have to deal with the problem?
More interesting to me is what will happen to DigiNotar's corporate parent, Vasco Data Security? The purchase of DigiNotar is relatively recent (January 10, 2011), so it's not clear how much influence Vasco's management had over DigiNotar's operations. At the very least, Vasco is going to need to pay for an audit of its own systems to reassure its direct customers.
--Paul
Too bad ... (Score:2)
Akamai issues SSL cert for www.ice.gov (Score:2)
On a related note, take a look at the certificate on www.ice.gov [ice.gov].
The certificate hierarchy is
Now that's interesting, and worrisome. Akamai possesses a wildcard subordinate CA cert that permits them to impersonate any site, even U.S. Government sites. Even the chief security officer of Akamai is worried about this. [csoandy.com]
Re: (Score:1)
Re: (Score:2)
The problem is that Akamai, which is not a CA, has a cert which gives it the powers of a CA.
SSL needs national/international backing (Score:1)
Why can't we have quangos do the signing? Governments can sign for companies, performing EV using their large, centralised databases of companies (e.g. Companies House in the UK).
Individuals may be signed off by the domain registrar subject to receiving basic identity documentation as individuals don't really need full EV'ing for their personal sites.
Anonymous individuals can be signed by a 3rd party and warnings can be given in-browser as to how the identity has not been verified.
Problem solved.