Mozilla Security Blog

Updated GPG key for signing Firefox Releases

Jun 13 2019

The GPG key used to sign the Firefox release manifests is expiring soon, and so we’re going to be switching over to new key shortly.

The new GPG subkey’s fingerprint is 097B 3130 77AE 62A0 2F84 DA4D F1A6 668F BB7D 572E, and it expires 2021-05-29.

The public key can be fetched from KEY files from Firefox 68 beta releases, or from below. This can be used to validate existing releases signed with the current key, or future releases signed with the new key.

Next steps in privacy-preserving Telemetry with Prio

Jun 6 2019

Steven Englehardt

In late 2018 Mozilla conducted an experiment to collect browser Telemetry data with Prio, a privacy-preserving data collection system developed by Stanford Professor Dan Boneh and PhD candidate Henry Corrigan-Gibbs. That experiment was a success: it allowed us to validate that our Prio data collections were correct, efficient, and integrated well with our analysis pipeline. Today, we want to let you know about our next steps in testing data collection with Prio.

As part of Content Blocking, Firefox will soon include default protections against tracking. Our protections are built on top of a blocklist of known trackers. We expect trackers to react to our protections, and in some cases attempt to work around them. We can monitor how our blocklists are applied in Firefox to detect these workarounds.

However, directly monitoring how our blocklists are applied would require data that we feel is too sensitive to collect from release versions of Firefox. That’s why Prio is so important: it allows us to understand how our blocklists are applied across a large number of users, without giving us the ability to determine how they are applied in any individual user’s browser or on any individual page visit.

To support this we’ve developed Firefox Origin Telemetry, which is built on top of Prio. We will use Firefox Origin Telemetry to collect counts of the number of sites on which each blocklist rule was active, as well as counts of the number of sites on which the rules were inactive due to one of our compatibility exemptions. By monitoring these statistics over time, we can determine how trackers react to our new protections and discover abuse.

In the next phase of testing we need validate that Firefox Origin Telemetry works at scale. To provide effective privacy, Prio requires that two independent parties each process a separate portion of the data — a requirement that we will not satisfy during this test. As in our initial test, we will run both data collection servers ourselves to complete end-to-end testing prior to involving a second party. That’s why we are running this test only in our pre-release channels, which we know are used by a smaller audience that has chosen to help us test development versions of Firefox. We’ve ensured that the data we’re collecting falls within our data collection policies for pre-release versions of Firefox, and we’ve chosen to limit the collection to 1% of Firefox Nightly users, as this is all that’s necessary to validate the API.

We expect to start this test during our Nightly 69 development cycle. Collecting this data in a production environment will require an independent third party to run one of the servers. We will provide further updates once we have such a partner in place.

Mozilla’s Common CA Database (CCADB) promotes Transparency and Collaboration

Apr 15 2019

Kathleen Wilson

The Common CA Database (CCADB) is helping us protect individuals’ security and privacy on the internet and deliver on our commitment to use transparent community-based processes to promote participation, accountability and trust. It is a repository of information about Certificate Authorities (CAs) and their root and subordinate certificates that are used in the web PKI, the publicly-trusted system which underpins secure connections on the web. The Common CA Database (CCADB) paves the way for more efficient and cost-effective management of root stores and helps make the internet safer for everyone. For example, the CCADB automatically detects and alerts root store operators when a root CA has outdated audit statements or a gap between audit periods. This is important, because audit statements provide assurance that a CA is following required procedures so that they do not issue fraudulent certificates.

Through the CCADB we are extending the checks and balances on root CAs to subordinate CAs to provide similar assurance that the subordinate CAs are not issuing fraudulent certificates. Root CAs, who are directly included in Mozilla’s program, can have subordinate CAs who also issue SSL/TLS certificates that are trusted by Firefox. There are currently about 150 root certificates in Mozilla’s root store, which leads to over 3,100 subordinate CA certificates that are trusted by Firefox. In our efforts to ensure that all subordinate CAs follow the rules, we require that they be disclosed in the CCADB along with their audit statements.

Additionally, the CCADB is making it possible for Mozilla to implement Intermediate CA Preloading in Firefox, with the goal of improving performance and privacy. Intermediate CA Preloading is a new way to hande websites that are not properly configured to serve up the intermediate certificate along with its SSL/TLS certificate. When other browsers encounter such websites they use a mechanism to connect to the CA and download the certificate just-in-time. Preloading the intermediate certificate data (aka subordinate CA data) from the CCADB avoids the just-in-time network fetch, which delays the connection. Avoiding the network fetch improves privacy, because it prevents disclosing user browsing patterns to the CA that issued the certificate for the misconfigured website.

