Phony Web Certs Issued For Google, Yahoo, Skype

Firefox/IE patches released,Comodo incident report by Anonymous Coward · 2011-03-23 08:26 · Score: 5, Informative

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

Well by The+MAZZTer · 2011-03-23 08:26 · Score: 1, Insightful

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

Re:Well by poetmatt · 2011-03-23 08:59 · Score: 2

Uh, you're kinda behind. IE and Firefox have already been patched, no doubt chrome too.
Re:Well by blair1q · 2011-03-23 08:59 · Score: 1

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 by click2005 · 2011-03-23 09:03 · Score: 1

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

--
I am a free slashdotter. I will not be modded, blogged, DRM'd, patented, podcasted or RFID'd. My life is my own.
Re:Well by John+Hasler · 2011-03-23 09:18 · Score: 1

I think he means anything originating with Comodo.

--
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Re:Well by cbiltcliffe · 2011-03-23 10:31 · Score: 1

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
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.

--
"City hall" in German is "Rathaus" Kinda explains a few things......
Re:Well by petermgreen · 2011-03-23 20:50 · Score: 2

Also given that we know how easy it is for goverments to coerce large buisnesses even in countries that supposedly have checks and balances you can basically assume that the goverment of any country with a recognised CA in it can get a cert to use to MITM your traffic.

--
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Re:Well by John+Hasler · 2011-03-24 00:28 · Score: 1

