Mozilla Checks If Firefox Is Affected By Same Malware Vulnerability As Tor (arstechnica.com) 45
Mozilla is investigating whether the fully patched version of Firefox is affected by the same cross-platform, malicious code-execution vulnerability patched on Friday in the Tor browser. Dan Goodin, reporting for ArsTechnica: The vulnerability allows an attacker who has a man-in-the-middle position and is able to obtain a forged certificate to impersonate Mozilla servers, Tor officials warned in an advisory. From there, the attacker could deliver a malicious update for NoScript or any other Firefox extension installed on a targeted computer. The fraudulent certificate would have to be issued by any one of several hundred Firefox-trusted certificate authorities (CA). While it probably would be challenging to hack a CA or trick one into issuing the necessary certificate for addons.mozilla.org, such a capability is well within reach of nation-sponsored attackers, who are precisely the sort of adversaries included in the Tor threat model. In 2011, for instance, hackers tied to Iran compromised Dutch CA DigiNotar and minted counterfeit certificates for more than 200 addresses, including Gmail and the Mozilla addons subdomain.
Obtaining fraudulent certificates (Score:1)
While it probably would be challenging to hack a CA or trick one into issuing the necessary certificate for addons.mozilla.org
That depends [google.com] on the CA [mozilla.org], some are more easy to trick than others...
Re: (Score:2)
Poster is stupid? Check.
Seriously, if you must troll, at least but some minimal thought into it. That is if you are capable.
Re:It's not hard to hack a CA (Score:4, Insightful)
You don't have a damned clue how this stuff works, do you?
All the public CAs issue non-EV certificates based on the ability to control email and/or DNS information for domains, and most of them automate it. Their verification standards for non-EV certificates are on page 13 of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.7.pdf [cabforum.org].
Let's Encrypt does exactly the same verification and meets those standards. Let's Encrypt is actually ahead of some of them in that it uses a published and publicly reviewed verification protocol (ACME) to check control over the DNS.
Yes, the CA infrastructure is shit, mostly because all you have to do to impersonate any domain is to find any CA you can trick. No, Let's Encrypt is not any worse than the hundreds of other CAs that the browsers trust.
Re: (Score:2)
Oh, I forgot the other major reason that the CA infrastructure is shit, which is that those verification standards are indeed too lax. If you can impersonate the server in the first place, you can probably fake control of the domain well enough to get a certificate. But again Let's Encrypt is no worse than any of the others.
Re: (Score:2)
I don't know about the ACME verification protocol, but stay far away from their rocket powered roller skates...
Wile E. Coyote, SG, sss. (Super Genius, still smoldering somewhat)
Chrome (Score:1)
End of story.
Re: (Score:2)
Yeah uh ... no.
That won't solve fake but valid certificates magically.
Sucks (Score:2)
Thanks for looking in to that... (Score:2)
Let us know when you find something out...
Down with the CA (Score:3)
The whole F-ing CA model is broken beyond repair...
Can we get rid of this joke of a model that we're all relying upon for the rest?
Re: (Score:2)
And replace it with....what?
Re: (Score:2)
The EFF Sovereign Keys proposal. (although it was developed in the days before block-chain technology became widely known so replacing the centralized servers with a block-chain style system may make the proposal better)
DNSSEC and DANE (it would be harder to compromise the DNS system and get a fake DANE blob that matches the bogus info for the hackers servers but also passes full DNSSEC validation)
PGP style web-of-trust where certificates get signed by multiple different entities and you choose whether to t
Re: (Score:2)
I honestly think that people are actively sabotaging all of the above approaches.
It's to the advantage of the existing CAs to go make trouble every time something like that comes up at the IETF or wherever. And it's to the advantage of the world's spooks to slow down any standardization that improves security, preferentially slow down the standardization of the most effective alternatives, and make sure that everything is so complicated and option-laden that you can always find a mode you can break.
I don't
Re: (Score:2)
The way I see it this problem comes down to detecting MITM attacks, not trying to prevent them.
People need easy, automated ways to communicate with each other to check if they're seeing the same public keys as everybody else.
If we use other site's certificates to sign the certificates being compared it will become exponentially difficult for the NSA to intercept and alter the information arriving at your PC. Only need ONE good certificate needs to get through and the whole attack against you will fail.
.
That
Re: (Score:2)
No security is better than no security combined with a false sense of security. I say we throw it away completely as a historical aberration. A PGP-like web-of-trust (often ridiculed) does a far, far better job in actual reality.
Re: (Score:2)
A web of trust can be compromised, too.
Webs of trust rely on humans to make them work. Humans are fallible, evil, can be bribed to change sides, etc.
Look at Tor. Tor works when there's not many evil nodes but the evidence is that the NSA is setting up tens of thousands of their own nodes all over the place. The chances of not going through several NSA-owned nodes is very slim.
Re: (Score:2)
If you want a solution that cannot be compromised, then you are a) clueless and b) need to disconnect from the Internet. The question is not at all whether something "can" be compromised, it is how difficult it is in relation to how easy it is to notice. And there a web-of-trust shines.
Re: (Score:2)
It is. And it is no surprise that it is. No security-model that requires trust in a lot of different instances that are subject to a lot of different attacks and pressure has ever worked well.
Incidentally, when the Internet was still young and the CA system as new, smart people already anticipated this. The bureaucrats wanted it anyways, and post-Snowden, I am very much inclined to believe they wanted a broken system. I trust an official certificate about as far as I can throw it when chiseled into a large
Not a vulnerability (Score:3)
Someone with a forged certificate can impersonate a web site. This is not a vulnerability, this is a feature of the threat model: we blindly trust CA for issuing only legitimate certificates.
This weakness in the security model can still be addressed, because fortunately we already have a workaround for it: HTTP Public Key Pinning (HPKP) [wikipedia.org].
Re: (Score:2)
HPKP carries a massive DoS risk that cannot be mitigated if you suffer a breach of key, sabotage, or a simple operational error.
True. If someone manages to spoof your server's response, an evil HPKP header can be sent so that your server will not be reachable anymore. The best protection against this is to implement HPKP on your server, so that the evil HPKP header cannot be accepted.
Why do Mozilla use the HTTPS CA system for this ? (Score:1)
Mozilla are a company that clearly deals with and understand X.509 certificates, so surely anything they do themselves where they control both the distribution and verification they use their own CA.
The only purpose of the "trusted CA" system is to issue certificates where there are three parties involved, a mutually trusted CA, a server (that needs to verify