Mozilla created and runs the CCADB, which is also used and contributed to by Microsoft, Google, Cisco, and Apple. Even though the common CA data is shared, each root store operator has a customized experience in the CCADB, allowing each root store operator to see the data sets that are important for managing root certificates included in their program.

The CCADB:

Makes root stores more transparent through public-facing reports, encouraging community involvement to help ensure that CAs and subordinate CAs are correctly issuing certificates.
- For example the crt.sh website combines information from the CCADB and Certificate Transparency (CT) logs to identify problematic certificates.
Adds automation to improve the level and accuracy of management and rule enforcement. For example the CCADB automates:
- Notification to CAs when audit statements are due at both the root and subordinate CA level
- Audit Letter Validation (ALV) via a tool provided by Microsoft
- Sending of communications to CAs and publishing their responses
Enables CAs to provide their annual updates in one centralized system, rather than communicating those updates to each root store separately; and in the future will enable CAs to apply to multiple root stores with a single application process.

Maintaining a root store containing only credible CAs is vital to the security of our products and the web in general. The major root store operators are using the CCADB to promote efficiency in maintaining root stores, to improve internet security by raising the quality and transparency of CA and subordinate CA data, and to make the internet safer by enforcing regular and contiguous audits that provide assurances that root and subordinate CAs do not issue fraudulent certificates. As such, the CCADB is enabling us to help ensure individuals’ security and privacy on the internet and deliver on our commitment to use transparent community-based processes to promote participation, accountability and trust.

DNS-over-HTTPS Policy Requirements for Resolvers

Apr 9 2019

Marshall Erwin

Over the past few months, we’ve been experimenting with DNS-over-HTTPS (DoH), a protocol which uses encryption to protect DNS requests and responses, with the goal of deploying DoH by default for our users. Our plan is to select a set of Trusted Recursive Resolvers (TRRs) that we will use for DoH resolution in Firefox. Those resolvers will be required to conform to a specific set of policies that put privacy first.

To that end, today we are releasing a list of DOH requirements, available on the Mozilla wiki, that we will use to vet potential resolvers for Firefox. The requirements focus on three areas: 1) limiting data collection and retention from the resolver, 2) ensuring transparency for any data retention that does occur, and 3) limiting any potential use of the resolver to block access or modify content. This is intended to cover resolvers that Firefox will offer by default and resolvers that Firefox might discover in the local network.

In publishing this policy, our goal is to encourage adherence to practices for DNS that respect modern standards for privacy and security. Not just for our potential DoH partners, but for all DNS resolvers.

Backward-Compatibility FIDO U2F support shipping soon in Firefox

Apr 4 2019

J.C. Jones

Web Authentication (WebAuthn), a recent web standard blending public-key cryptography into website logins, is our best technical response to credential phishing. That’s why we’ve championed it as a technology. The FIDO U2F API is the spiritual ancestor of WebAuthn; to-date, it’s still much more commonly used. Firefox has had experimental support for the Javascript FIDO U2F API since version 57, as it was used to validate our Web Authentication implementation that then shipped in Firefox 60. Both technologies can help secure the logins of millions of users already in possession of FIDO U2F USB tokens.

We encourage the adoption of Web Authentication rather than the FIDO U2F API. However, some large web properties are encountering difficulty migrating: WebAuthn works with security credentials produced by the FIDO U2F API. However, WebAuthn-produced credentials cannot be used with the FIDO U2F API. For the entities affected, this could lead to poor user experiences and inhibit overall adoption of this critical technology.

To smooth out this migration, after discussion on the mozilla.dev.platform mailing list, we have decided to enable our support for the FIDO U2F API by default for all Firefox users. It’s enabled now in Firefox Nightly 68, and we plan for it to be uplifted into Firefox Beta 67 in the coming week.

Enabling FIDO U2F API in Firefox

A FIDO U2F API demo website being activated

Firefox’s implementation of the FIDO U2F API accommodates only the common cases of the specification; for details, see the mailing list discussion. For those who are interested in using FIDO U2F API before they update to version 68, Firefox power users have successfully utilized the FIDO U2F API by enabling the “security.webauth.u2f” preference in about:config since Quantum shipped in 2017.

Currently, the places where Firefox’s implementation is incomplete are expected to remain so. With the increase of using biometric mechanisms such as face recognition or fingerprints in devices, we are focusing our support on WebAuthn. It provides a sophisticated level of authentication and cryptography that will protect Firefox users.

The future of anti-phishing is Web Authentication