Of course governments can get any certs they want. Using force to take what they want is their business. However, you have to consider the threat model. Governments are not after your bank account details (yours already has them and others have bigger fish to fry). You'd be a fool to rely on SSL to hide subversive activities but it's probably adequate for buying electronic toys from Amazon (or at least governments aren't the threat there).

--
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Re:Well by pinkushun · 2011-03-24 02:55 · Score: 1

One user account in one RA was compromised.
The attacker created himself a new userID (with a new username and password) on the compromised user account.
In lay terms, a sales rep login was compromised, and used to issue the certs. And we all know what sales guys are like, don't we. ;-D

Patches? by oneiros27 · 2011-03-23 08:28 · Score: 2

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.

--
Build it, and they will come^Hplain.

Re:Patches? by julesh · 2011-03-23 08:34 · Score: 4, Informative

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.
Re:Patches? by natehoy · 2011-03-23 08:40 · Score: 1

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.

--
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
Re:Patches? by The+MAZZTer · 2011-03-23 08:58 · Score: 1

Chrome does but that feature is off by default (perhaps it is slow?).
Re:Patches? by heypete · 2011-03-23 10:12 · Score: 1

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? by blacklint · 2011-03-23 10:58 · Score: 2

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? by natehoy · 2011-03-23 11:25 · Score: 1

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.

--
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
Re:Patches? by ToasterMonkey · 2011-03-23 12:22 · Score: 1

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.
Re:Patches? by Eunuchswear · 2011-03-23 21:54 · Score: 1

To use a phony cert someone has to MITM you.
And if they can MITM the SSL connection they can break the connection to the revocation list server. The browser treats this as a soft fail.
https://blog.torproject.org/category/tags/ssl-tls-ca-tor-certificates-torbrowser

--
Watch this Heartland Institute video

An IP address doesn't mean it came from Iran by Anonymous Coward · 2011-03-23 08:31 · Score: 1

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 by Seumas · 2011-03-23 08:36 · Score: 1

And Iran. Iran so far away.
Re:An IP address doesn't mean it came from Iran by blair1q · 2011-03-23 09:08 · Score: 1

Are there a lot of open proxies in Iran?
Re:An IP address doesn't mean it came from Iran by cheater512 · 2011-03-23 09:56 · Score: 1

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

Re:Better Internet for Everybody by zach_the_lizard · 2011-03-23 08:31 · Score: 3, Informative

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.

--
SSC

CRLs? by hawguy · 2011-03-23 08:31 · Score: 4, Insightful

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

Re:CRLs? by Anonymous Coward · 2011-03-23 08:41 · Score: 5, Informative

Are CRLs completely broken and unused?
Yes, they are.
Re:CRLs? by BZ · 2011-03-23 08:43 · Score: 1, Informative

You may want to read http://www.imperialviolet.org/2011/03/18/revocation.html
Re:CRLs? by hey! · 2011-03-23 09:20 · Score: 2

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.

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Re:CRLs? by evilviper · 2011-03-23 13:51 · Score: 1

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.

--
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Re:CRLs? by Eunuchswear · 2011-03-23 21:57 · Score: 1

Your article merely explains that CRL implementations are fail safe.
Safety is in the eye of the beholder.
They're "fail safe" in the sense that you can still use SSL of the CRL server is down.
They're "fail deadly" in the sense that if someone can MITM you to get you to use a phoney cert they can also break the connection to the CRL server.

--
Watch this Heartland Institute video

no big deal by Anonymous Coward · 2011-03-23 08:40 · Score: 4, Interesting

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 by DarkOx · 2011-03-23 08:45 · Score: 1

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.

--
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Re:no big deal by praxis · 2011-03-23 11:59 · Score: 1

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 by zaphirplane · 2011-03-23 22:53 · Score: 1

comodo is not based in those places.
why do you think oh say africa is "safer" than eastern Europe?
Re:no big deal by yuhong · 2011-03-25 08:26 · Score: 1

But didn't, because you posted as AC.

Import CRL? by Stavr0 · 2011-03-23 08:43 · Score: 1

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

Re:Import CRL? by heypete · 2011-03-23 10:15 · Score: 1

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

Re:Better Internet for Everybody by sqlrob · 2011-03-23 08:54 · Score: 1

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:Firefox/IE patches released,Comodo incident rep by blair1q · 2011-03-23 08:57 · Score: 1

Firefox released 3.6.16 yesterday:

But did they already release 4.0.1?

Re:Firefox/IE patches released,Comodo incident rep by Nimey · 2011-03-23 09:00 · Score: 1

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.

--
Hail Eris, full of mischief...

E pluribus sanguinem

Things You Can Do On Your Own by Jah-Wren+Ryel · 2011-03-23 09:01 · Score: 4, Informative

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 - sort of crowd-sourcing approach
Certificate Patrol - remembers the certs of sites you've visited in the past and tells you when they change

--
When information is power, privacy is freedom.

Re:Things You Can Do On Your Own by jd · 2011-03-23 10:17 · Score: 1

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.

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Re:Things You Can Do On Your Own by caluml · 2011-03-23 10:45 · Score: 1

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

--
Get your own free personal location tracker

Re:Firefox/IE patches released,Comodo incident rep by kbrosnan · 2011-03-23 09:07 · Score: 3, Informative

Current releases of 3.6, 4.0 and 3.5 have the fix for this problem
http://www.mozilla.org/security/announce/2011/mfsa2011-11.html
http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates/

--
These people look deep within my soul and assign me a number based upon the order I joined. -Homer Simpson

Re:Better Internet for Everybody by Anonymous Coward · 2011-03-23 09:08 · Score: 2, Insightful

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

Why doesn't every website use HTTPS? by iamhassi · 2011-03-23 09:16 · Score: 1

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

Oh Irony!

--
my karma will be here long after I'm gone

Re:Why doesn't every website use HTTPS? by heypete · 2011-03-23 10:09 · Score: 2

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? by Anonymous Coward · 2011-03-23 11:32 · Score: 1

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? by heypete · 2011-03-23 12:19 · Score: 4, Interesting

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? by Bert64 · 2011-03-24 22:55 · Score: 1

These certificate authorities are for-profit companies, and admitting to a breach is extremely bad for business... If a breach occurs and is detected before it becomes public, there's every chance that these companies would try to hide what happened and hope nothing comes of it. Similarly a hacker who has breached such a site, is likely to keep it to themselves and use it in highly targeted attacks rather than setting up thousands of phishing sites which will rapidly get the problem noticed.
EV certs don't help, they are more expensive and *supposed* to do a more thorough background check of who requested the cert, however original ssl certs were supposed to do thorough checks too but now they just boil down to "can receive email on the domain in question"... Companies issuing certs will always aim to increase profit, so reducing the level of work required to issue a certificate is an effective way to increase profits in the short term.
Personally i think organisations like banks should issue their own certificates, that way you are not trusting any third party. For other sites, who knows...

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Re:Why doesn't every website use HTTPS? by heypete · 2011-03-30 10:10 · Score: 1

Personally i think organisations like banks should issue their own certificates, that way you are not trusting any third party. For other sites, who knows...
That raises the question of authentication (much like for self-signed certs): how do you know the bank's certificate is actually legitimate? Yes, you could contact the bank and ask for their key fingerprints, or be issued the key information when one opens an account and validate it when one gets home (much like SSH)...but I suspect that >99% of people would not know how to do this properly. This is a Bad Thing.
Can you cite any EV-issuing CA that does not do a "more thorough background check" of an applicant? If so, I'm sure the auditors and browser vendors would be interested to know.
Others have suggested some sort of cross-signatures for high-value sites, such banks. By having a certificate signed by both a commercial vendor (VeriSign and the like) and from a regulatory body (e.g. the banking regulators for that particular country), that would offer higher levels of validation.
Of course, users will continue to get phished by look-alike sites (who display little padlock icons in the site content just like the sites they're spoofing, not to mention sites where the login page is insecure [offering no authentication of the remote site prior to submitting credentials] even though the login information is submitted to an SSL-secured page)
As I've mentioned previously, the current PKI implementation is not perfect. It has its flaws, and can certainly be improved. Even with all of its flaws, it's had remarkably few problems over the years. Adding features in browsers like showing additional "trust flags" for cross-signed certs would be a nice start.
Re:Why doesn't every website use HTTPS? by Bert64 · 2011-03-31 22:49 · Score: 1

For a bank it's fairly easy, you already have an existing relationship with the bank and they will already have sent you username, password, possibly a physical authentication device like a token not to mention all the other stuff like cards and check books etc... For them to send you an SSL certificate fingerprint and a small booklet explaining how to install it is not a huge additional burden.
Commerce sites with whom you do not necessarily have an existing relationship are more problematic...
Speaking of which, a push system of funds transfer for purchases would make a lot more sense than the current pull system of credit cards...

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!

And the CAs do ... what again? by DriedClexler · 2011-03-23 09:18 · Score: 4, Insightful

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

--
Information theory is life. The rest is just the KL divergence.

Re:And the CAs do ... what again? by Anonymous Coward · 2011-03-23 10:33 · Score: 1

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? by dgatwood · 2011-03-23 10:33 · Score: 1

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.

--
Check out my sci-fi/humor trilogy at PatriotsBooks.
Re:And the CAs do ... what again? by Sancho · 2011-03-23 11:15 · Score: 2

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? by Pinky's+Brain · 2011-03-23 11:55 · Score: 3, Informative

Shouldn't be much longer ...
http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/?include_text=1
Well unless the CA's pay off Mozilla/Microsoft/Apple not to implement it.
Re:And the CAs do ... what again? by FrangoAssado · 2011-03-23 12:03 · Score: 1

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) 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? by F'Nok · 2011-03-23 13:09 · Score: 1

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? by FrangoAssado · 2011-03-23 15:00 · Score: 1

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? by dgatwood · 2011-03-23 15:44 · Score: 1

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.

--
Check out my sci-fi/humor trilogy at PatriotsBooks.
Re:And the CAs do ... what again? by dgatwood · 2011-03-23 15:53 · Score: 1

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.

--
Check out my sci-fi/humor trilogy at PatriotsBooks.
Re:And the CAs do ... what again? by dgatwood · 2011-03-23 16:00 · Score: 3, Insightful

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. :-)

