Three central issues informed our decision:

1) Failure to notify. DigiNotar detected and revoked some of the fraudulent certificates 6 weeks ago without notifying Mozilla. This is particularly troubling since some of the certificates were issued for our own addons.mozilla.org domain.

2) The scope of the breach remains unknown. While we were initially informed by Google that a fraudulent *.google.com certificate had been issued, DigiNotar eventually confirmed that more than 200 certificates had been issued against more than 20 different domains. We now know that the attackers also issued certificates from another of DigiNotar’s intermediate certificates without proper logging. It is therefore impossible for us to know how many fraudulent certificates exist, or which sites are targeted.

3) The attack is not theoretical. We have received multiple reports of these certificates being used in the wild.

Mozilla has a strong history of working with CAs to address shared technical challenges, as well as responding to and containing breaches when they do arise. In an incident earlier this year we worked with Comodo to block a set of mis-issued certificates that were detected, contained, and reported to us immediately. In DigiNotar’s case, by contrast, we have no confidence that the problem had been contained. Furthermore, their failure to notify leaves us deeply concerned about our ability to protect our users from future breaches.

Staat der Nederlanden Certificates

DigiNotar issues certificates as part of the Dutch government’s PKIoverheid (PKIgovernment) program. These certificates are issued from a different DigiNotar-controlled intermediate, and chain up to the Dutch government CA (Staat der Nederlanden). The Dutch government’s Computer Emergency Response Team (GovCERT) indicated that these certificates are issued independently of DigiNotar’s other processes and that, in their assessment, these had not been compromised. The Dutch government therefore requested that we exempt these certificates from the removal of trust, which we agreed to do in our initial security update early this week.

The Dutch government has since audited DigiNotar’s performance and rescinded this assessment. We are now removing the exemption for these certificates, meaning that all DigiNotar certificates will be untrusted by Mozilla products. We understand that other browser vendors are making similar changes. We’re also working with our Dutch localizers and the Bits of Freedom group in the Netherlands to contact individual site operators using affected certificates (based on the EFF’s SSL Observatory data).

The integrity of the SSL system cannot be maintained in secrecy. Incidents like this one demonstrate the need for active, immediate and comprehensive communication between CAs and software vendors to keep our collective users safe online.

Johnathan Nightingale
Director of Firefox Engineering

On 15th March 2011, a RA partner of the Comodo CA suffered an internal security breach (Comodo incident report). The attacker used the RA’s account with Comodo to cause 9 fraudulent certificates to be issued.

The domain names of the certificates were as follows:

• addons.mozilla.org
• login.live.com
• mail.google.com
• www.google.com
• login.yahoo.com (x3)
• login.skype.com
• global trustee

These certificates were issued between 6 and 8pm on 15th March from the UTN-UserFirst-Hardware root, without the use of an intermediate certificate. The attack was discovered almost immediately by an internal Comodo check, and the certificates were revoked (via both CRL and OCSP). The compromised RA account has been suspended.

So far, according to Comodo, the only OCSP activity seen relating to these certificates has been two hits, one from the attacker’s IP and one from another very close by, plus hits from testing by Comodo and the notified companies. This suggests that the certificates have not been deployed in an attack, though it is possible that the attackers would block OCSP requests as well.

The IP address 212.95.136.18 appeared to be associated with the attack. According to Comodo, this IP address is an ADSL connection in Iran. From the OCSP traffic mentioned above, we think the attacker is aware that the certificates have been revoked.

Risk Analysis

Given the above, we do not believe that there has been a root key compromise. Nevertheless, an attacker armed with these fraudulent certificates and an ability to control their victim’s network could impersonate the sites in a way that would be undetectable to most users.

With particular regard to Mozilla, the certificate for ‘addons.mozilla.org’ would allow the attacker to imitate the addons.mozilla.org website, and potentially deceive users into downloading malicious software. However, they would not be able to interfere with automatic updates, either to Firefox or to addons. These mechanisms use different domain names, and updates to Firefox also do additional checks to match the certificate issuer to the expected value (which is not UTN-UserFirst-Hardware).

Mitigating Risk

