Slashdot Mirror
Certificate Blunders May Mean the End For DigiNotar
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."
If you can't play the game, you pay the pain.
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 anymore, rather than just handing out free master keys to anyone with a big enough wallet or gun.
#fuckbeta #iamslashdot #dicemustdie
It's not like we have reason to think that other CAs have not had unreported blunders. In fact, we have every reason to think that the whole CA system is broken, and is just hanging on because nobody is willing to put in the effort needed to replace it.
Palm trees and 8
Hopefully this will get the others CAs worried and motivate them to get better security.
If getting compromised and issuing bad certificates *didn't* cost you your position of trust, then what credibility would the certification process have anyway?
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.
Error: password can't contain reverse spelling of ancient Chinese emperor
Those responsible at Diginotar are unlikely to feel anything more than (possible) economic consequences. Based on the location of the MiTM attacks, their incompetence wasn't responsible for some penny-ante credit card scamming, it was employed to advance surveillance by a somewhat ideologically touchy state. It would be entirely within the realm of possibility that somebody is doing hard time right now because they fucked up...
What.. you reckon? They were tasked to do ONE THING and ended up in an epic case of fail and pwnage.
Never email donotemail@WeAreSpammers.com
This is a popular Dutch comic: http://foksuk.nl/nl?cm=79&ctime=1315260000
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!"
Pretty good is actually pretty bad.
include Pidgy and Dragonite. both are formidable but the latter is a fully realized dragon type so its pretty powerful.
Good people go to bed earlier.
it's good to know that crows are equally black everywhere
ELOI, ELOI, LAMA SABACHTHANI!?
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 telling me what/ who to trust out of the box. Maybe I don't want to trust microsoft.com cause ms just got owned by a monopoly suite..
The correct implementation would be every site has a cert and YOU choose which ones to trust, this would require the browser to implement features such as warnings on when a cert is expiring as well as user education, but if you want security, you typically need to trade convenience for it, thus my banks 4 step login process, I had to re-memorize my answers several times and call customer service twice to unlock my account, but in the end, its nearly impossible to break at least through front facing means make sense? Such is life.
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
http://saveie6.com/
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
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 banks and all those CDOs as AAA low risk, when many of them were in fact Junk--, and they're still around. But Diginotar doesn't have the same level of governmental backing that the US rating agencies have.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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 primarily the authentication of the party at the other end of the connection.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
What is different?
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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 registered that name with the .cm domain registry, which wouldn't tell you anything about whether it was really Bill Gates's company - but at least you'd know that if you were talking to www.microsoft.com, the only people who could eavesdrop were the people who ran the website you were talking to.
There were organizational/political reasons this didn't happen. The NSA/FBI/etc. used the anti-Communist ITAR rules to prevent export of DNSSEC code, even a "bones" version that John Gilmore developed that didn't include the crypto modules, and the RSA patent made it difficult to use it even in the US. And once ICANN took over the domain name business, it was obvious that the only IP they cared about was Intellectual Property, not the Internet Protocol, and they dragged their heels for years, probably partly as a favor to the US government, who'd given them their quasi-monopoly position and could take it away from them if it wanted.
There were also technical issues - the protocol had to make tradeoffs between the people who wanted perfect security and the people who wanted scalability, and while certifying the properties of domain names that do exist scales really well, certifying the non-existence of domain names that don't exist is a lot trickier, but the perfect-security folks thought it needed to be done. And error handling is hard - DNS resolvers usually live at a part of the protocol stack and applications infrastructure that doesn't have a user interface, and they have to handle cases like "here's the IP address but the certificate's invalid, do you want to connect anyway?" and "here's the IP address but the cert's invalid" and "that IP address has a reverse-lookup that resolves to 42 different names, 13 of which have matching forward certificates" and such.
It's not like the current CA system doesn't have serious problems as well, but it did get there first, which carries a lot of infrastructural weight, especially when the people running the DNS system are also selling CAs.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Certificate authority, runs Windows. Amazing.
http://nakedsecurity.sophos.com/2011/09/05/operation-black-tulip-fox-its-report-on-the-diginotar-breach/
Thank god they're closed.
Only seeing their CEO being t-bagged would be better than bankruptcy.
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 gmail certificate.
It's not the metadata that's the threat during a phishing attack. The threat comes from being a CA-signed cert, which, regardless of the name in the cert, your browser tells you is "secure".
Or maybe you're saying that CAs protect against people registering look-alike domains? I doubt that.
And (simple) notaries don't mark certs as valid, they report them as seen. Then you (via configuration of your software) decide on what is valid.
I would believe a handful of trusted notaries who all say they've seen gmail.com using certificate abc123 for a whole week. More so than I would trust when just one of several hundred race-to-the-bottom CAs in my browser says that certificate xyz789 is gmail.com.
It's still a CA, except one that follows a different policy. It's just as breakable. What guarantee do you have that their servers return accurate information?
I think maybe you're not clear on the concept of notaries or "multiple perspectives". Or "trust agility".
Anyone unclear on the concept should check out this great video on how notary systems work.
Have gnu, will travel.
On a related note, take a look at the certificate on www.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.
Can somebody explain what is different between the DigiNotar case and the Comodo case earlier this year? The two cases look similar, but Comodo is still truested and DigiNotar is not. I hope it is not because Comodo issued so many certificates that it would be inconvenient to not trust them anymore.
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.
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...
And, anyway, this scenario assumes you can block the notaries. Anyone can run a notary. Not everyone has to publicize their notary.
The notary list is public.
There is a public notary list. But it is not the only list and it's not comprehensive. Anyone can run a notary. The larger and more diverse the ecosystem of notaries is, the healthier the scheme. How many people run their own DNS or NTP servers? How will you block all possible notaries?
What if the client itself is running multiple notaries that use proxies on the wider net to get certs?
I strongly suspect the nature of notaries is not being understood.
It will happily mark as valid a certificate for gma1l.com, with the metadata copied from the gmail certificate.
It will do no such thing!
That's pretty far from how notaries work.
I must say I find it very frustrating to see you going on with apparent certainty regarding something you evidently don't understand. And it should be obvious to you that you don't understand it. And you appear resistant to clicking a link and watching a video that would clarify it for you. You, sir, owe me an apology.
Granted, the video is a little long. But I implore you to weigh that against the time you'll spend misinforming people and creating pointless argument, among other problems.
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 get anything. The worst thing they can do is to use their CA to emit a valid cert for gmail.com and spy on me that way. That is a big problem, but I can remove the chinese CA from my system. Certainly this isn't perfect at all, but workable to some extent.
Now Convergence: if Convergence is blocked I can still connect to gmail. And if they firewall it off country-wide I have no way to reach it at all. One needs to be really dedicated to security not to say "ah, screw it" and resist checking the mail over a possibly insecure connection. With CAs I can try to find a secure site that the government isn't intercepting. With Convergence being disabled it's all equally unclear.
Which is cool and all but not very helpful. First, if the notaries aren't published anywhere, how do people find about them? Very very few people are going to run their own notary. Few people understand all this stuff, and even fewer have the means to run a notary that has a different perspective than their own.
Second, I can go set up a notary right now. Will you trust it? Why? If not, then how do you determine when to trust a notary? If you use custom notaries how do you bootstrap the system? That is, how do you, before the system that checks certificates is ready, check the certificate for the notaries that compose it, so that you know you're talking to the notary you wanted to talk to?
Third, picture the system 10 years in the future. We have 10 competing services in the style of Convergence, at 10000 notaries run by various people. How do you decide which are trustworthy and secure? How do you deal with the possibility of somebody setting up lots of notaries with an extra feature to let MITM go undetected sometimes, or lots of notaries becoming unmaintaned and insecure? Somebody has to police this stuff, but who?
They mostly run them on their own network, which is pointless for this application. Your notary would see the same perspective you do, contributing nothing useful.
I strongly suspect the same on your part, or more precisely that you're not thinking enough of issues like how does one determine what is a good notary to use, and how to bootstrap the system.
You're basically setting up your own trusted CA list. Suppose you clear your browser's CA list and start from scratch. How do you decide whether to trust Verisign, and how do you make sure it's really Verisign without a working authentication system?
Alternatively, you're trusting somebody else to provide you with a list of notaries, but that's easily blockable.
Another thing: why do you trust Convergence? Is making a good presentation all it really takes to convince you to install a plugin that overrides how your browser does security?
Sure it will. Nothing in the video contradicts it.
If I have gma1l.com, make a cert with CN: gma1l.com and "Google Inc" in the organization field, both
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 update? Eventually we discovered there were more than one cert:
Handling that is not very workable.
And what if the CA is someone like Verisign? Do you remove Verisign? And make a quarter of HTTPS connections show up as invalid? Too big to fail is another failure of trust agility.
And did you know that Diginotar's website had been hacked as far back as 2 years ago? And they never noticed or fixed it until now. Could their CA cert have been compromised then? 2 years of exposure, without a hint so we couldn't have removed the certs even if we knew which ones were relevant.
And there are over 500 organizations your browser trusted in addition to Diginotar. What are the chances that any one of them is being run badly? Or, the better question, how many other Diginotar-alikes are sitting in your browser at this very moment? The logical OR of the current browser CA system is a failure.
I assume "it" refers to notary access. I pointed out earlier that firewalling by protocol or port would be problematic because Convergence notaries use HTTPS.
And if they managed somehow to block all notaries by identifying some quality of the requests, you might still be able to access them via web proxy or SSH.
And if they managed somehow to block all notaries by identifying some quality of the requests, and they could block all web proxy and SSH connections, you would still likely have a cache of important sites' certs.
And if they managed somehow to block all notaries by identifying some quality of the requests, and they could block all web proxy and SSH connections, and you didn't have a cache of important certs, the Convergence protocol is extensible such that a local notary could return its "OK" or "NOK" based on results from any method it chooses, not only "whether seen". Notaries could use DNSSEC, or "whether seen" via Tor, or a PGP Web of Trust, or even the existing CA system. You could have such a notary running locally as a fallback.
Where the CA system requires only one -- just one CA -- out of half a thousand organizations to vouch for a cert -- and you have no choice about it using that method -- notaries-based systems can be configured to require some number/percentage of notaries to agree, out of a quorum. Who you trust and how you trust them is your decision. And you can change your mind.
The system is in the process of be
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
That's why I'm advocating for multiple signatures
I see the same problem existing with notaries, except worse, because notaries will be much less monitored.
You don't understand firewalls. Firewalls act on IP addresses and ports. They do their work before a SSL negotiation can begin, making SSL entirely irrelevant.
I assume you're thinking about filtering proxies.
Sure, but now checking your mail involves finding and using a proxy, or caching certs in advance. Convenience is an important part of security. Nobody will bother with it if it requires arcane incantations every time.
I am thinking about it, which is exactly why I'm having this argument.
How do you know it's the EFF notary? Again, you need to bootstrap your system. How does that work?
Bad examples. DNS is inherently insecure, and SSL specifically tries to ensure that DNS issues get noticed. Tor has an entirely different security model. SETI doesn't have anything to do with anything and is not externally accessible, and any uptime for it is completely optional.
As a security critical service, a notary has requirements that none of those have.
I'm not sure this works long term. It seems too maintenance intensive. If you leave that to the end users, it will end up going very wrong sooner or later, I think.
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.
Notaries are different from CAs.
If any one CA tells you a site is good, your browser says it's good. So if any one CA fails, your security is broken. And in a bad way. A false positive way.
If any one notary fails (or, more precisely, conflicts with other notaries) your system should take note. And with enough other notaries in operation, as the system is meant to be used, you continue without problem. (Indeed, notaries could be monitored (by your system, as you use them) and notary judgement could be weighted by longevity of good service.) If a notary fails, it's not a problem, it's an anticipated design constraint.
Compromised notaries are accounted for as a fundamental part of the technique. So it is clearly not the same problem as compromised CAs.
I understand firewalls. Pardon me if I haven't been clear.
The point is that you can't block notaries by IP because virtually any machine on the net can be running a notary (which is why I mention DNS and other such services, for their virtue of being easy to run by sysadmins the world over). Nor can you block them by port because they use 443. Nor can you block them by deep packet inspection, because they use TLS/SSL. Thus SSL is relevant.
You said manual CA list editing was an acceptable solution in a worst case scenario. Yet reconfiguring a notary list is off limits? You'll have to distinguish the two so this doesn't look like self-contradiction.
And note that cert caching is a part of the design. Invisible to the user, not an "arcane incantation". This information was in the video. When you say things like this it makes me think you're trolling.
I'll take that as your concession that trusted organizations could indeed be reasonably expected to run notaries.
Yes, the bootstrap is the part I'm mulling over. What ideas do you have for it?
Notary list management could even be done automatically. Come on, put your imagination towards making it work, not just tow