--
Check out my sci-fi/humor trilogy at PatriotsBooks.
Re:And the CAs do ... what again? by FrangoAssado · 2011-03-23 16:52 · Score: 1

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? by Sancho · 2011-03-23 17:14 · Score: 1

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/ the page I get is actually https://www.gatwood.net/ but with https://www.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? by Sancho · 2011-03-23 17:18 · Score: 1

Eh, I kinda just realized that I'm coming off like a jerk. Sorry for my comments.
Re:And the CAs do ... what again? by mvdwege · 2011-03-23 18:21 · Score: 1

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

--
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Re:And the CAs do ... what again? by mpe · 2011-03-23 19:31 · Score: 1

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.

The current system of "authentication" is vulnerable to such attacks. Since in essence things come down to complete trust of a third party CA.
Re:And the CAs do ... what again? by petermgreen · 2011-03-23 21:17 · Score: 1

If they merely implement it then the MITM can simply implement a DNS proxy that strips all DNSSEC related information.
To fix the mess browsers basically have to drop support for the broken CA system completely and I don't see that happening any time soon.

--
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Re:And the CAs do ... what again? by petermgreen · 2011-03-23 21:20 · Score: 1

Since in essence things come down to complete trust of a third party CA.
It's worse than that, they come down to complete trust of every CA listed in your browsers root list and every CA they have delegated to.