On being informed of this issue by Comodo at 9.47pm GMT on 16th March, Mozilla considered a number of technical avenues. Although Comodo’s revocation is a significant mitigating step, we thought that additional measures made sense and eventually decided to hard-code a blacklist of the certificate serial numbers into Firefox. We therefore produced RC2 of Firefox 4 (released as Firefox 4 final on 22nd March), with two additional code patches (1, 2). These patches disable these specific certificates, plus one additional certificate issued to us by Comodo for testing, making a total of 10. These fixes were also included in updates to Firefox 3.5 and 3.6, also released on 22nd March. As soon as all the patched versions were released, we made a release announcement with some details of the problem.

Mozilla did not publish the information we received prior to shipping a patch. In early discussions, we were concerned that any indication that we knew about the attack would lead to attackers blocking our security updates as well. We also recognized that the obvious mitigation advice we might offer (to change Firefox’s security preferences to require a valid OCSP response in all cases, or to remove trust from Comodo’s certificates, or both) risked causing a significant portion of the legitimate web to break as well.

Additionally, neither we nor Comodo have found any evidence of access to their OCSP responder being blocked, either in Iran or anywhere else. We have also found no evidence of any other sort of attack.

In hindsight, while it was made in good faith, this was the wrong decision. We should have informed web users more quickly about the threat and the potential mitigations as well as their side-effects.

Mozilla has requested that Comodo do the following:

1. Publish a full account of exactly what happened. (So far: they have published an incident report and a blog post.)
2. Monitor their OCSP logs for evidence of use of these certificates, or evidence that access to their OCSP responders is being blocked from any geographical locations. (So far: no sign of use or blocking.)
3. Cancel all relationship with the RA concerned. (So far: the RA is suspended.)
4. Change their practices to use intermediate certs rather than issuing directly off the root, and use a different one for each RA.

Ongoing Discussion

Unfortunately, the practice of issuing certs directly from the root eliminated some possible steps we could have taken to mitigate the problem. We are concerned about the amount of trust Comodo seems to have placed in RAs whose network security they did not oversee.

Comodo appropriately revoked the certificates immediately and notified the major browser vendors so that more proactive actions could be taken. We are still working with Comodo to find more information on how the breach occurred and what measures they plan to put in place to prevent future recurrences.

This issue raises many questions about the systems surrounding authentication and security on the web. We intend to have a vigorous discussion about what technical and policy changes we can make to significantly improve the situation. You can join the discussion in the mozilla.dev.security.policy forum.

Mozilla has been informed about the issuance of several fraudulent SSL certificates for public websites. The certificates have been revoked by their issuer which should protect most users. This is not a Firefox-specific issue. As part of our ongoing commitment to providing a secure Web experience for users, we have updated Firefox 4.0, 3.6, and 3.5 to recognize these certificates and block them automatically.

Impact to users

Users on a compromised network could be directed to sites using the fraudulent certificates and mistake them for the legitimate sites. This could deceive them into revealing personal information such as usernames and passwords. It may also deceive users into downloading malware if they believe it’s coming from a trusted site.

Status

Current versions of Firefox are protected from this attack. We are still evaluating the possibility of further response to this issue. We encourage all users to keep their software up to date by regularly applying security updates.

Credit

This issue was reported to us by the Comodo Group, Inc., the certificate authority responsible for issuing the fraudulent certificates.

Firefox users don’t have to do anything in order to gain this protection. Simply install Firefox 4 and you will instantly receive all of the benefits that Content Security Policy has to offer. Easy!

If you are a web developer who wants to learn how to deploy this feature on your site, head over to the Mozilla Developer Center and see how easy it is to write a policy.

We expect Content Security Policy to be widely adopted very quickly. There are popular commercial websites like Twitter who are already using it, and there are CSP plugins for many of the popular content management systems like WordPress, Django and Drupal. If this works out according to plan, the curtain will soon be coming down on a broad range of nasty web bugs!

Brandon Sterne
Man-in-the-Middle

The introduction of this tool reinforces the importance of websites configuring themselves to require secure connections.

Not too long ago we announced HTTP Strict-Transport-Security that can be used to — among other things — ensure your Facebook or Twitter cookies can’t be sniffed by someone using a tool like Firesheep. In fact, it’s built into Firefox 4. To protect their users from the this attack, a site simply needs to set the Strict-Transport-Security HTTP header when they serve you a secure log-in page, and make the rest of their site available over HTTPS. Firefox will take care of the rest: automatically fetching that site over a secure connection and blocking any third parties from seeing the unencrypted traffic.

We recommend that website authors make use of this header in order to protect their users.