It’s important that the Web move to Web Authentication rather than building new capabilities with the deprecated, legacy FIDO U2F API. Now a published Recommendation at the W3C, Web Authentication has support for many more use cases than the legacy technology, and a much more robustly-examined browser security story.

Ultimately, it’s most important that Firefox users be able to protect their accounts with the strongest protections possible. We believe the strongest to be Web Authentication, as it has improved usability via platform authenticators, capabilities for “passwordless” logins, and more advanced security keys and tokens.

Passwordless Web Authentication Support via Windows Hello

Mar 19 2019

J.C. Jones

Firefox 66, being released this week, supports using the Windows Hello feature for Web Authentication on Windows 10, enabling a passwordless experience on the web that is hassle-free and more secure. Firefox has supported Web Authentication for all desktop platforms since version 60, but Windows 10 marks our first platform to support the new FIDO2 “passwordless” capabilities for Web Authentication.

A Windows 10 dialog box prompting for a Web Authentication credential

PIN Prompt on Windows 10 2019 April release

As of today, Firefox users on the Windows Insider Program’s fast ring can use any authentication mechanism supported by Windows for websites via Firefox. That includes face or fingerprint biometrics, and a wide range of external security keys via the CTAP2 protocol from FIDO2, as well as existing deployed CTAP1 FIDO U2F-style security keys. Try it out and give us feedback on your experience.

For the rest of Firefox users on Windows 10, the upcoming update this spring will enable this automatically.

Akshay Kumar from Microsoft’s Windows Security Team contributed this support to Firefox. We thank him for making this feature happen, and the Windows team for ensuring that all the Web Authentication features of Windows Hello were available to Firefox users.

For Firefox users running older versions of Windows, Web Authentication will continue to use our Rust-implemented CTAP1 protocol support for U2F-style USB security keys. We will continue work toward providing CTAP2/FIDO2 support on all of our other platforms, including older versions of Windows.

For Firefox ESR users, this Windows Hello support is currently planned for ESR 60.0.7, being released mid-May.

If you haven’t used Web Authentication yet, adoption by major websites is underway. You can try it out at a variety of demo sites: https://webauthn.org/, https://webauthn.io/, https://webauthn.me/, https://webauthndemo.appspot.com/, or learn more about it on MDN.

If you want to try the Windows Hello support in Firefox 66 on Windows 10 before the April 2019 update is released, you can do so via the Windows Insider program. You’ll need to use the “fast” ring of updates.

Why Does Mozilla Maintain Our Own Root Certificate Store?

Feb 14 2019

Wayne Thayer

Mozilla maintains a database containing a set of “root” certificates that we use as “trust anchors”. This database, commonly referred to as a “root store”, allows us to determine which Certificate Authorities (CAs) can issue SSL/TLS certificates that are trusted by Firefox, and email certificates that are trusted by Thunderbird. Properly maintaining a root store is a significant undertaking – it requires constant effort to evaluate new trust anchors, monitor existing ones, and react to incidents that threaten our users. Despite the effort involved, Mozilla is committed to maintaining our own root store because doing so is vital to the security of our products and the web in general. It gives us the ability to set policies, determine which CAs meet them, and to take action when a CA fails to do so.

A major advantage to controlling our own root store is that we can do so in a way that reflects our values. We manage our CA Certificate Program in the open, and by encouraging public participation we give individuals a voice in these trust decisions. Our root inclusion process is one example. We process lots of data and perform significant due diligence, then publish our findings and hold a public discussion before accepting each new root. Managing our own root store also allows us to have a public incident reporting process that emphasizes disclosure and learning from experts in the field. Our mailing list includes participants from many CAs, CA auditors, and other root store operators and is the most widely recognized forum for open, public discussion of policy issues.

The value delivered by our root program extends far beyond Mozilla. Everyone who relies on publicly-trusted certificates benefits from our work, regardless of their choice of browser. And because our root store, which is part of the NSS cryptographic library, is open source, it has become a de-facto standard for many Linux distributions and other products that need a root store but don’t have the resources to curate their own. Providing one root store that many different products can rely on, regardless of platform, reduces compatibility problems that would result from each product having a unique set of root certificates.

Finally, operating a root store allows Mozilla to lead and influence the entire web Public Key Infrastructure (PKI) ecosystem. We created the Common Certificate Authority Database (CCADB) to help us manage our own program, and have since opened it up to other root store operators, resulting in better information and less redundant work for all involved. With full membership in the CA/Browser Forum, we collaborate with other root store operators, CAs, and auditors to create standards that continue to increase the trustworthiness of CAs and the SSL/TLS certificates they issue. Our most recent effort was aimed at improving the standards for validating IP Addresses.