--
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Re:And the CAs do ... what again? by roman_mir · 2011-03-23 23:03 · Score: 1

Just look through this thread for all the fanboyism of the CAs.
The argument comes up over and over again:
Why are browsers treating self signed certificates over HTTPS as some sort of a plague, while not doing the same for HTTP?
There is no difference between security of HTTP and HTTPS if the certificate is self signed, so just encrypt the traffic, DO NOT display the visual icon that signifies that the connection is secure and DO NOT bother the user with nonsense warnings.
Better yet, display the fingerprint near the address, make it obvious what the fingerprint the HTTPS connection is but for fuck sakes, stop the nonsense of pretending that HTTP is somehow better and HTTPS with a self signed cert for encryption is worse than HTTP.
Stop doing that. It's very counterproductive if you want more HTTPS on the web.

--
You can't handle the truth.
Re:And the CAs do ... what again? by esarjeant · 2011-03-24 00:34 · Score: 1

This kind of scheme makes perfect sense to me. Then individual companies would become their own certificate authority and could self-sign as needed. As a consumer, the only decision I need to make is if I trust the destination and after doing this once I shouldn't need to do it again. Of course, as a company I won't have to keep shelling out pointless cash to a CA that doesn't really do anything for me.
If my next visit to https://visa.com/ turns out to be a phishing site (don't bother following the link, it appears Visa's site is SSL challenged), then I'll likely get a prompt that says something like https://visa4scam.com/ has a certificate that you don't already trust - do you want to trust it? Smart browsers could say stuff like did you know that you already trust a certificate from visa.com and it has a different domain or IP address, and even indicate that this may not in fact really be Visa.
Honestly, I'm not sure the identity checks associated with EV really mean anything either. It's entirely for encryption purposes, and as a hacker unless I can hijack the actual domain there isn't much I can do with it.

--
Eric Sarjeant
eric[@]sarjeant.com
Re:And the CAs do ... what again? by dan_linder · 2011-03-24 01:32 · Score: 1

Eh, I kinda just realized that I'm coming off like a jerk. Sorry for my comments.
Wow, I'm impressed. The first sign of self-monitoring I've seen on Slashdot in a long time!
I sincerely wish more people would actually apologize like Sancho when they have an inkling they might have gone over the line.
You've restored my faith in the Slashdot community a bit.
Dan
Re:And the CAs do ... what again? by Lennie · 2011-03-24 03:20 · Score: 1

Don't know.
But you can go to https://www.startssl.com/ and get the same 'domain-validation' service for free. :-)

--
New things are always on the horizon
Re:And the CAs do ... what again? by Lennie · 2011-03-24 03:55 · Score: 1

Yeah, well, maybe.
Do you really think it will work reliably for normal users ? For technical users, I would just like to have the ability to restrict a CA to a few domains so when I visit a self-signed site like you mentioned. I can just add the CA to my CA-list, but just for that domain.
Probably something like publishing your certificate information in DNS and verifiable with DNSSEC is the real solution ?

