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!

cancel ×

151 comments

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

Firefox/IE patches released,Comodo incident report (5, Informative)

Anonymous Coward | more than 3 years ago | (#35591500)

Comodo’s advisory:

http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html

Firefox released 3.6.16 yesterday:

http://www.mozilla.com/en-US/firefox/3.6.16/releasenotes/

Microsoft released an advisory and patch yesterday:

Advisory: http://www.microsoft.com/technet/security/advisory/2524375.mspx

Patch: http://support.microsoft.com/kb/2524375

Re:Firefox/IE patches released,Comodo incident rep (1)

blair1q (305137) | more than 3 years ago | (#35591904)

Firefox released 3.6.16 yesterday:

But did they already release 4.0.1?

Re:Firefox/IE patches released,Comodo incident rep (1)

Nimey (114278) | more than 3 years ago | (#35591946)

They released 4.0 RC2 (which probably became 4.0) a few days ago, and its changelog said that it blacklisted certain SSL certs. Bet that was these.

Re:Firefox/IE patches released,Comodo incident rep (3, Informative)

kbrosnan (880121) | more than 3 years ago | (#35592012)

Re:Firefox/IE patches released,Comodo incident rep (1)

robmv (855035) | more than 3 years ago | (#35592760)

If someone is trying to intercept your communications using a phony certificate, they already have access to your traffic, just blocking connections to those update sites and they will have those machines unpatched for a lot of time

any alternative to updates? (1)

jginspace (678908) | more than 3 years ago | (#35595640)

The removal of the 'weaker' certs and authorities needs to be scriptable. Connecting to Mozilla updates is bad at the best of times - much much more so in countries where this incident might be more of an issue.

From TFA:

The Comodo breach will force organizations that might replace one or two certificates in a year to swap out nine certificates in a matter of hours - a painstaking and multi-step process that is often handled manually.

Is there *anything* I can download - just a few Kb in size - to patch up my browser when cert issues arrive, rather than waiting for browsers to hard code the strings in 1-20Mb download?

Well (1, Insightful)

The MAZZTer (911996) | more than 3 years ago | (#35591506)

Time for major browsers to add that issuer to the blacklist, I guess. Or the individual certs, but that's less fun.

Re:Well (2)

poetmatt (793785) | more than 3 years ago | (#35591916)

Uh, you're kinda behind. IE and Firefox have already been patched, no doubt chrome too.

Re:Well (1)

John Hasler (414242) | more than 3 years ago | (#35592138)

I think he means anything originating with Comodo.

Re:Well (1)

blair1q (305137) | more than 3 years ago | (#35591918)

Ought to be a cut-and-paste operation, at worst. The issuer probably does it himself once he knows he's given out bad numbers.

The question is whether blacklisting is really working on a lot of browsers on which cert checking is working.

Re:Well (1)

click2005 (921437) | more than 3 years ago | (#35591982)

I'd be interested to know if Comodo Inc uses SSL certs for it's own security software updates.

Why doesn't every website use HTTPS? (1)

iamhassi (659463) | more than 3 years ago | (#35592128)

from Monday: Why Doesn't Every Website Use HTTPS? [slashdot.org] "HTTPS is more secure, so why isn't the Web using it?"

Oh Irony!

Re:Why doesn't every website use HTTPS? (2)

heypete (60671) | more than 3 years ago | (#35592668)

Because an uncommon, widely-publicized, already-fixed incident that affects a very small number of sites is somehow worse than the status quo, where there's no validation of sites, no assurance of a lack of tampering of data in transit, or of illicit interception of data, right?

Re:Why doesn't every website use HTTPS? (1)

Anonymous Coward | more than 3 years ago | (#35593548)

Because an uncommon, widely-publicized, already-fixed incident that affects a very small number of sites is somehow worse than the status quo, where there's no validation of sites,

No, you can still validate sites any way you find works best, it's just that you're asking the wrong (i.e. untrustworthy) people to do it for you.

no assurance of a lack of tampering of data in transit, or of illicit interception of data, right?

That's exactly what SSL is for. What you're thinking of is the key distribution. If you don't know who's signing the keys, then SSL cannot help you.

  (Ever looked at how many "trusted" CA's your browser includes by default? Are you familiar enough with even 10% of them to trust them for this role?)

Re:Why doesn't every website use HTTPS? (4, Interesting)

heypete (60671) | more than 3 years ago | (#35593888)

That's exactly what SSL is for. What you're thinking of is the key distribution. If you don't know who's signing the keys, then SSL cannot help you.

Fair enough.

My point was that CAs rarely mistakenly sign keys for fraudulent entities. Has it happened? Absolutely. Is it common? No. With EV certs becoming more popular for big-name sites (e.g. banks and the like), users can have a reasonable confidence in that the site they're visiting is legitimate. Non-EV certs provide a more modest assurance. Non-SSL sites offer essentially no assurance, which is the current situation for most sites.

In short, using even an occasionally-flawed system like the current SSL infrastructure is far better than not using anything at all, which is what's currently going on.

(Ever looked at how many "trusted" CA's your browser includes by default? Are you familiar enough with even 10% of them to trust them for this role?)

Yes, I've looked at the list. Rather than prune it of CAs that I may consider to be bad (they do, after all, have to undergo audits and the like to be added to the major browser lists), I make it a habit to always hover over the Firefox SSL indicator (which then displays the name of the CA) when I visit an SSL-secured site, and make sure it's a reasonable CA (e.g. one in North America or Western Europe for essentially all the sites I visit) for the site. I also have the Certificate Patrol plugin to detect spoofing.

Of course, the average user doesn't do anywhere near this much checking (which admittedly isn't much). However, I stand by my above point that even with its flaws, using SSL on everything (or at least more things) is far better than keeping things they way they are now.

Re:Why doesn't every website use HTTPS? (0)

Anonymous Coward | more than 3 years ago | (#35593372)

Because using SSL for every single site is... usually overkill. Processor-time isn't free--even with VMs, it still increases processor utilization... You can offload but that costs you money for appliances or additional other hardware/appliance VMs. If you have already eaten the cost of an load-balancer/SSL offload appliance, then sure, use SSL for everything, why not?

Re:Well (1)

cbiltcliffe (186293) | more than 3 years ago | (#35592876)

I said this wasn't over a few years after Verisign signed the fake Microsoft cert in 2001. http://www.cert.org/advisories/CA-2001-04.html [cert.org]

I can't find my /. comment on it right now, as it was years ago, but everybody who responded said many checks had been put in place so that type of thing couldn't happen again.

Well, I told you so. The problem is, it only takes one legitimate CA to screw up, and it subverts the entire system for all CAs.

Better Internet for Everybody (0)

Anonymous Coward | more than 3 years ago | (#35591520)

How to get a better 'net for everybody: everyone refuse all traffic originating from the third-world shithole countries of the world. Iran, most of Asia, most of Africa, and some of South America.

*poof* it's magic! overnight, drastic reduction in spam and attacks like this

we need to get the top-level ISPs that run backbones to start doing this. pronto.

Re:Better Internet for Everybody (3, Informative)

zach_the_lizard (1317619) | more than 3 years ago | (#35591574)

Yeah! We should ban such third world hellholes as the United States, Japan, Canada, Italy, Germany and the United Kingdom! They are all in the top 10 for spamming, according to Spamhaus. The others are China, Russia, Brazil, and Argentina.

Re:Better Internet for Everybody (1)

sexconker (1179573) | more than 3 years ago | (#35592384)

Yeah! We should ban such third world hellholes as the United States, Japan, Canada, Italy, Germany and the United Kingdom! They are all in the top 10 for spamming, according to Spamhaus. The others are China, Russia, Brazil, and Argentina.

Troll troll is troll troll.
Spam is sent out by botnets. Botnet operators almost all reside China, Russia, South America, etc.

Re:Better Internet for Everybody (2)

overlordofmu (1422163) | more than 3 years ago | (#35592436)

Citation, please?

Re:Better Internet for Everybody (1)

sqlrob (173498) | more than 3 years ago | (#35591848)

Yeah, why should they be given tools like twitter that helped trigger and coordinate a revolution. Damn them using the internet to get better.

Re:Better Internet for Everybody (1)

MichaelKristopeit334 (1966808) | more than 3 years ago | (#35592004)

you're an idiot.

banning traffic from entering the US which originated from the revolting countries would do nothing to stop any of the local revolutions, as local organizational traffic would never be blocked.

damn you, moron.

continue with your hypocritically ignorant marketeering, feeb.

you're completely pathetic.

Re:Better Internet for Everybody (2, Insightful)

Anonymous Coward | more than 3 years ago | (#35592028)

Wow, broken clocks are right twice a day it seems.

Re:Better Internet for Everybody (0)

MichaelKristopeit335 (1966810) | more than 3 years ago | (#35592084)

ur mum's face are right twice a day.

you're an idiot.

cower in my shadow some more, feeb.

you're completely pathetic.

Re:Better Internet for Everybody (0)

Anonymous Coward | more than 3 years ago | (#35594386)

WTF don't the management here clean out all the sock puppet troll armies?

Guys like this don't build pageviews. They (and their) posts make people realize they got on the shortbus by accident. And then they leave... ...not like it is hard to find someplace else to waste time on the web.

off to reddit [reddit.com] I go..

Re:Better Internet for Everybody (1)

MichaelKristopeit336 (1967526) | more than 3 years ago | (#35594422)

i am michael kristopeit. i have but one voice. your hypocritically ignorant insistence on perceiving my singular voice as an army of puppets is very telling.

ur mum's face is the sock puppet troll army.

cower in my shadow some more, feeb.

you're completely pathetic.

Re:Better Internet for Everybody (1)

MichaelKristopeit337 (1967528) | more than 3 years ago | (#35594430)

pointing out my insightfulness = insightful

my insightfulness = troll

slashdot = stagnated.

Re:Better Internet for Everybody (1)

shutdown -p now (807394) | more than 3 years ago | (#35595738)

If you split the Net like that, I suspect it's the "dirty" Asia/Africa/SA part that'll end up with TPB. Whereas the "clean" one will have Disney, NewsCorp, and other paywalled gardens.

Patches? (2)

oneiros27 (46144) | more than 3 years ago | (#35591530)

The Mozilla Foundation, Microsoft, Google and other firms rushed out patches to their Web browsers on Tuesday to block the fraudulent SSL certificates. In an incident report filed on March 15, Comodo said the nine certificates were issued to seven domains, but that no attacks using the certificates had been seen in the wild.

What, they don't support revocation lists already? This should be a non-issue, once someone realized it happened.

Re:Patches? (4, Informative)

julesh (229690) | more than 3 years ago | (#35591600)

What, they don't support revocation lists already?

Firefox, to take an example, supports offline revocation lists (i.e. imported from files) or Online Certificate Status Protocol for automatically verifying certificates. Both of these are optional, although OCSP is enabled by default for certificates that specify an OCSP server in their details. Comodo do use OCSP, so this should be dealt with automatically for most firefox users. However, some may have disabled OCSP, and for these a CRL must be installed to revoke the certificates. The easiest way to persuade people to do this is by pushing a patch that contains it.

Why not move CRL into DNS? (2)

mcrbids (148650) | more than 3 years ago | (#35595224)

Why should we be trusting some dis-interested third party to give us that assurance? It's a loser's game! Certificate vendors are in a price war. They don't get paid extra for "going the mile" to confirm your identity, they get paid extra for processing more applications faster and charging 10% less than the other guy. The actual cost of the certificate is too cheap to measure - a couple of used PCs bought on Ebay and a free copy of Linux could probably satisfy most of the global need for certificates. They don't need to be "super certain" they only need to be "reasonably certain", enough to not get sued, and still pass a SAS-70 audit by yet another, disinterested accountancy firm.

Are you feeling confident yet?

In a very real sense, the thing that asserts the IP address of your domain is your DNS server. It's what declares, to the world, where your server is. Since it's the declarative source, why shouldn't it be the confirmational one, as well?

DNSSEC comes close. With DNSSEC you can confirm with certificates and the "chain of trust" that the answer you have came from the DNS server you thought you were asking for the answer from. Now, just one more step: the certificate for the web server should be generated by the trusted DNS server.

It's no assurance that www.screwmebadly.com is a friendly site, but it is a very effective assurance that you are properly connected to www.screwmebadly.com!

Re:Patches? (1)

natehoy (1608657) | more than 3 years ago | (#35591686)

These are the revocation lists. They're being updated.

3.6.16 of Firefox (for example) merely adds the new certs to the blacklist. Microsoft issued a Windows Update that updates the blacklist at the operating system level.

Re:Patches? (0)

Anonymous Coward | more than 3 years ago | (#35592996)

Microsoft issued a Windows Update that updates the blacklist at the operating system level.

Sounds like the perfect way to make a small change to a list of data for a userspace application like a Web browser. Man, that's so much better than a real package manager. Go Microsoft!

Next on my wishlist, I want the ability to use Windows Update to make minor corrections to an Excel spreadsheet ... wait for it ... at the operating system level.

Read 'em and weep. It's called the right tool for the job, folks.

Re:Patches? (2)

blacklint (985235) | more than 3 years ago | (#35593174)

You do know that SSL certificates are used by things other than browsers and for things other than HTTPS, right? The operating system keeps a list of valid root certificates so all applications can use them, not just IE. Or would you rather every application needs to know how to validate certificates on its own?

It's the equivalent of updating ca-certificates on Debian based systems. Which I'm really surprised hasn't happened as far as I can tell, even with the warning "Please note that certificate authorities whose certificates are included in this package are not in any way audited for trustworthiness and RFC 3647 compliance, and that full responsibility to assess them belongs to the local system administrator."

Re:Patches? (1)

natehoy (1608657) | more than 3 years ago | (#35593480)

Microsoft IE uses an SSL library that is part of the OS. The advantage of that is that any fixes affect all applications that choose to use that library, like SSH tools and some web browsers (Safari tends to use MS libraries). The disadvantage is that any vulnerabilities in the browser can easily translate into OS-level vulnerabilities due to the deep interoperability between them.

Windows Update is a package manager, it's just limited to Microsoft product. I tend to prefer the Linux approach where you have a central repository and get updates for ALL your software in one place, which is why I run that, but Windows Update works perfectly well as a package manager. There are plenty of IE (and Excel) software updates that come down through Windows Update, so I really fail to see any point other than trollage for your entire post.

Re:Patches? (1)

The MAZZTer (911996) | more than 3 years ago | (#35591912)

Chrome does but that feature is off by default (perhaps it is slow?).

Re:Patches? (1)

heypete (60671) | more than 3 years ago | (#35592690)

You sure? OCSP validation is a requirement for Extended Validation certificates. If OCSP is not enabled, the certs will still work, but they'll show up as ordinary SSL certs rather than the "green bar" EV certs.

All major browsers have OCSP enabled by default.

Re:Patches? (1)

ToasterMonkey (467067) | more than 3 years ago | (#35593924)

What, they don't support revocation lists already? This should be a non-issue, once someone realized it happened.

Yah, you get a new one in your browser patch. Those are manually distributed lists. You might be thinking OCSP. I think most browsers now do OCSP by default and have for a few years, and Comodo does support it so most people might already be set. This doesn't help all the weaker SSL clients out there, like what, almost every non-browser application using SSL.

An IP address doesn't mean it came from Iran (1)

Anonymous Coward | more than 3 years ago | (#35591568)

Just because one of the IP addresses involved in the attack was from Iran doesn't mean the attack came from Iran. Anybody sophisticated enough to do this could also hide their true IP address via open proxies, compromised hosts, or Tor, such as explained here:
http://erratasec.blogspot.com/2011/03/no-evidence-comodo-compromise-was-from.html

Re:An IP address doesn't mean it came from Iran (1)

Seumas (6865) | more than 3 years ago | (#35591632)

And Iran. Iran so far away.

Re:An IP address doesn't mean it came from Iran (1)

blair1q (305137) | more than 3 years ago | (#35592030)

Are there a lot of open proxies in Iran?

Re:An IP address doesn't mean it came from Iran (1)

cheater512 (783349) | more than 3 years ago | (#35592524)

What about a closed proxy? Someone paid to proxy it from Iran?

I think (2)

fireylord (1074571) | more than 3 years ago | (#35592898)

That I hear a whoosh there. Maybe its that big group of birds up above? I think that they're seagulls ;)

CRLs? (4, Insightful)

hawguy (1600213) | more than 3 years ago | (#35591576)

The article says that browser makers rushed to put out patches to blacklist the fraudulent certs. Isn't this what certificate revocation lists [wikipedia.org] are for? Are CRLs completely broken and unused?

Re:CRLs? (5, Informative)

Anonymous Coward | more than 3 years ago | (#35591698)

Are CRLs completely broken and unused?

Yes, they are. [imperialviolet.org]

Re:CRLs? (2)

hey! (33014) | more than 3 years ago | (#35592148)

Well, that's interesting, but not quite the same as saying that CRLs are broken. It just means you have to have reasonable expectations, which is where people often screw up. You can't expect a browser to check a certificate against a CRL if it can't access the CRL, but the when the browser *can* access the CRL it provides a useful service.

If the browser can't reach the certificate server to check against the list, there's no ideal policy to choose. You don't want the certificate servers to be a single point of failure from which a massive denial of service could be launched. But you don't want to have the problem to be totally ignored, as with IE. You'd want to give a user who was sufficiently paranoid a chance to not trust the suspect certificate.

Again, speaking of reasonable expectations, you can't expect most users to know what to do with a warning that the certificate can't be checked against the CRL, therefore the browsers must be patched. But an unpatched browser *should* tell the user the certificate is no good if it *can* check the CRL, and that's a good thing.

Re:CRLs? (0)

Anonymous Coward | more than 3 years ago | (#35592212)

Are CRLs completely broken and unused?

Yes, they are. [imperialviolet.org]

Uhh, if someone can block access to CRLs, what's to stop them blocking access to WindowsUpdate or Mozilla update?

Re:CRLs? (1)

evilviper (135110) | more than 3 years ago | (#35594454)

No they aren't.

Your article merely explains that CRL implementations are fail safe. A CRL isn't something that's needed 99.999% of the time, so depending on the CRL server being available would be a serious risk. Ignoring the CRL being unavailable is a good thing. A pop up warning would be unnecessary noise. The likelihood of an attacker getting a cert is remote, and being able to also block the CRL server is astronomically unlikely.

yes and yes (0)

Anonymous Coward | more than 3 years ago | (#35591712)

correct on both counts

Re:CRLs? (1, Informative)

BZ (40346) | more than 3 years ago | (#35591722)

You may want to read http://www.imperialviolet.org/2011/03/18/revocation.html [imperialviolet.org]

Great article, terrible proposal (1)

jginspace (678908) | more than 3 years ago | (#35595542)

A great article but the author does himself in with the final paragraph:

A much better solution would be for certificates to only be valid for a few days and to forget about revocation altogether.

As someone who spends a lot of time mixing with the 'enemies of the internet' - incl some dodgy states not listed, like India - I've learned to treat my browser downloading a new certificate as an *exceptional* circumstance - something to be looked into. Certificates should be worth something and they should be worth keeping a while. What's with the arbitrary validity anyway. Let the issuers choose the validity on a per-certificate basis. After a while some researcher is going to suggest that 'a few days' is far too long and expose this proposal for the cludge it is.

Then there's the mechanism for reissuing frequently. Tag with 'whatcouldpossiblygowrong'.

If the above proposal gained traction all those MiM government-level adversaries would be delighted.

Re:CRLs? (0)

Anonymous Coward | more than 3 years ago | (#35591782)

CRLs are only useful if they are actually checked.

SSL Revocation mechanisms don't work (1)

Khopesh (112447) | more than 3 years ago | (#35593032)

The article says that browser makers rushed to put out patches to blacklist the fraudulent certs. Isn't this what certificate revocation lists [wikipedia.org] are for? Are CRLs completely broken and unused?

As a matter of fact, yes. SSL revocation mehcanisms are broken [imperialviolet.org] and nobody knew until a few days ago. Jacob Appelbaum wrote a nice write-up yesterday about how he noticed the emergency patches in Firefox and Chrome [torproject.org] regarding blacklisted SSL certificates.

no big deal (4, Interesting)

Anonymous Coward | more than 3 years ago | (#35591676)

Your browser already trusts a certificate authority run by the Chinese government, along with one that delegated authority to them.

Your browser also trusts certificate authorities in Africa, *stan countries, and the non-EU portion of Eastern Europe. How many of these could be bribed or coerced if you knew the right people or worked for a random 3rd-world government?

Really, the lock/key icon and colored URL box are totally misleading. You have almost no security. Given the rotten certificate authority situation, failing to accept self-signed and expired certificates is actually a loss for security. You might as well get encryption against a passive attacker. Pretending to be secure against active attackers is just providing a false sense of security.

Re:no big deal (1)

DarkOx (621550) | more than 3 years ago | (#35591752)

Don't make statements about my browser, you know nothing about my browser. Yes I have actually removed most the Eastern Europe, Middle East, and China.

Re:no big deal (0)

Anonymous Coward | more than 3 years ago | (#35591836)

Don't make statements about my browser, you know nothing about my browser. Yes I have actually removed most the Eastern Europe, Middle East, and China.

And that protects you from compromised authorities elsewhere, how?

Re:no big deal (1)

praxis (19962) | more than 3 years ago | (#35593782)

It doesn't, but trusting some CAs is better than trusting none of them and trying to get a Google engineer on the phone, validating his identity with some challenge response system and then having him read the fingerprint over the phone.

It is correct to say you have no security, for there is only calculated risk. DarkOx decided there are some CAs he trusts, and some he does not. He calculated that risk and accepted it. Saying that it's not perfect security does not mean it's not better security.

Re:no big deal (0)

Anonymous Coward | more than 3 years ago | (#35594458)

i can still see them on google maps

Re:no big deal (0)

Anonymous Coward | more than 3 years ago | (#35594286)

Really, the lock/key icon and colored URL box are totally misleading. You have almost no security. Given the rotten certificate authority situation, failing to accept self-signed and expired certificates is actually a loss for security. You might as well get encryption against a passive attacker.

You're spreading misinformation. Security is not a "yes/no" proposition. It comes down to things like risk and trust. Your browser vendor trusts those CAs and you trust your browser vendor because you run their software. The UI sucks ass, but cert issuer doesn't fit on an address bar and makes the UI worse.

You also make a really naive assumption that a "passive attacker" somehow never snoops your traffic prior to initiating a connection. Who signs a certificate doesn't matter AT ALL if you know you securely exchanged the right keys and you cache them. However, you're not doing yourself any favors accepting new keys over the wire. There is no safety from "passive attackers", only safety if whoever it is isn't there for the whole session, which is a stupid thing to hope for.

Re:no big deal (0)

ToasterMonkey (467067) | more than 3 years ago | (#35594300)

Your browser already trusts a certificate authority run by the Chinese government, along with one that delegated authority to them.

Your browser also trusts certificate authorities in Africa, *stan countries, and the non-EU portion of Eastern Europe. How many of these could be bribed or coerced if you knew the right people or worked for a random 3rd-world government?

Really, the lock/key icon and colored URL box are totally misleading. You have almost no security. Given the rotten certificate authority situation, failing to accept self-signed and expired certificates is actually a loss for security. You might as well get encryption against a passive attacker. Pretending to be secure against active attackers is just providing a false sense of security.

Please, for the love of God someone with a clue about PKI, trust, and risk mod this down.

His idea of "passive attacker" is one who _accidentally_ snoops your traffic and is incapable of loitering for more than a few minutes to catch the start of a new session.

Re:no big deal (0)

Anonymous Coward | more than 3 years ago | (#35594810)

I modded up the wrong post on accident. Not another one of those self signed and expired certificate people, ugh. This should undo my moderation.

Import CRL? (1)

Stavr0 (35032) | more than 3 years ago | (#35591726)

Firefox has a CRL management feature. (Option/Advanced/Revocation List) What is the CRL link for import ?

Re:Import CRL? (1)

heypete (60671) | more than 3 years ago | (#35592736)

It's not needed, so long as the "Use the Online Certificate Status Protocol..." box is ticked, and the "Validate a certificate if it specifies an OCSP server" box is selected in the "Validation" section under the "Encryption" tab in Firefox preferences.

OCSP > CRL

crimes against world, nobody jailed, some scolding (-1)

Anonymous Coward | more than 3 years ago | (#35591778)

that should do it. now even more innocent folks have to die semi-approved deaths?

Things You Can Do On Your Own (4, Informative)

Jah-Wren Ryel (80510) | more than 3 years ago | (#35591948)

Neither of these are perfect, but here are two different firefox add-ons that can significantly reduce the chance of you falling victim to a compromised certificate authority:

Network Notary [networknotary.org] - sort of crowd-sourcing approach
Certificate Patrol [mozilla.org] - remembers the certs of sites you've visited in the past and tells you when they change

Re:Things You Can Do On Your Own (1)

jd (1658) | more than 3 years ago | (#35592752)

There are a few add-ons for checking the strength of a cert as well - probably doesn't matter nearly as much, since the breach is through the vendor and not through a security hole, but it would not surprise me if there's a relationship between bargain-basement certs and bargain-basement security.

Re:Things You Can Do On Your Own (1)

caluml (551744) | more than 3 years ago | (#35593024)

Ironically, addons.mozilla.org is one of the sites that had a fake cert generated for it.

Re:Things You Can Do On Your Own (0)

Anonymous Coward | more than 3 years ago | (#35595556)

How is that ironic? If you're getting fake certs, doesn't it simply make sense to grab the ones that will help keep the users you're attacking from catching on? Browser updates and add-ons sites are obvious.

What to do (0)

Anonymous Coward | more than 3 years ago | (#35592066)

Hey Hey,
Ho, Ho,
Nuke Iran
And make it glow!

Propaganda. (0)

Anonymous Coward | more than 3 years ago | (#35592130)

Obviously more right-wing propaganda designed to discredit Iran.

And the CAs do ... what again? (4, Insightful)

DriedClexler (814907) | more than 3 years ago | (#35592134)

If I'm paying the CA to certify that public key X really is mine, and yet someone who's not me can get the same certification from the CA for being me ... what was I paying for again?

RSA =/= rubber stamp authority

Re:And the CAs do ... what again? (1)

Anonymous Coward | more than 3 years ago | (#35592888)

The problem is that SSL certs are not tied to domains and therefore not limited to any CA.

In other words, any CA can issue SSL certs for any domain. That includes the CN-NIC and plenty of other less-than-trustworthy root CAs.

In fact, if you have a way to intercept/view email for a domain, you can issue an SSL cert for that domain via StartSSL. StartSSL relies on an email sent to [postmaster|webmaster|hostmaster]@domain.com and if you can get that you can then be trusted to issue certs for that domain.

The root CA model is fundamentally broken. It needs to be scraped and DNSSEC used to bootstrap the way we trust SSL certs.

Then all you need is the root DNSSEC key and you can verify all the way down to any domain that is DNSSEC-secured. Once you have that, you can put into DNS SSL CAs for a given domain and/or SSL Signatures/Keys.

Re:And the CAs do ... what again? (1)

dgatwood (11270) | more than 3 years ago | (#35592890)

Well, ultimately, the flaw is that the CAs are allowed to deliberately conflate identity with encryption to boost sales. The fact is that 99.999% of sites do NOT need rigorous identity checks, but 100% of all websites SHOULD use encryption.

In parallel with SSL, we should adopt a protocol similar to what SSH does, in which, upon connecting to a service, you decide if you trust it, and then your browser remembers the key fingerprint for that browser. This should not be in the form of a scary "this site may be masquerading as another site" dialog, but rather as a legitimate alternative that establishes encryption without establishing identity. Essentially, it should be a special flag that indicates that this self-signed cert should be treated as a production cert, but with permanent memorization.

By having such a system, true, high-security systems like banks would continue to pay their small fortune to a CA to get an EV cert. Normal certs would go away because as we know, they really don't provide any real value from an identity perspective anyway, and their very existence lulls people into a false sense of security.

Re:And the CAs do ... what again? (2)

Sancho (17056) | more than 3 years ago | (#35593384)

The fact is that 99.999% of sites do NOT need rigorous identity checks, but 100% of all websites SHOULD use encryption.

Fun with shell scripts: ShellScriptGames.com [shellscriptgames.com]

FYI, your URL doesn't do https, and if I put https in front of it, I go to a different page.

Re:And the CAs do ... what again? (1)

dgatwood (11270) | more than 3 years ago | (#35595076)

Yup. That would be because my box hosts a couple of dozen domains, and SSL sucks at virtual hosting. If there were a solution for encryption that didn't involve your immortal soul every year for a multi-site cert, all my sites would be encrypted. Something like I suggested would completely solve that problem because you would be able to self-sign a single cert for multiple domains, and everyone's computer would simply remember that cert.

The only options for me right now would be to either spend a fortune on a multi-site cert or use a separate IP for each site. Neither of these is feasible for sites run out of somebody's home, hence I had to pick and choose what to encrypt with SSL. I don't like it, but I didn't really have any other good options. Indeed, it's my inability to do the encryption that I feel like my site needs that is the driving force behind my desire for improvements in the system.

Re:And the CAs do ... what again? (1)

Sancho (17056) | more than 3 years ago | (#35595482)

But now you're falling into the same old trap--conflating identity with encryption.

You can serve up any old cert for any old page. If identity doesn't matter, do it. The site is already broken with regard to identity (if I go to https://www.shellscriptgames.com/ [shellscriptgames.com] the page I get is actually https://www.gatwood.net/ [gatwood.net] but with https://www.shellscriptgames.com/ [shellscriptgames.com] shown in the URL bar.)

I'm mostly just nitpicking because of the absolute (100%) you used. It reminds me of the occasional case of a Slashdot editor lamenting (as an editorial to a submission) that 'all sites don't use ssl'--when Slashdot doesn't use SSL.

Re:And the CAs do ... what again? (1)

Sancho (17056) | more than 3 years ago | (#35595498)

Eh, I kinda just realized that I'm coming off like a jerk. Sorry for my comments.

Re:And the CAs do ... what again? (1)

FrangoAssado (561740) | more than 3 years ago | (#35593804)

This should not be in the form of a scary "this site may be masquerading as another site" dialog, but rather as a legitimate alternative that establishes encryption without establishing identity.

The problem is that this does not ensure no one is eavesdropping. That is: how do you know that you're not actually connecting to an attacker that is relaying traffic between you and the real server? (i.e., a MITM [wikipedia.org] ) The CA role in SSL exists specifically to prevent this sort of thing.

In the case of SSH, to prevent this sort of thing you must check that the fingerprint you got matches the one you had previously obtained from the server (how often people do that is another story...) In the case of a web browser, what percentage of people will do that check before clicking "Proceed"?

So, in practice, your proposal would also lull people into a false sense of security, although it would be arguably worse. With the current scheme, an attacker has to fool a CA into signing something for them. This is not impossible (as shown by this story), but is much harder than fooling an user into clicking "Proceed", because most users don't know enough to understand what's going on.

Re:And the CAs do ... what again? (0)

Anonymous Coward | more than 3 years ago | (#35594276)

You seem to be assuming that a browser would display a self-signed HTTPS website as secure. There is no reason to do so. Instead the browser should show it just the same as an unsecure page. I have even seen suggestions of using a different protocol name like HTTPE to indicate that it is not supposed to signed by a CA.

Re:And the CAs do ... what again? (1)

FrangoAssado (561740) | more than 3 years ago | (#35594872)

That's an interesting suggestion. SSL without authentication (i.e., with self-signed certificates), while vulnerable to MITM, is certainly better than no SSL at all. And I believe a lot of people would probably switch from plain HTTP to HTTPE given the option (using SSL without paying for a certificate and having no ugly warning/error messages when connecting seems like a good deal).

But there's still the danger of "lulling people into a false sense of security" mentioned originally by dgatwood: people might think that HTTPE is safe enough and never bother with HTTPS, even in situations where MITM is a real problem.

Re:And the CAs do ... what again? (1)

dgatwood (11270) | more than 3 years ago | (#35595136)

Let me just make sure I'm making myself clear here. It is very important that the browser permanently remember the cert authorized for a given site. Without that, an encrypted connection is easy enough to spoof that it would not be significantly safer than plain HTTP.

Such a system is technically vulnerable to a man-in-the-middle attack, true, but only the very first time you connect to a site. And if you're really paranoid, you could connect to the site from home, then connect to the same site from work and make sure you don't get a "host key has changed" dialog before you trust the site with any personal info.

The point is that most people would not describe SSH as particularly insecure. Each client computer keeps track of the keys, and if they change, it screams bloody murder. Modify that slightly to use self-signed SSL certs, and make the browser also remember the fake CA cert used to sign the cert and make the browser allow that CA cert to sign new certs (including new versions of the CA cert) in the future. With that relatively small change to the SSL infrastructure on the policy side, you would avoid warnings even as self-signed certs expire (as long as people take the time to update their certs once in a while).

In effect, such a scheme would be "good enough" for pretty much everything but e-commerce sites.

Re:And the CAs do ... what again? (1)

FrangoAssado (561740) | more than 3 years ago | (#35595394)

Now I understand, that seems more reasonable than what I thought you had proposed before.

I think that would probably be acceptable with the following extra requirement (you probably already thought of this): the browser should only allow the "fake" CA (from the self-signed cert) to sign other certificates for the domain you originally accepted it for. After all, you don't want to be in the situation where you accept a self-signed cert for foo.com and then suddenly you're unknowingly and silently accepting a bad certificate for amazon.com because foo.com is not trustworthy.

Still, that leaves the problem of how to revoke a self-signed cert (for when your site gets hacked, for example). Browsers can't make it too easy to remove the current self-signed cert and accept a new one (otherwise the whole system becomes useless), but it has to be easy enough so that when the old certificate gets compromised, almost every user can understand what's going on and do it on their own. I think that's a very hard problem, unless you're dealing with tech-savvy users (as is usually the case with SSH).

Re:And the CAs do ... what again? (1)

F'Nok (226987) | more than 3 years ago | (#35594254)

Site identity is the only way to know you're not being MitM'ed.

If someone uses a man-in-the-middle attack, your encryption is useless.

Identity is required to make encryption useful.

Re:And the CAs do ... what again? (3, Insightful)

dgatwood (11270) | more than 3 years ago | (#35595166)

Are you saying that SSH is not useful? Read my post again.

should be treated as a production cert, but with permanent memorization.

Emphasis mine. Yes, it is vulnerable to a man-in-the-middle attack. Exactly once. After you've made one connection, you're safe to connect to that particular host forever and ever... unless and until somebody legitimately has to change keys and certs without signing the new one with the same CA cert. At that point, you're unsafe one more time (and, hopefully, suspicious about the competence of the site's admins by this point).

And if you connect to the site, then take your computer to a different network and make the connection again and don't get screamed at (because the host key has changed), you can pretty much feel confident that you aren't getting hit by a man-in-the middle attack unless your computer is thoroughly 0wn3d, in which case it really doesn't matter if the traffic is encrypted because your keystrokes are probably being sniffed anyway. :-)

Re:And the CAs do ... what again? (1)

mvdwege (243851) | more than 3 years ago | (#35595706)

The problem is that identity confirmation is innate in providing correct encryption.

The problem is not the encryption per se, it is the key exchange. In order for Alice to securely talk to Bob, they have to agree on a shared secret to use for encryption. It is useless for Alice to provide Bob with a key unless she can verify she is not actually talking to Eve.

Mart

Re:And the CAs do ... what again? (0)

Anonymous Coward | more than 3 years ago | (#35595120)

RSA has it's own problems that are unrelated to this. No need to drag them into another security fight they can't win. We are likely to see the entire US federal government drop them as a customer in the next few months - and sooner if someone comes up with a viable alternative.

Big websites (1)

robmv (855035) | more than 3 years ago | (#35592296)

I ask myself what would happen if the websites were small ones, do the issuer move that fast and browsers fix that fast too?

I am not that sure. It is time that all CA must provide Certificate Revocation List and not be optional. Anye advantage of using a CA that provide it is nullified by the existence of CAs without CRL?

Re:Big websites (1)

heypete (60671) | more than 3 years ago | (#35592784)

I ask myself what would happen if the websites were small ones, do the issuer move that fast and browsers fix that fast too?

I am not that sure. It is time that all CA must provide Certificate Revocation List and not be optional. Anye advantage of using a CA that provide it is nullified by the existence of CAs without CRL?

All CAs do provide CRLs, but it's enormously inefficient to provide the files to brazillions of end-users, as they need to download the entire files at regular intervals and likely don't visit more than a handful of sites that may be listed in the CRL. There's also a window in between when CRLs are published and when the user actually downloads the list, usually on the order of a week or so.

Instead, most CAs and essentially all browsers support OCSP, which allows for live revocation checking. This has been the case for some time, as there's essentially no window where revoked certificates would be considered valid and it dramatically reduces the amount of network resources needed as the CAs need only provide replies to individual, on-demand queries rather than distributing much larger CRLs to everyone, whether they need it or not.

In short: don't worry.

Re:Big websites (1)

Amouth (879122) | more than 3 years ago | (#35592786)

i can say that they don't care about the smaller sites -- i revoked one of my certs just yesterday - (different reason still on a revocation list) and i'm sure it won't be put into any patch..

as i always explain the costs for certs to the book keeper - just paying the extortion fee.

What?!?! (1)

Charliemopps (1157495) | more than 3 years ago | (#35592376)

How dare they hack our computers!!! This isn't right! Someone should do something!! (I'm intentionally not going to reveal which country I'm from)

Re:What?!?! (1)

GodfatherofSoul (174979) | more than 3 years ago | (#35592556)

Totally different circumstances. In this case, Iran phishing for certs is a terrorist act. In the other, the Israelis and we were liberating the...uh...oppressed alpha and beta particles from your research facilities.

RA Authentication (0)

Anonymous Coward | more than 3 years ago | (#35592754)

Well the real take away is that the RA is authenticating with username and password only. A sensitive function like that of the RA should be (and often is) protected by two-factor authentication (smart card preferred subsequent to RSA break-in). This is where Comodo failed IMO.

Iran? (2)

Wolfling1 (1808594) | more than 3 years ago | (#35592886)

Don't they mean "The last proxy they were able to tracert to was in Iran"?

Re:Iran? (2)

kdsible (2019794) | more than 3 years ago | (#35592926)

If they said that it wouldn't have the same attraction.

Not Phony (0)

Anonymous Coward | more than 3 years ago | (#35592972)

The certs that were issued were illegitimate, but certainly not phony. Ill-gotten certs from a real and trusted central CA are real and trusted certs until the CRL says otherwise.

Can the updates be tampered with? (1)

robberbarron (171029) | more than 3 years ago | (#35594612)

I expect the Firefox update process would use SSL to download the update. Since mozilla.org is one of the sites with a bogus key, can this attack be used to sabotage the browser update process (assuming you are doing the update from the country that sponsored the attack).

If so, how do you detect it?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

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>