Phony Web Certs Issued For Google, Yahoo, Skype 151
Gunkerty Jeb writes "A major issuer of secure socket layer (SSL) certificates acknowledged on Wednesday that it had issued 9 fraudulent SSL certificates to seven Web domains, including those for Google.com, Yahoo.com and Skype.com following a security compromise at an affiliate firm. The attack originated from an IP address in Iran, according to a statement from Comodo Inc."
Firefox/IE patches released,Comodo incident report (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
Re: (Score:2)
Firefox released 3.6.16 yesterday:
But did they already release 4.0.1?
Re: (Score:2)
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: (Score:3, Informative)
http://www.mozilla.org/security/announce/2011/mfsa2011-11.html [mozilla.org]
http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates/ [mozilla.com]
Re: (Score:2)
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? (Score:2)
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?
mozilla.com certs? (Score:2)
Wait, what happens if when you go to mozilla.com to download an update, the cert for mozilla.com itself has been compromised?
Re: (Score:2)
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
Re: (Score:2)
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 [torproject.org]
Executive summary - SSL is broken as designed.
Mobile??? (Score:2)
Does anyone have any idea how to update the CRL on a mobile phone, specifically, IOS?
Well (Score:2, Insightful)
Re: (Score:3)
Uh, you're kinda behind. IE and Firefox have already been patched, no doubt chrome too.
Re: (Score:2)
I think he means anything originating with Comodo.
Re: (Score:2)
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: (Score:2)
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? (Score:2)
Oh Irony!
Re: (Score:3)
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? (Score:5, 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: (Score:2)
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 h
Re: (Score:2)
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 appli
Re: (Score:2)
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 w
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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).
Re: (Score:2)
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 [thewebsiteisdown.com]. ;-D
Patches? (Score:3)
What, they don't support revocation lists already? This should be a non-issue, once someone realized it happened.
Re:Patches? (Score:5, 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.
Why not move CRL into DNS? (Score:3)
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. The
Re: (Score:2)
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 s
Re: (Score:2)
Under DNSSEC, how do you verify the . root server (or other top-level servers: com, org, uk, us)?
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 [torproject.org]
Re: (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 authoriti
CRLs? (Score:5, Insightful)
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? (Score:5, Informative)
Are CRLs completely broken and unused?
Yes, they are. [imperialviolet.org]
Re: (Score:3)
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 po
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2, Informative)
You may want to read http://www.imperialviolet.org/2011/03/18/revocation.html [imperialviolet.org]
Great article, terrible proposal (Score:2)
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 basi
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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.
R
SSL Revocation mechanisms don't work (Score:2)
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 (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: (Score:2)
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: (Score:2)
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: (Score:2)
But didn't, because you posted as AC.
Things You Can Do On Your Own (Score:5, 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 [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: (Score:2)
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: (Score:2)
And the CAs do ... what again? (Score:5, 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
Re: (Score:2)
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
Re: (Score:3)
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: (Score:2)
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
Re: (Score:2)
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 lam
Re: (Score:2)
Eh, I kinda just realized that I'm coming off like a jerk. Sorry for my comments.
Re: (Score:2)
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 browse
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
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/ [visa.com] turns out to be a phishing site (don't bother following the link, it
Re: (Score:2)
Paying for SSL-certificates is not needed anyway: https://www.startssl.com/ [startssl.com]
Re:And the CAs do ... what again? (Score:4, Insightful)
Are you saying that SSH is not useful? Read my post again.
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: (Score:2)
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 ?
Re: (Score:2)
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/ [startssl.com]
Re: (Score:2)
Just look through this thread [slashdot.org] 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 n
Re: (Score:2)
Don't know.
But you can go to https://www.startssl.com/ [startssl.com] and get the same 'domain-validation' service for free. :-)
Re:And the CAs do ... what again? (Score:4, Informative)
Shouldn't be much longer ...
http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/?include_text=1 [ietf.org]
Well unless the CA's pay off Mozilla/Microsoft/Apple not to implement it.
Re: (Score:2)
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.
Re: (Score:3)
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 (Score:2)
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: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
i'd love to see that backed up with real data..
Re: (Score:2)
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 [twitter.com]
(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)
Re: (Score:2)
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.
What?!?! (Score:2)
Re: (Score:2)
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.
Iran? (Score:2)
Great...you cant even trust google now (Score:2)
Google, yahoo, skype, they all have been compromised,
I am glad I shut down my computer, and writing this with my pen and paper...
Re:Better Internet for Everybody (Score:4, 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.
Re: (Score:3)
Re: (Score:2)
Citation, please?
Citation provided per request. [google.com]
Re: (Score:3)
Re: (Score:2)
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: (Score:2, Insightful)
Wow, broken clocks are right twice a day it seems.
Re: (Score:2)
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.
Re: (Score:2)
Are there a lot of open proxies in Iran?
Re: (Score:2)
What about a closed proxy? Someone paid to proxy it from Iran?
I think (Score:2)
That I hear a whoosh there. Maybe its that big group of birds up above? I think that they're seagulls ;)
Re: (Score:2)
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: (Score:2)
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 [youtube.com]
Re: (Score:2)
Seems that wasn't the original, anyway. I wanted to post a link to the Beastie Boys :-)
http://www.youtube.com/watch?v=ACraVoR01Yg [youtube.com]