--
New things are always on the horizon
Re:And the CAs do ... what again? by Lennie · 2011-03-24 03:59 · Score: 1

Paying for SSL-certificates is not needed anyway: https://www.startssl.com/

--
New things are always on the horizon
Re:And the CAs do ... what again? by Lennie · 2011-03-24 04:01 · Score: 1

Now that I think about it.
Doing selfsigned is not needed anyway ? Because why do you do selfsigned ? Because you don't want to pay for it ?
That problem was already solved last year:
https://www.startssl.com/

--
New things are always on the horizon
Re:And the CAs do ... what again? by Pinky's+Brain · 2011-03-24 06:24 · Score: 2

You can always make it the default ... so the first time a CA only certified website is shown ask "Do you want to add an exception for this website (if the certificate changes you will have to renew this exception) or a general exception to accept CA certifications to authenticate websites?" with some explanation that the last option is relatively safe, and will require no future user input, but websites which hash their certificates using DNSSEC are safer.
A gentle push in the right direction.

Big websites by robmv · 2011-03-23 09:34 · Score: 1

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 by heypete · 2011-03-23 10:21 · Score: 1

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 by Amouth · 2011-03-23 10:21 · Score: 1

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.

--
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
Re:Big websites by Lennie · 2011-03-24 04:04 · Score: 1

Did you know that for every revoked certificate which makes it on the list it adds atleast a terabyte of traffic for the CA per year. That is just one cert.

--
New things are always on the horizon
Re:Big websites by Amouth · 2011-03-24 04:52 · Score: 1

i'd love to see that backed up with real data..

--
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
Re:Big websites by Lennie · 2011-03-24 08:54 · Score: 1

I guess I remembered it a bit wrong, it was a lot less. But still a lot:
"How much costs ONE revocation? 0.2 KB x ~12,000,000 CRL downloads x 52 weeks x 7 years = More than 850 GB for ONE revocation."
http://twitter.com/eddy_nigg/status/11729927248
(Eddy Nigg owns/operates StartSSL)
Maybe some other CA need get more requests (more sites using their certs ?) and maybe the numbers also go up in the years (more users)

--
New things are always on the horizon
Re:Big websites by Lennie · 2011-03-24 09:01 · Score: 1

I think I just realized why this is.
A CRL is a list of all the id's which have been revoked and the list as a whole is a re-signed/re-encoded everytime something is added, so the whole list is downloaded each time.

--
New things are always on the horizon

What?!?! by Charliemopps · 2011-03-23 09:41 · Score: 1

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?!?! by GodfatherofSoul · 2011-03-23 09:59 · Score: 1

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.

--
I swear to God...I swear to God! That is NOT how you treat your human!

Re:Better Internet for Everybody by sexconker · 2011-03-23 09:42 · Score: 1

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 by overlordofmu · 2011-03-23 09:47 · Score: 2

Citation, please?

Re:Firefox/IE patches released,Comodo incident rep by robmv · 2011-03-23 10:18 · Score: 1

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

Iran? by Wolfling1 · 2011-03-23 10:32 · Score: 2

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

Re:Iran? by kdsible · 2011-03-23 10:36 · Score: 1

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

I think by fireylord · 2011-03-23 10:34 · Score: 2

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

Re:Better Internet for Everybody by causality · 2011-03-23 10:45 · Score: 1

Citation, please?

Citation provided per request.

--
It is a miracle that curiosity survives formal education. - Einstein

SSL Revocation mechanisms don't work by Khopesh · 2011-03-23 10:45 · Score: 1

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

As a matter of fact, yes. SSL revocation mehcanisms are broken 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 regarding blacklisted SSL certificates.

--
Use my userscript to add story images to Slashdot. There's no going back.

Re:Better Internet for Everybody by IDIIAMOTS · 2011-03-23 11:41 · Score: 2

http://www.spamhaus.org/statistics/countries.lasso

