Mozilla Checks If Firefox Is Affected By Same Malware Vulnerability As Tor (arstechnica.com)

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.

Comments

Obtaining fraudulent certificates

[ShaunC]

While it probably would be challenging to hack a CA or trick one into issuing the necessary certificate for addons.mozilla.org

That depends on the CA, some are more easy to trick than others...

Thanks for looking in to that...

[The-Ixian]

Let us know when you find something out...

Down with the CA

[alexandre]

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:Down with the CA

[Joce640k]

And replace it with....what?

Re:Down with the CA

[jonwil]

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 trust a site based on whether enough entities you already trust have signed it or not.

And there are probably others out there.
The big problem is convincing Microsoft, Apache, Mozilla, Google, Apple and the other major makers of web browsers and web servers to support one or more of these alternatives out-of-the-box.

Re:Down with the CA

[Hizonner]

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 think there's some vast shadowy conspiracy with central control. Just a lot of players with reasons to fuck things up. Sometimes they may cooperate, but probably they mostly just engage in "leaderless sabotage".

The standards bodies/processes at least try to defend against commercial interests who want to get things they control standardized over technically better alternatives. But once they do get captured, they're hard to un-capture. And they have almost no defenses against players whose only interest is simply to make things not work. And because mentioning the possibility sounds like a conspiracy theory, it's even harder to get them to adopt such defenses.

Re:Down with the CA

[gweihir]

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

Re:Down with the CA

[gweihir]

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:Down with the CA

[Joce640k]

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:Down with the CA

[gweihir]

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:Chrome

[alexandre]

Yeah uh ... no.
That won't solve fake but valid certificates magically.

Sucks

[ArtemaOne]

Still don't like it.

Re:It's not hard to hack a CA

[Hizonner]

The idiots behind let's encrypt don't understand that the first and role of the public CA system is identity non-repudiation, but they issue certificates with any name to anyone who asks.

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.

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:It's not hard to hack a CA

[Hizonner]

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:It's not hard to hack a CA

[FatdogHaiku]

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)

Not a vulnerability

[manu0601]

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

Why do Mozilla use the HTTPS CA system for this ?

[OdinOdin_]

Surely signing extensions and signing software updates use two different certs and either cert is uses the existing HTTPS SSL/TLS CA system for that ?

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 its legitimacy) and a client (that needs a mechanism to verify the servers legitimacy). But there is only 1 party involved with Mozilla extension and Mozilla browser software updates (although thats not completely true to OS vendor might also be involved for OS level code signing).

So while the might use HTTPS under that system, the payload it carried is also signed right ? And that verification process is using a CA system that only Mozilla control ?

Re:Open source as failure.

[gweihir]

Poster is stupid? Check.

Seriously, if you must troll, at least but some minimal thought into it. That is if you are capable.

Re:HPKP was ill-thought, and thus has seen little

[manu0601]

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.

Re:Time

[Joce640k]

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 one good ones should come from your browsing history. The most trustworthy certificates are the oldest ones because it's very difficult to alter history no matter how big your spying budget is..