Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Diginotar Responds To Rogue Certificate Problem

samzenpus posted about 3 years ago | from the our-bad dept.

The Internet 177

An anonymous reader writes "Vasco, the owner of the DigiNotar CA implicated in the MITM attacks on Iranian Google users has responded to their fraudulently issued certificate problems. The press release reads: 'On July 19th 2011, DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure, which resulted in the fraudulent issuance of public key certificate requests for a number of domains, including Google.com. Once it detected the intrusion, DigiNotar has acted in accordance with all relevant rules and procedures. At that time, an external security audit concluded that all fraudulently issued certificates were revoked. Recently, it was discovered that at least one fraudulent certificate had not been revoked at the time. After being notified by Dutch government organization Govcert, DigiNotar took immediate action and revoked the fraudulent certificate'. It is not clear whether the latter certificate is the one used in Iran, or whether other certificates remain at large. I guess removing the root certificate from browsers is the correct response."

cancel ×

177 comments

Sorry! There are no comments related to the filter you selected.

Wasn't a forged certificate a big part of Stuxnet? (1)

elrous0 (869638) | about 3 years ago | (#37254198)

Looks like the Iranians learned a neat trick from that attack.

or you can be sure that iranian authorities don't (1)

gl4ss (559668) | about 3 years ago | (#37254296)

or you can be sure that iranian authorities don't interfere.

were all victims from iran?

Re:Wasn't a forged certificate a big part of Stuxn (2)

Z00L00K (682162) | about 3 years ago | (#37254522)

DigiNotar CA is now removed from my list of trusted root CA:s.

I propose that all web browsers and other application should do the same since it's not certain how many compromised ones there are out there.

Or that the private key for the root CA was kept safe.

Re:Wasn't a forged certificate a big part of Stuxn (1)

Relayman (1068986) | about 3 years ago | (#37255204)

Confirm that it is in fact removed. The last time I tried that (IE 6?), it reappeared the next time I started the program.

Re:Wasn't a forged certificate a big part of Stuxn (2)

Ossifer (703813) | about 3 years ago | (#37256598)

If you are still using IE6 you have bigger problems than diginotar...

Re:Wasn't a forged certificate a big part of Stuxn (1)

Smallpond (221300) | about 3 years ago | (#37255914)

Should also check the bank accounts of DigiNotar employees to see if any got an unexplained bonus.

Re:Stolen, not forged (0)

Anonymous Coward | about 3 years ago | (#37254624)

It was a stolen certificate belonging to Realtek Semiconductor Corp. I found a piece of malware - not stuxnet - signed with the same cert. I imagine it was popular for a time in the underground, as it was entirely valid and trusted.

Just another case of the SSL model being flawed. The CA can issue whatever they like, and we implicitly trust everything they issue. Or the owners of the valid cert can cough up their private keys.

So they don't know... (3, Insightful)

iCEBaLM (34905) | about 3 years ago | (#37254224)

... how many forged certs are now in the wild? Nuke the CA, they are incompetent.

Already done (1)

oGMo (379) | about 3 years ago | (#37254300)

I just removed the trust setting from this CA in my browser. So can anyone else. Anyone know a site for which they've issued a cert to test and see if this actually makes any difference?

Re:Already done (0)

Anonymous Coward | about 3 years ago | (#37254438)

Google.com (see http://www.mediafire.com/?rrklb17slctityb via https://www.google.com/support/forum/p/gmail/thread?tid=2da6158b094b225a&hl=en)

Seriously, were you not paying attention?

Re:Already done (1)

oGMo (379) | about 3 years ago | (#37254590)

Um, no. Google's true CA is not DigiNotar, but Equifax, according to the cert from encrypted.google.com [google.com] . The rogue MITM cert for *.google.com was issued by DigiNotar, but there's not really a way to test this without altering DNS to point to the rogue site. Also, that cert was already revoked ("were you not paying attention?"), and I want to test revoked trust for all DigiNotar.

This should be obvious.

Re:Already done (1)

Meumeu (848638) | about 3 years ago | (#37254644)

Um, no. Google's true CA is not DigiNotar, but Equifax,

Whoosh

Re:Already done (2, Informative)

Anonymous Coward | about 3 years ago | (#37254528)

check their site, they sign their own certificate ::

https://www.diginotar.com/Products/ExtendedValidationSSL/tabid/622/Default.aspx

Re:Already done (-1)

Anonymous Coward | about 3 years ago | (#37254968)

check their site, they sign their own certificate

Wow, and I have the key to my own house. Quite an earth shattering observation there Sherlock.

Re:Already done (1)

Lieutenant_Dan (583843) | about 3 years ago | (#37254588)

Same here; Vasco and DigiNotar are gone in our QA instance of Firefox. Will push the change across all desktops in the next week.

Re:Already done (1)

xaxa (988988) | about 3 years ago | (#37254592)

I just removed the trust setting from this CA in my browser. So can anyone else. Anyone know a site for which they've issued a cert to test and see if this actually makes any difference?

Their own [diginotar.nl] (it just redirects to the non-SSL site, but that should be sufficient for you).

Re:Already done (1)

master666 (246477) | about 3 years ago | (#37254886)

Hey, DigiNotar.
Welcome and join fellow Comodo on my blacklist. Have fun our there.
Looking forward who's next...

Re:Already done (2)

ComaVN (325750) | about 3 years ago | (#37255524)

A lot of (most?) dutch intra-government traffic uses their certificates.

See https://loket.amsterdam.nl/ [amsterdam.nl] for instance

Re:So they don't know... (1)

GSloop (165220) | about 3 years ago | (#37254378)

True enough....

But the whole framework behind certificates and CA's is the problem. This is just a symptom of the problem.

Moxiespike: "Who are you going to trust, and for how long?"
If the answer to how-long, is forever - then you probably have a problem.

The problem is there's no real way to handle problem CA's - and you don't get much choice, and the system is too moribund and static to respond to problems like this.

So, yes we can fix this *specific* problem by getting every browser to re-work the trusted CA's and then get everyone to install the new browser with the new set of trusted CA's.

But that will still leave a small group of people making choices about YOUR trusted CA's. And the latency to make those changes is *very* high.

Not much of a solution, IMO.

Truly, everyone should take the time to listen or read Marlin Moxiespike's proposal.

Moxiespike at BlackHat USA 2011 here [youtube.com] .

Read about it. [infosecurity-us.com]

Re:So they don't know... (1)

pwileyii (106242) | about 3 years ago | (#37254566)

Trust should be earned, not simply given by some authority. Every CA is not the same when it comes to how much I trust them. I'd be much more pleased with a web of trust type system for CAs than an all or nothing approach. What would it take now for a CA to get removed from all of the browser's list? I think it would be a very significant, incompetent act otherwise, they remain trusted. That is not a good system.

Re:So they don't know... (0)

Anonymous Coward | about 3 years ago | (#37255164)

I agree. Trust is not boolean anyway, so why pretend it is?

A web-of-trust type of system makes more sense than the current system. That, coupled with a certificate storage/verification system (similar to the "Certificate Patrol" firefox addon) would go a long way.

The trick is to save (at least for important websites, like gmail or your e-banking thing) all certificates that you're given and compare them with past certificates. If the signing authority chain changes (e.g. you get a certificate signed by diginotar for *.google.com, when you usually would get one signed by equifax), you should get a warning from the browser (like the ones you get when you get a self-signed cert), because something might not be right. This would thwart most MITM attacks, because they're usually intermittent in time.

Those simple things, coupled to a web-of-trust system (to check if you should take the first certificate you get from a certain SSL identity as authoritative or not) would probably improve the current SSL public key infrastructure for sure...

Re:So they don't know... (1)

icebraining (1313345) | about 3 years ago | (#37255364)

Of course, Convergence relies on the user having any clue whatsoever of whether (s)he should trust a particular Notary or not.

We're talking about users who use the same password repeatedly, who use mostly 6 and 7 char passwords, who use 'password' and '123456', etc.

Re:So they don't know... (1)

Smallpond (221300) | about 3 years ago | (#37256034)

The web has a problem. How do we tell if a URL is trustworthy?

I know, lets create certificates backed by certificate authorities!

Now the web has two problems.

Re:So they don't know... (1)

Z00L00K (682162) | about 3 years ago | (#37254448)

Especially since even if you revoke a certificate it still requires that someone checks the revocation list - and if you are behind a wall or suffer from a man in the middle, can you be sure that the revocation list is the correct one?

Once a CA is failed - it's completely and utterly failed as a trusted entity. And if someone got hold of the private CA key - then it's a clusterfsck.

Nuke the root from orbit (0)

Anonymous Coward | about 3 years ago | (#37254258)

It's the only way to be sure.

Don't they have an air gap? (0)

Anonymous Coward | about 3 years ago | (#37254282)

WTF? Don't they keep their certificate issuing system on a separate network from their regular corporate network, with an air gap? Any CA worth its salt does that.

Re:Don't they have an air gap? (1)

0123456 (636235) | about 3 years ago | (#37254418)

Cost, I presume. With an air gap someone has to physically take a USB key to the other machine to get the key signed, and that adds cost and people want to buy certs cheap.

Of course the end user who's relying on those certs has no way of ensuring that they weren't generated by a cheap CA which doesn't take serious precautions to prevent this kind of thing.

Ultimately the whole CA system is broken because any company can issue any key for any site, so we're all reliant on the least secure CA that the browser trusts. Worse than that, the browser doesn't even tell you that they key has changed unexpectedly (e.g. without the old key expiring), which would go a long way toward eliminating these kind of attacks.

Re:Don't they have an air gap? (1)

roman_mir (125474) | about 3 years ago | (#37254980)

that's unnecessary. Build a machine with OpenBSD on it, put a write only disk into it for sharing, 2 separate network cards and then create an account for using scp between the machine and network 1 and machine and network 2. Have network 2 generate the certificates and be off the Internet, but have network 1 be on the Internet. Poll the files from the machine every once in a while.

Re:Don't they have an air gap? (1)

0123456 (636235) | about 3 years ago | (#37255570)

How does that help? If the key-signing computer just signs any keys submitted to the intermediate system then anyone who hacks into the network can send keys to the intermediate system and wait for the signed certificate to appear there.

Re:Don't they have an air gap? (1)

roman_mir (125474) | about 3 years ago | (#37255736)

I am only talking about having the certificate issuing computer on a network, loosely connected to the network that is connected to the Internet, only talking about not needing a 'USB data transfer' approach. So this would prevent the certificate issuing system from being compromised and that is important, since CA's private keys are there (and the signing code is there).

As to the other question of how should anybody be prevented from submitting requests to have certificates generated for domains that do not belong to that requester - I am actually quite against CAs in the first place and that's part of the reason - I don't know who submitted the request and who the hell is signing it.

Re:Don't they have an air gap? (1)

0123456 (636235) | about 3 years ago | (#37256014)

So this would prevent the certificate issuing system from being compromised and that is important, since CA's private keys are there (and the signing code is there).

But... they... don't... need... those... keys.

Their goal is to get fake keys signed. If they can break into your network and submit their fake keys to the signing system and get signed certificates back, then they have succeeded. Obviously stealing the signing keys would be better, but so long as they can get the fake certificates they want, then they don't much care.

All you've done is converted an attack on the signing computer into an attack on the intermediate computer. That's a difference that makes very little difference.

Re:Don't they have an air gap? (1)

roman_mir (125474) | about 3 years ago | (#37256088)

Yes. But we are in a thread that discusses an "air gap" that's all. You are not in a thread that discusses how to prevent false requests from being processed. The air gap wouldn't have prevented that either and this is not what we are talking about in this specific thread.

To fix the problem that you are talking about - the false requests planted by whoever SUPPOSEDLY (and I don't believe that it is what happened there) broke into the system you need to have something else altogether. There has to be a way to verify that the request itself is legitimate. I in fact had to deal with this, I actually got a CA to generate a certificate for a company and send it to me, they didn't really know who they were talking to. This happened maybe 5 years ago and I am not going to get into specifics of what CA and what company that was.

Re:Don't they have an air gap? (1)

Smallpond (221300) | about 3 years ago | (#37256068)

An air gap won't help. This was almost certainly an inside job with the intrusion blah-blah as a cover story. Somebody was paid.

In Firefox 6 (4, Informative)

janeuner (815461) | about 3 years ago | (#37254292)

1) Options -> Advanced -> Encryption -> View Certificates
2) In the Certificate Manager window, click the Authorities tab.
3) Scroll down to DigiNotar.
4) Delete or Distrust the "DigiNotar Root CA" certificate.

Re:In Firefox 6 (2)

GameboyRMH (1153867) | about 3 years ago | (#37254326)

And do the same for Comodo while you're at it.

Re:In Firefox 6 (1)

Necroman (61604) | about 3 years ago | (#37254358)

And do the same for Comodo while you're at it.

Care to explain why?

Re:In Firefox 6 (3, Informative)

janeuner (815461) | about 3 years ago | (#37254428)

In short, Comodo has issued fraudulant certificates for Google Mail, Yahoo, and a couple other high traffic sites. Gameboy is correct - nuke both of these CAs immediately.

Re comodo (1)

v1 (525388) | about 3 years ago | (#37254648)

The sucky part of that is that's who I get my email pgp keys from. But really there needs to be a tiered CA system, where a CA is providing certs to anyone that asks, to people that have to prove themselves, and to government and other trusted sources. The way things are now, pulling the plug on an entire CA is the nuclear option.

Re:Re comodo (1)

janeuner (815461) | about 3 years ago | (#37254842)

I agree that government would be a logical choice to provide this service. It would be sensible to build a geographic web of trust, where citizens authenticate themselves with the municipality, the municipalities trust the governors, and the governors trust one another.

I would also enjoy the conspiracies that this model would create.

Re:Re comodo (0)

roman_mir (125474) | about 3 years ago | (#37255016)

I would never in my entire life trust a gov't of any kind to do this work (or any other work either.)

Re:Re comodo (0)

Anonymous Coward | about 3 years ago | (#37255180)

I would never in my entire life trust a gov't of any kind to do this work (or any other work either.)

Indeed. The one organisation you can trust to issue fake certificates is the government.

Re:Re comodo (2, Insightful)

hedwards (940851) | about 3 years ago | (#37255226)

That's because you're a paranoid wingnut. Believe it or not there are some jobs best left to the government. If you genuinely feel that way, Somalia is =========> that away.

Re:Re comodo (1, Troll)

roman_mir (125474) | about 3 years ago | (#37255288)

there is no longer a single job that I can point at and say: gov't can do this or should do this or must do this. Anything I look at and I see gov't in there, I know it's all completely screwed up.

BTW., that's why people came to USA - for less gov't. Now they have to go to Somalia all of a sudden? I believe attempting to fix what is found locally is the first thing to do.

Re:Re comodo (1)

GameboyRMH (1153867) | about 3 years ago | (#37256214)

Most don't want to "fix" the US the way you do.

Re:Re comodo (1)

roman_mir (125474) | about 3 years ago | (#37256290)

Oh, they have no choice. The country is bankrupt, so it's either going to become the next United States of Soviet Republics moving to the next logical step: Union of Soviet Socialist Republics or it will return to its roots of personal liberties and freedoms and limited government machine.

See? Not limited personal freedoms and overpowering government, but the opposite of it - limited government and maximum of personal liberties and freedoms.

I think most Americans would rather be free than not.

Re:Re comodo (1)

GameboyRMH (1153867) | about 3 years ago | (#37256416)

They do have a choice, whether it's the right choice is irrelevant, the vast majority will not vote the way you do so your "fix" is quite impossible to pull off in the US.

Re:Re comodo (1)

roman_mir (125474) | about 3 years ago | (#37256502)

You are correct, so the future of me either having a business in USA or not (business which is not in USA now) depends on the outcome of US presidential elections AFAIC. Ron Paul wins - I bring my business into USA, anybody else wins - I won't deal with USA most likely, because it will be lost and I'll keep dealing with emerging markets.

Re:Re comodo (0)

Anonymous Coward | about 3 years ago | (#37255384)

Or put another way, if you don't like it you can GIT OUT.

Re:Re comodo (0)

Anonymous Coward | about 3 years ago | (#37255392)

That's because you're a paranoid wingnut.

No, it's because you can absolutely guarantee that if the government has control over encryption certificates they will be issuing fake ones so they can spy on criminals. Where 'criminal' will start by being evil terrists and soon progress to people who don't put their recycliing in the correct bins.

There is no government in the world which could resist using that power to 'prevent crime'.

Re:Re comodo (2)

Archangel Michael (180766) | about 3 years ago | (#37256494)

Somalia has no functioning government, and therefore does not protect the LIBERTIES of the individual, which is the purpose of government.

Re:Re comodo (1)

unencode200x (914144) | about 3 years ago | (#37255198)

If the government was to do this they would also have the power to intercept these private communications. Granted.... it's only transport layer encryption.

Re:Re comodo (1)

datapharmer (1099455) | about 3 years ago | (#37256294)

How about we all just provide the public key via a nameserver record and cut the CA out of the mix altogether. Use secure DNS and you are good to go.

This makes it worse! (1)

Manip (656104) | about 3 years ago | (#37254334)

So not only did they hide a break-in from the internet at large, including companies (e.g. Google) which were by extension the target, but they also aren't able to tell how many or what kinds of fake certificates got generated by the break-in? If you ask me their entire CA needs to be revoked, and a new one started. They can then re-issue all legitimate certificates under the new CA. That is the only safe way to do it.

Re:This makes it worse! (1)

badfish99 (826052) | about 3 years ago | (#37254386)

Or better still: revoke their entire CA, and *don't* start a new one.

Re:This makes it worse! (1)

mlts (1038732) | about 3 years ago | (#37254580)

They need to not just dump every single private key, but do it the right way, and use hardware security modules that limit access, and what access is granted is thoroughly logged.

RedHat had a break-in a few years back with a blackhat getting access. The attack was mitigated of in a matter of hours, and the damage was very limited (with "blacklist" keys sent out for the rogue packages that were signed.) A CA has to have their core keys in a HSM, or they should not be in business because their whole commerce resides around the trustworthiness of their keys.

My question: What makes these guys more trustworthy than someone who lives in a basement who wants to run a CA, and has the CA root key stored in an Aladdin eToken? CAs are supposed to be trusted for a reason, and because of that, they need to invest in the proper hardware, processes, and HR procedures in making sure what their keys sign is correct.

Re:This makes it worse! (2)

jesseck (942036) | about 3 years ago | (#37255824)

So not only did they hide a break-in from the internet at large, including companies (e.g. Google) which were by extension the target, but they also aren't able to tell how many or what kinds of fake certificates got generated by the break-in?

The way I hear the quote from the summary

On July 19th 2011, DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure

is "We found out this week that fraudulent certificates were issued on July 19th..."

Can someone explain... (1)

gad_zuki! (70830) | about 3 years ago | (#37254420)

Can someone explain why a .nl organization has the power to produce .com certs? I mean, isn't this an obvious flaw in the domain/ssl/registrar/CA/whatever hodgepodge we take for granted everyday? Is it even possible to limit these guys or is it "Hi, you're a CA now, you can do anything!"

I remember the same thing happening with a different foreign CA not too long ago and a lot of hand wringing over state owned telecoms in China/Iran/Syria and other autocratic nations. The domain name system works like this. China can make all the .ch domains it wants, but a Chinese CA can make all the .com SSL certs it wants? That's fucked up.

Re:Can someone explain... (0)

Anonymous Coward | about 3 years ago | (#37254532)

China can make all the .ch domains it wants

I'm not sure the Swiss are all that happy about it.

Re:Can someone explain... (1)

gad_zuki! (70830) | about 3 years ago | (#37254564)

Heh, good catch. .cn is what my 30-something brain meant.

Re:Can someone explain... (1)

janeuner (815461) | about 3 years ago | (#37254682)

The chain-of-trust model is not hierarchical. Many CA certificates do not include a domain name at all. It is all about the certificate subject and the key usage flags.

Re:Can someone explain... (1)

BZ (40346) | about 3 years ago | (#37254716)

> Can someone explain why a .nl organization has the
> power to produce .com certs?

To avoid having a monopoly in the CA space?

But yes, having some limits on what CAs are trusted to issue certs of which sites what is a good idea, and I fully expect browsers will move in that direction. I'm certainly pushing for it.

Re:Can someone explain... (1)

Anonymous Coward | about 3 years ago | (#37255170)

SSL Certificates are not bound to DNS domains by anything other than convention. The CN in a certificate is a random string of characters, and could end in .com, .nl, or .whatever. The important things here are the Alice and Bob mechanics of it, and the third party relationships between CA vendors and browser and OS vendors. Trust has to be established somewhere.

If a certificate is signed by one of these CA certificates and the crypto math works out, it is considered to be valid, period, regardless of the CA signer's CN.
Making statements such as " .com certificates are only valid when signed signed by the following CAs... " would be an implementation detail outside of the SSL itself, having to be made in Browser or crypto library code.

It's fairly easy to try it yourself!
1) use opsenssl generate a self signed CA cert.
2) Use openssl and your new CA certificate to generate a *.google.com cert
3) Set up a MITM on your network: Use webmitm from dsniff (does that still work these days?) to serve the new Certificate when trying to visit https://encrypted.google.com/
4) Observe it being broken, since the certificate is actually invalid
5) Install the CA cert into your browser
6) click reload, observe the green bar or padlock.

Step 5 is where the trust relationship is established. A CA vendor (yourself) just paid your browser vendor (yourself) a sum (of time) to include your CA in their product. If the browser vendor (yourself) didn't go through the trouble of investigating the CA vendor (yourself) to see if they were trustworthy, then you (yourself) should find a new browser vendor (besides yourself) because you can obviously not be trusted. Likewise, if the CA (yourself) should be found to be incompetent or malicious, then the browser vendor (yourself) needs to not trust them anymore. (which is what's happening here.)

So you need to trust yourself to not trust yourself.

Get it?

-s

Re:Can someone explain... (1)

someara (1342897) | about 3 years ago | (#37255464)

Ha. +1

Re:Can someone explain... (1)

gad_zuki! (70830) | about 3 years ago | (#37255750)

Great explanation, thanks, but I disagree this is essentially about trust. Sure, my CA is trustworthy today, but if there's some exploit on our network and tomorrow the internet is flooded with fake certs.

You can't trust entities, you can only trust components. I think CA's in general are just security through obscurity and don't provide any real security. A determined attacker just finds a way to generate a SSL from a compromised CA or uses laws like the PATRIOT ACT to generate one from a CA.

Crazy Response to Attack (2)

Rich0 (548339) | about 3 years ago | (#37254444)

We REALLY need a better way to handle root CAs.

First, there should be one list of CAs for the system - not one for every application on the system. Why should Firefox, Thunderbird, Chrome, IE, and who knows what else all have an embedded list?

Second, that list should be easy to update without having to download new copies of all your software.

Ideally, that list should have its own CRL of sorts - so that automated revokes of root CA certificates can be done with a simple process. That should be a fail-safe mechanism - if the CRL can't be authenticated in some period of time, then a warning is displayed or all certificates relying on that CRL become invalid.

Re:Crazy Response to Attack (1)

hedwards (940851) | about 3 years ago | (#37254614)

Right and while we're at it, they should be subject to random security audits. Given that the signing key doesn't need to be present on a network to work, I'm not really sure I understand how a breach like this couldn't have been prevented.

Re:Crazy Response to Attack (1)

characterZer0 (138196) | about 3 years ago | (#37254652)

Debian has /usr/sbin/update-ca-certificates that reads certificate configuration from /etc/ca-certificates.conf and generates the certificate store for any applications that use the mechanism, which includes openssl, Firefox, and Java as installed from the Debian repositories.

I would think it would be easy to write a program that does the CRL checking as you described and remove the entries from /etc/ca-certificates.conf.

Re:Crazy Response to Attack (2)

janeuner (815461) | about 3 years ago | (#37254762)

I disagree. I trust public CAs for web browsing. I trust my company CAs for company email.

The reverse of this is not true.

TBH, we should have certificate stores for each application. In a perfect world, I should install my bank's certificate as a trusted certificate, and distrust Thawte, Verisign, etc when visiting mybank.com. But alas, that is hard.

mod parent up (0)

Anonymous Coward | about 3 years ago | (#37255628)

This. A million times this.

How hard would be to make the system so that when you apply for e-banking services, you're given a cd with your certificate files and have your browser only recognize those as legitimate for their website.

Better yet, create a minimalistic bootable (security-hardened) distribution that you're supposed to use every time you do e-banking (with a modified browser that only accepts your bank's CA) and you would be totally safe doing e-banking in your typical malware-ridden Windows box (well... at least until they start going after the BIOS and the boot sector :P).

Re:Crazy Response to Attack (1)

Relayman (1068986) | about 3 years ago | (#37255294)

Apparently, OS X does have one list for the system, or at least that's the list Chrome uses (Firefox, not so sure). And it has a feature where I can disable a CA without removing it. I'm going to disable 80% of the CAs because I really don't know them and see what happens.

Re:Crazy Response to Attack (1)

yuhong (1378501) | about 3 years ago | (#37255396)

AFAIK, the lists are part of the SSL libraries I think. Two of the commonly used ones are Mozilla's NSS and MS's SChannel.

Re:Crazy Response to Attack (1)

yuhong (1378501) | about 3 years ago | (#37255406)

And I forgot to mention that SChannel, while most often used by IE, is actually part of Windows itself.

Re:Crazy Response to Attack (0)

Anonymous Coward | about 3 years ago | (#37255368)

Yeah, that is how it works in Windows, when using Microsoft software (like Internet Explorer).
The list of trusted roots is completely separate from the browser code.

But I guess that is not popular to say here...

Re:Crazy Response to Attack (1)

Smallpond (221300) | about 3 years ago | (#37256222)

Yeah, that is how it works in Windows, when using Microsoft software (like Internet Explorer).
The list of trusted roots is completely separate from the browser code.

But I guess that is not popular to say here...

Which also means you can't control which CAs are trusted from IE. You wait for Windows Update to do it for you. That's probably the right thing to do for most people.

Re:Crazy Response to Attack (0)

Anonymous Coward | about 3 years ago | (#37256332)

Actually, in versions after Windows 2003 this does not use Windows Update but a separate service for updating the list of trusted roots.
(XP and 2003 use an optional update sent via Windows Update)

Microsoft can revoke root certificates without making their customers update to a new version of the browser.
Other browsers are lacking in this respect.

Re:Crazy Response to Attack (0)

Anonymous Coward | about 3 years ago | (#37256452)

Chrome uses the system SSL stack, so it would use what IE uses on Windows, what Safari uses on OS X, etc. Firefox includes NSS, so it has its own certificate store.

its a different approach to the same (1)

nimbius (983462) | about 3 years ago | (#37254492)

problem faced by governments. namely, how do we spy on the public without their knowledge to ensure they remain compliant to the states will?
in iran the middleman is obtained nefariously as third and second world nations are excluded from participation in general surveillance as a matter of ideological
principal on the part of wealthier and larger nations. in a sense this is to ensure that "our spying" is ideologically valid and just in the public eye, while
"their spying" is only for evil purposes and not to enforce a relatively tolerated theocratic government. american authority figures however simply access the service providers directly. Frameworks are even provided
at the request of the government to facilitate warrantless surveillance of the populous, for any reason, through various internet services.

this abuse of CA by iran is problematic not because theatens the security model, but because it undermines the infrastructure by which america and other wealthy nations ensure the sanctity of their firstworld economic transactions; the lifeblood by which they operate.

Re:its a different approach to the same (1)

hedwards (940851) | about 3 years ago | (#37255270)

Iran is excluded because they're not to be trusted. The real question is why we trust the Israelis and some of the other folks we trust.

Where they kept the master keys ? (0)

Anonymous Coward | about 3 years ago | (#37254534)

Tell me that not was on public network, even on a networked machine. They surely can afford HSM for managing,and keeping safe the most valuable keys.
 

To whom it make concern: (5, Insightful)

fuzzyfuzzyfungus (1223518) | about 3 years ago | (#37254546)

We at Vasco love the passive voice more than our own mothers. Also, all appearances to the contrary, we aren't colossal fuckups because, when we colossally fucked up, we "acted in accordance with all relevant rules and procedures"(this apparently didn't include mentioning that there had been an issue). Thankfully, we hire external auditors who operate well on our level of understanding, so they didn't reveal the embarrassing scope of our failure. After somebody else entirely did our job for us, we finally got around to cleaning up what of our mess was still within the realm of fixable(sorry, Iranian Gmail users, hope you weren't doing anything seditious..)

So, is there any reason that this company shouldn't just be sold for scrap now? Their security clearly isn't good enough, their secretive attitude isn't exactly in line with being a 'trusted' certificate authority, and they can't even hire the right outside assistance to help them clean up their own messes. Hell, at this point, my very own FuzzyFuzzyFungus' SporeCert(tm) trust solutions would appear to be a better bet...

Re:To whom it make concern: (0)

Anonymous Coward | about 3 years ago | (#37254730)

Dear sirs,

I needz to have my cert for a domain I am operating. It needs to be good for all subdomain and purposes.

Please tell me where i may send my csr to that I may then get my new publik cert.

Thankzzzz!

Re:To whom it make concern: (1)

Lieutenant_Dan (583843) | about 3 years ago | (#37254984)

I was going to suggest http://beessl.com/ [beessl.com] but they seem to be down.

Re:To whom it make concern: (1)

Lieutenant_Dan (583843) | about 3 years ago | (#37254744)

I have a feeling that the other players out there are in a similar state and operate on thin ice.

It would be interesting to see if any CAs have done a SAS70 or SOC2 type audit? At least there would be some assurance that they have the right controls in place to run a CA. A quick Google came up with zilch.

Re:To whom it make concern: (0)

Anonymous Coward | about 3 years ago | (#37254926)

True. But still... until rogue certificates signed by those "other CAs" start appearing, I'll just assume they're slightly more trustworthy than Diginotar/VASCO or Comodo (which have already been demonstrably lax and incompetent in their role as CAs).

Obviously, issuing/signing SSL certificates is a lucrative business. On the other hand, the power/authority of a CA depends solely on OS/browser vendors and users trusting them. If these "stakeholders" start applying a zero tolerance policy towards these instances of incompetence (i.e. a CA signs a rogue cert AND fails to take appropriate measures once the breach is found, it gets immediately deleted from all root certificate lists until they can prove there was no wrongdoing on their behalf), I'm pretty sure most important CAs (which highly depend on their reputation) would start reviewing their security measures (under the risk of being shitlisted by everyone and have their source of income disappear overnight).

tl;dr: the only way to change the often shady and incompetent behaviour of CAs is to hit them where it hurts... their wallets.

Re:To whom it make concern: (1)

Anonymous Coward | about 3 years ago | (#37254770)

Exactly. They say (or "claim") that they discovered the intrusion to their PKI on July 19th: that's just 1 month and 10 days since they discovered the issue until they actually publicly disclosed that something was wrong.

By failing to enforce correct security measures that would prevent this issue and (even worse) by failing to inform involved parties in a timely manner, Diginotar/VASCO have proven to be utterly incompetent as CA and, as such, deserve no trust from me (or anyone else).

Certificates issued by them (and Comodo) are now in my shitlist: I'll just assume every site that presents a certificate signed by them is likely to be compromised.

Also, I'm happy to see most browser vendors are following that too.

No competence... no trust.

Re:To whom it make concern: (0)

Anonymous Coward | about 3 years ago | (#37255046)

Good thing the cleaned up the mess.
https://www.diginotar.nl/Portals/0/Extrance.txt
Oh, wait...

Re:To whom it make concern: (1)

pe1chl (90186) | about 3 years ago | (#37255424)

I also find it quite disgusting how they mainly focus on the damages potentially being done to their own company and the profits it might or might not generate, instead of considering the damages done to others, in this case even to individuals that may pay for this incident with their lives.

In other words, we don't have a clue. (0)

Anonymous Coward | about 3 years ago | (#37254650)

"At that time, an external security audit concluded that all fraudulently issued certificates were revoked. Recently, it was discovered that at least one fraudulent certificate had not been revoked at the time."

This simply means that their audit method is incapable of flagging the certs that are bogus.

Re:In other words, we don't have a clue. (1)

pe1chl (90186) | about 3 years ago | (#37255460)

But still in further statements they continue to claim that the trust in other certificates managed by the same company (under a different root) is not affected by all this.
First, that indicates that they have no clue what trust means, but also it is not at all unlikely that they have to announce next week that a fraudulent certificate was still issued, only their broken auditing system had not been able to trace it.

Root certs need to be restricted by TLD (4, Insightful)

Animats (122034) | about 3 years ago | (#37254678)

Currently, root certificates are wildcards, usable for any TLD. They need to be restricted to a single TLD, or a short list.

Single-nation CAs and government-operated CAs should be restricted to their TLD. For the generic TLDs, ("com", ".net", etc,) the CA/Browser Forum should require the CAs to post a large bond [cabforum.org] , from which a penalty is forfeited if any improperly issued cert is found. That should get the problem under control.

Why only one CA per certificate? (1)

drolli (522659) | about 3 years ago | (#37254836)

Could one not send CSRs to more than one CA and the browser indicates how many CAs responded ok?

they were repeatly hacked since 2009 (1)

Anonymous Coward | about 3 years ago | (#37254940)

F-secure claims Diginotar was repeatly hacked since May 2009; it shouldn't be trusted at all:
http://www.f-secure.com/weblog/archives/00002228.html

Too late (4, Informative)

slasho81 (455509) | about 3 years ago | (#37254974)

Too little, too late. I already removed DigiNotar from my trusted CA list. You should too. In Firefox: Options > Advanced > Encryption > View Certificates > Authorities tab > Find DigiNotar > Edit Trust.

Re:Too late (0)

Anonymous Coward | about 3 years ago | (#37255762)

DO NOT WORK.

Log out, start a new session, start Firefox and DigiNotar is back.
This does not work.

Re:Too late (1)

slasho81 (455509) | about 3 years ago | (#37255822)

Works for me.

And what about comodo? (0)

Anonymous Coward | about 3 years ago | (#37255080)

They didn't get removed by mozilla et al despite two breaches (and proof that their process is completely untrustable well beyond some errors, they are unable to ascertain just who requested what); instead specific certificates got blacklisted.

Anybody care to explain where the difference lies?

Not trying to astroturf for diginotar. Just wondering why comodo didn't get the same treatment.

this makes me happy (1)

roman_mir (125474) | about 3 years ago | (#37255212)

this is a good day for liberties, because this kind of sh...stuff exposes any type of 'authority' for what they really are, be it a gov't or any other so called authority (especially the kind that people just trust without questioning).

Since when are people just blindly trusting one another? Government like structures? Isn't this a sure way to get completely screwed by whoever you are trusting?

The entire model is wrong, of-course. There is a need for a bunch of competing systems, open, distributed, easy to verify lists, that can be compared one to another, with time stamps, with hash keys, it needs to be thought through, but there is a need. It has to be distributed so that there is no one central authority. I want to be able to check the fingerprint of a certificate against multiple competing distributed signed lists and as an admin of a system I want to be able to check what those lists maintain as fingerprint for my sites as well and quickly fix any problems if they happen. This is complicated but it will have to happen.

In MacOSX (4, Informative)

Jeremy Erwin (2054) | about 3 years ago | (#37256016)

open /Applications/Utilities/Keychain Access.app
Click on System Roots
Scroll down to DigiNotar Root CA
Click the "i" icon, or select "Get Info CMD-I"
Expand the "Trust" node
For the "When using this certificate"
Select the "Never Trust" option

If successful, the info window will now say "This certificate is marked as not trusted for all users"--- and you can browse this site [diginotar.nl] to ensure that the trust is broken.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>