Can the updates be tampered with? by robberbarron · 2011-03-23 14:20 · Score: 1

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?

Re:Can the updates be tampered with? by Lennie · 2011-03-24 04:08 · Score: 1

In theorie everything in computing can be sabotaged, what is your point ? ;-)
But who cares about boring details, enjoy:
http://www.youtube.com/watch?v=jwVMxR8PcyM

--
New things are always on the horizon
Re:Can the updates be tampered with? by Lennie · 2011-03-24 04:11 · Score: 1

Seems that wasn't the original, anyway. I wanted to post a link to the Beastie Boys :-)
http://www.youtube.com/watch?v=ACraVoR01Yg

--
New things are always on the horizon

Why not move CRL into DNS? by mcrbids · 2011-03-23 16:09 · Score: 2

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!

--
I have no problem with your religion until you decide it's reason to deprive others of the truth.

Re:Why not move CRL into DNS? by Lennie · 2011-03-24 03:09 · Score: 1

That is why people in the know say, EV-certificates (green bar, hopefully proper verification of organisation) is still useful.
Yes I want DNSSEC, it will however take years.
It is now slowly spreading over the TLD's, 20%of the TLD's now have or will soon have DNSSEC support. That 20% is the 20% of the most important/largest TLD's like .net and .com .org and .info So probably in practise more than 50% can soon be signed.
The domainname providers and hosting providers are slowly starting to support it or have something in testing and so on.
It would be good if the access-providers and organisations like opendns would support it, but atleast opendns does not seem to be interrrested.
But if you want it to work for the user to be able to use it to very it in the browser. We'll need the operating systems to support it, I think recent Linux distributions support it and Windows 7.
Some DSL-/cable-/SOHO-routers block DNSSEC or don't allow the fallback to work, so they need to be fixed.
Also the protocol needs to be there and the browsers need to support it. There is an old RFC which might apply for this, but there seems to be some discussion if that is the right solution.
The computer needs to be on the correct time, not like with HTTPS where it can be off a few months and it might work. But more correct within minutes.
When all this exists, yes we can use it for that.
There are also some fallback proposals discusses, but nothing which has 'industry support' (whatever that means). Actually DNSSEC doesn't have have that, some people think DNSSEC gives to much more to the root (thus the US government) and so on. I think the solution for that might be to move that to Switzerland and make it independant like some other organisations.

--
New things are always on the horizon
Re:Why not move CRL into DNS? by Compaqt · 2011-03-24 03:13 · Score: 1

Under DNSSEC, how do you verify the . root server (or other top-level servers: com, org, uk, us)?

--
I'm not a lawyer, but I play one on the Internet. Blog
Re:Why not move CRL into DNS? by baerm · 2011-03-25 03:42 · Score: 1

A public key on the local recursive dns is used to verify the root server. The root server verifies the tld's and so on.

Great article, terrible proposal by jginspace · 2011-03-23 17:30 · Score: 1

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:Great article, terrible proposal by BZ · 2011-03-24 00:06 · Score: 1