The primary alternative to running our own root store is to rely on the one that is built in to most operating systems (OSs). However, relying on our own root store allows us to provide a consistent experience across OS platforms because we can guarantee that the exact same set of trust anchors is available to Firefox. In addition, OS vendors often serve customers in government and industry in addition to their end users, putting them in a position to sometimes make root store decisions that Mozilla would not consider to be in the best interest of individuals.

Sometimes we experience problems that wouldn’t have occurred if Firefox relied on the OS root store. Companies often want to add their own private trust anchors to systems that they control, and it is easier for them if they can modify the OS root store and assume that all applications will rely on it. The same is true for products that intercept traffic on a computer. For example, many antivirus programs unfortunately include a web filtering feature that intercepts HTTPS requests by adding a special trust anchor to the OS root store. This will trigger security errors in Firefox unless the vendor supports Firefox by turning on the setting we provide to address these situations.

Principle 4 of the Mozilla Manifesto states that “Individuals’ security and privacy on the internet are fundamental and must not be treated as optional.” The costs of maintaining a CA Certificate Program and root store are significant, but there are fundamental benefits for our users and the larger internet community that undoubtedly make doing it ourselves the right choice for Mozilla.

Defining the tracking practices that will be blocked in Firefox

Jan 28 2019

Steven Englehardt

Marshall Erwin

For years, web users have endured major privacy violations. Their browsing continues to be routinely and silently tracked across the web. Tracking techniques have advanced to the point where users cannot meaningfully control how their personal data is used.

At Mozilla, we believe that privacy is fundamental, and that pervasive online tracking is unacceptable. Simply put: users need more protection from tracking. In late 2018, Mozilla announced that we are changing our approach to anti-tracking, with a focus on providing tracking protection by default, for the benefit of everyone using Firefox.

In support of this effort, today we are releasing an anti-tracking policy that outlines the tracking practices that Firefox will block by default. At a high level, this new policy will curtail tracking techniques that are used to build profiles of users’ browsing activity. In the policy, we outline the types of tracking practices that users cannot meaningfully control. Firefox may apply technical restrictions to the parties found using each of these techniques.

With the release of our new policy, we’ve defined the set of tracking practices that we think users need to be protected against. As a first step in enforcing this policy, Firefox includes a feature that prevents domains classified as trackers from using cookies and other browser storage features (e.g., DOM storage) when loaded as third parties. While this feature is currently off by default, we are working towards turning it on for all of our users in a future release of Firefox.

Furthermore, the policy also covers query string tracking, browser fingerprinting, and supercookies. We intend to apply protections that block these tracking practices in Firefox in the future.

Parties not wishing to be blocked by this policy should stop tracking Firefox users across websites. To classify trackers, we rely on Disconnect’s Tracking Protection list, which is curated in alignment with this policy. If a party changes their tracking practices and updates their public documentation to reflect these changes, they should work with Disconnect to update the classification of their domains.

This initial release of the anti-tracking policy is not meant to be the final version. Instead, the policy is a living document that we will update in response to the discovery and use of new tracking techniques. We believe that all web browsers have a fundamental obligation to protect users from tracking and we hope the launch of our policy advances the conversation about what privacy protections should be the default for all web users.

Clarification (2019-01-28): Added a sentence to clarify the current status of the cookie blocking feature.

When does Firefox alert for breached sites?

Nov 14 2018

Luke Crouch

Mozilla’s Position on Data Breaches

Data breaches are common for online services. Humans make mistakes, and humans make the Internet. Some online services discover, mitigate, and disclose breaches quickly. Others go undetected for years. Recent breaches include “fresh” data, which means victims have less time to change their credentials before they are in the hands of attackers. While old breaches have had more time to make their way into scripted credential stuffing attacks. All breaches are dangerous to users.

As stated in the Mozilla Manifesto: “Individuals’ security and privacy on the internet are fundamental and must not be treated as optional.” Most people simply don’t know that a data breach has affected them. Which makes it difficult to take the first step to secure their online accounts because they don’t know they’re insecure in the first place. This is why we launched Firefox Monitor.

Informing Firefox Users

Today we are continuing to improve our Firefox Monitor service. To help users who might have otherwise missed breach news or email alerts, we are integrating alerts into Firefox that will notify users when they visit a site that has been breached in the past. This feature integrates notifications into the user’s browsing experience.