But this technology is new to Firefox 4. To get HTTP Strict-Transport-Security support in Firefox 3.6, you will need to install an add-on that implements it such as ForceTLS. ForceTLS also gives you a way to opt-in to this extra security for sites who haven’t yet started sending that helpful HTTP header; it provides a user interface to add and remove sites that should never be contacted insecurely. Both HSTS and the manual opt-in are also available as part of NoScript. However, manually opting-in to HSTS on a site which does not yet make itself fully available securely may break the site; not all sites are ready for secure access.

If you are already using Firefox 4 beta or nightly versions, you can enable the additional controls with the STS-UI add-on. While the core Strict-Transport-Security features are already built into Firefox 4, this UI gives advanced users the ability to further ensure the security of their connections.

Sid Stamm
Conspiracy Theorist

A website can choose to include the x-frame-options header to protect against malicious framing of web content by third parties. For example a malicious site might frame a website from another domain and surround the framed site with advertisements. Alternatively, a malicious site could use a CSS layer attack called ClickJacking to trick users into performing unintended actions within the framed website that is obscured by overlaid CSS layers.

The x-frame-options header supports the following values:
SAMEORIGIN – allows only sites from the same domain to frame the page
DENY – prevents any site from framing the page

Additional Reading:
Mozilla Developer Network article
Microsoft Developer Network article
OWASP Clickjacking Article

Michael Coates
Web Security

We’re excited about this because it enables sites to easily give their users lots more protection from man-in-the-middle attacks when they’re using an untrustworthy network.

Grab a nightly build, and let us know what you think! The folks over at PayPal are serving a Strict-Transport-Security header, if you’d like to check it out.

More Info:

• A bit more about HSTS
• Mozilla Hacks blog entry
• Draft specification (technical details)

Sid Stamm
Conspiracy Theorist

For additional information please see Mozilla Foundation’s Security Advisory MFSA-10-08 as well as the Firefox 3.6.2 Release Notes. We urge users to promptly update to this release by selecting “Check for Updates…” from the “Help” menu, or by visiting https://www.mozilla.com/ for a free download.

We hate crashes. When Firefox crashes, we try to get you back on your feet as quickly as possible, but we’d much rather you not crash in the first place. In Firefox 3.6, we are changing the way that some third party software hooks into Firefox which should eliminate a good chunk of those crashes without sacrificing our extensibility in any way. In the process, we’ll also be giving you greater control over the code that runs in your browser.

Background

Firefox is built around the idea of extensibility – it’s part of our soul. Users can install extensions that modify the way their browser looks, the way it works, or the things it’s capable of doing. Our add-ons community is an amazing part of the Mozilla ecosystem, one we work hard to grow and improve.

In addition to the standard mechanism for extending the browser via add-ons and plugins, though, there has historically been another way to do it. Third-party applications installed on your machine would sometimes try extend Firefox by just adding their own code directly to the “components” directory, where much of Firefox’s own code is stored.

There are no special abilities that come from doing things this way, but there are some significant disadvantages. For one thing, components installed in this way aren’t user-visible, meaning that users can’t manage them through the add-ons manager, or disable them if they’re encountering difficulties. What’s worse, components dropped blindly into Firefox in this way don’t carry version information with them, which means that when users upgrade Firefox and these components become incompatible, there’s no way to tell Firefox to disable them. This can lead to all kinds of unfortunate behaviour: lost functionality, performance woes, and outright crashing – often immediately on startup.

In Firefox 3.6 (including upcoming beta refreshes), we’re closing this door. Third party applications can still extend Firefox via add-ons and plugins the way they always could, but the components directory will be for Firefox only.

What Does This Mean For Me?

If you’re a Firefox user, this should be 100% positive. You don’t have to change anything, your regular add-ons should continue to work properly – you just might notice fewer crashes or odd bugs. If you do notice that something has stopped working, particularly a third party addition to Firefox, you might want to contact the producer of that addition to ensure they know about the change.

If you’re a Firefox component developer, this shouldn’t be a big change, either. If you’re already packaging your additions as an XPI, installed as an add-on it’s business as usual. If you have been dropping components directly, though, you’ll need to change to an XPI-based approach. Our migration document on the Mozilla Developer Connection outlines the changes you’ll need to make, and should be pretty straightforward. The good news is that once you’ve done this, your add-on will actually be visible to users and will support proper version information so that our shared users are guaranteed a more positive experience.

If you haven’t downloaded the new Firefox beta yet, and want to give it a spin, you can find a copy here.

Johnathan Nightingale
Human Shield