Actually, the author does address that. They key is that the private key would not change when the certificate changes. Unless the MiM has cracked the old cert (in which case you're screwed no matter what), they couldn't impersonate an update that keeps the same private key.
Re:Great article, terrible proposal by jginspace · 2011-03-24 01:29 · Score: 1

Actually, the author does address that. They key is that the private key would not change when the certificate changes. Unless the MiM has cracked the old cert (in which case you're screwed no matter what), they couldn't impersonate an update that keeps the same private key.
The two scenarios I'm thinking of when either: 1) a government, or 2) someone controlling you local network, manage to pass you fake certs. I can't say if the private key does or doesn't change in these two scenarios but the problem still remains - I'm being alerted to a certificate being renewed and I'm having to check up. You (or the author) don't address the 'whatcouldpossiblygowrong' or the 'escalation of cludginess' issues.
Re:Great article, terrible proposal by BZ · 2011-03-24 01:40 · Score: 1

The only way to issue a cert with the same private key as another cert is to know that private key. If you know the private key and you know the certificate the server sends in response to an SSL request, then you can simply impersonate the server's existing certificate right now. In other words, a "certificate" is a pair consisting of a private key and the public bits that the SSL server puts on the wire when you connect to it. Everyone knows the latter, so "all" you need to MITM is to know the former.
Right now, if someone creates a fake cert for a domain it'll have the right domain name but a different key pair from the real cert for that domain. Again, being able to issue a fake cert with the same key pair means you don't need a "fake" cert; you just have the real one!
You're right that if this proposal were implemented, then the "new certificate" alert would need to only happen in cases when the key pair for a hostname changes. But that seems eminently doable.

any alternative to updates? by jginspace · 2011-03-23 18:00 · Score: 1

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?

Re:any alternative to updates? by zaphirplane · 2011-03-23 22:44 · Score: 1

there is, it's called Certificate Revocation and Online Certificate Status Protocol
why they are not implemented and we have to rely on installing new s/w, I'll leave to those in the know
Re:any alternative to updates? by Anonymous Coward · 2011-03-23 23:58 · Score: 1

[I work for Comodo, these are not an official response, see the incident report etc for that]
OCSP is implemented in practically all browsers, it is not turned on to hard fail by default in most. Comodo, VeriSign and almost all major CAs have supported it for at least five years.
It appears that this is going to change in the near future and browsers will start to hard fail. Other measures being considered include short term certificates.
The OCSP servers are not receiving requests for the fraudulently issued certs, thus it appears that either the certs are not currently deployed or OCSP traffic is also being blocked - which would be causing a rather large impact in the area affected and would be rather noticeable to end users.
As for the idea that mentioning Iran helps us, what planet are people living on? The easiest way to have the incident forgotten would have been to bury that piece of information and pass the incident off as being financial crime. The point of telling people was to let them know that the old assumptions of who is a target and what level of measures they need no longer apply. Internet security just got a lot harder and people have to act accordingly.
Re:any alternative to updates? by jginspace · 2011-03-24 00:21 · Score: 1

there is, it's called Certificate Revocation and Online Certificate Status Protocol
As has been discussed further down, those two methods are broken. I want to delete the certificates/authorities *as soon as* I find out they are suspect - not wait for a faulty mechanism to check up on certificates that I *already know* are compromised.
Specifically, someone could send back a 500 error when you try to access those sites. Most of today's browsers, on receiving that 500 error, will choose to continue treating the certificate as legit - but will give you almost zero notification that anything is amiss.

Re:Better Internet for Everybody by shutdown+-p+now · 2011-03-23 18:34 · Score: 1

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.

Comodo has issued rogue certificates before by Anonymous Coward · 2011-03-23 19:07 · Score: 1

http://it.slashdot.org/article.pl?sid=08/12/23/0046258
Personally I wouldn't trust this CA which delegates the critical verification process to resellers...

Re:Firefox/IE patches released,Comodo incident rep by Eunuchswear · 2011-03-23 21:49 · Score: 1

Comodo knew about this on the 15th.

Chromium was patched on the 16th/17th.

Firefox was patched on the 17th,

https://blog.torproject.org/category/tags/ssl-tls-ca-tor-certificates-torbrowser

Executive summary - SSL is broken as designed.

--
Watch this Heartland Institute video

Mobile??? by brunes69 · 2011-03-23 23:57 · Score: 1

Does anyone have any idea how to update the CRL on a mobile phone, specifically, IOS?

Great...you cant even trust google now by hesaigo999ca · 2011-03-24 00:52 · Score: 1

Google, yahoo, skype, they all have been compromised,
I am glad I shut down my computer, and writing this with my pen and paper...

mozilla.com certs? by Compaqt · 2011-03-24 02:58 · Score: 1

Wait, what happens if when you go to mozilla.com to download an update, the cert for mozilla.com itself has been compromised?

--
I'm not a lawyer, but I play one on the Internet. Blog

Slashdot Mirror

Phony Web Certs Issued For Google, Yahoo, Skype

117 of 151 comments (clear)