To power this feature, we use a list of breached sites provided by our partner, Have I Been Pwned (HIBP). Neither HIBP nor Mozilla can confirm that a user has changed their password after a breach, or whether they have reused a breached password elsewhere. So we do not know whether an individual user is still at risk, and cannot trigger user-specific alerts.

For our initial launch we’ve developed a simple, straightforward methodology:

If the user has never seen a breach alert before, Firefox shows an alert when they visit any breached site added to HIBP within the last 12 months.
After the user has seen their first alert, Firefox only shows an alert when they visit a breached site added to HIBP within the last 2 months.

We believe this 12-month and 2-month policy are reasonable timeframes to alert users to both the password-reuse and unchanged-password risks. A longer alert timeframe would help us ensure we make even more users aware of the password-reuse risk. However, we don’t want to alarm users or to create noise by triggering alerts for sites that have long since taken significant steps to protect their users. That noise could decrease the value and usability of an important security feature.

Towards a more Sophisticated Approach

This is an interim approach to bring attention, awareness, and information to our users now, and to start getting their feedback. When we launched our Monitor service, we received tremendous feedback from our early users that we’re using to improve our efforts to directly address users’ top concerns for their online service accounts. For service operators, our partner, Troy Hunt, already has some great articles on how to prevent data breaches from happening, and how to quickly and effectively disclose and recover from them. Over the longer term, we want to work with our users, partners, and all service operators to develop a more sophisticated alert policy. We will base such a policy on stronger signals of individual user risk, and website mitigations.

Firefox 63 Lets Users Block Tracking Cookies

Oct 23 2018

Steven Englehardt

As announced in August, Firefox is changing its approach to addressing tracking on the web. As part of that plan, we signaled our intent to prevent cross-site tracking for all Firefox users and made our initial prototype available for testing.

Starting with Firefox 63, all desktop versions of Firefox include an experimental cookie policy that blocks cookies and other site data from third-party tracking resources. This new policy provides protection against cross-site tracking while minimizing site breakage associated with traditional cookie blocking.

This policy is part of Enhanced Tracking Protection, a new feature aimed at protecting users from cross-site tracking. More specifically, it prevents trackers from following users around from site to site and collecting information about their browsing habits.

We aim to bring these protections to all users by default in Firefox 65. Until then, you can opt-in to the policy by following the steps detailed at the end of this post.

What does this policy block?

The newly developed policy blocks storage access for domains that have been classified as trackers. For classification, Firefox relies on the Tracking Protection list maintained by Disconnect. Domains classified as trackers are not able to access or set cookies, local storage, and other site data when loaded in a third-party context. Additionally, trackers are blocked from accessing other APIs that allow them to communicate cross-site, such as the Broadcast Channel API. These measures prevent trackers from being able to use cross-site identifiers stored in Firefox to link browsing activity across different sites.

Our documentation on MDN provides significantly more technical detail on the policy, including: how domains are matched against the Tracking Protection list, how Firefox blocks storage access for tracking domains, and the types of third-party storage access that are currently blocked.

Does this policy break websites?

Third-party cookie blocking does have the potential to break websites, particularly those which integrate third-party content. For this reason, we’ve added heuristics to Firefox to automatically grant time-limited storage access under certain conditions. We are also working to support a more structured way for embedded cross-origin content to request storage access. In both cases, Firefox grants access on a site-by-site basis, and only provides access to embedded content that receives user interaction.

More structured access will be available through the Storage Access API, of which an initial implementation is available in Firefox Nightly (and soon Beta and Developer Edition) for testing. This API allows domains classified as trackers to explicitly request storage access when loaded in a third-party context. The Storage Access API is also implemented in Safari and is a proposed addition to the HTML specification. We welcome developer feedback, particularly around use cases that can not be addressed with this API.

How can I test my website?

We welcome testing by both users and site owners as we continue to develop new storage access restrictions. Take the following steps to enable this storage access policy in Firefox:

Open Preferences
On the left-hand menu, click on Privacy & Security
Under Content Blocking, click the checkbox next to “Third-Party Cookies”
Select “Trackers (recommended)”

If you find a broken site, you can tell us about it directly in Firefox with the “Report a Problem” button in the Control Center. If you encounter problems in the implementation of this policy, please let us know on Bugzilla. Site owners may also be interested in our debugging tools.

Does this mean Firefox will no longer support the Tracking Protection feature?

Tracking Protection is still available to users who want to opt-in to block all tracking loads; with our updated UI, this feature can be enabled by setting “All Detected Trackers” to “Always”. All tracking loads will continue to be blocked by default in Private Browsing windows.

Expect to hear more from us in the coming months as we continue to strengthen Firefox’s default-on tracking protection.