Why Does Mozilla Maintain Our Own Root Certificate Store?

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

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?

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

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:

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

Preference panel screenshot showing how to enable third-party cookies.

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.

Encrypted SNI Comes to Firefox Nightly

Eric Rescorla

TL;DR: Firefox Nightly now supports encrypting the TLS Server Name Indication (SNI) extension, which helps prevent attackers on your network from learning your browsing history. You can enable encrypted SNI today and it will automatically work with any site that supports it. Currently, that means any site hosted by Cloudflare, but we’re hoping other providers will add ESNI support soon.

Concealing Your Browsing History

Although an increasing fraction of Web traffic is encrypted with HTTPS, that encryption isn’t enough to prevent network attackers from learning which sites you are going to. It’s true that HTTPS conceals the exact page you’re going to, but there are a number of ways in which the site’s identity leaks. This can itself be sensitive information: do you want the person at the coffee shop next to you to know you’re visiting cancer.org?

There are four main ways in which browsing history information leaks to the network: the TLS certificate message,  DNS name resolution, the IP address of the server, and the TLS Server Name Indication extension. Fortunately, we’ve made good progress shutting down the first two of these: The new TLS 1.3 standard encrypts the server certificate by default and over the past several months, we’ve been exploring the use of DNS over HTTPS to protect DNS traffic. This is looking good and we are hoping to roll it out to all Firefox users over the coming months. The IP address remains a problem, but in many cases, multiple sites share the same IP address, so that leaves SNI.

Why do we need SNI anyway and why didn’t this get fixed before?

Ironically, the reason you need an SNI field is because multiple servers share the same IP address. When you connect to the server, it needs to give you the right certificate to prove that you’re connecting to a legitimate server and not an attacker. However, if there is more than one server on the same IP address, then which certificate should it choose? The SNI field tells the server which host name you are trying to connect to, allowing it to choose the right certificate. In other words, SNI helps make large-scale TLS hosting work.

We’ve known that SNI was a privacy problem from the beginning of TLS 1.3. The basic idea is easy: encrypt the SNI field (hence “encrypted SNI” or ESNI). Unfortunately every design we tried had drawbacks. The technical details are kind of complicated, but the basic story isn’t: every design we had for ESNI involved some sort of performance tradeoff and so it looked like only sites which were “sensitive” (i.e., you might want to conceal you went there) would be willing to enable ESNI. As you can imagine, that defeats the point, because if only sensitive sites use ESNI, then just using ESNI is itself a signal that your traffic demands a closer look. So, despite a lot of enthusiasm, we eventually decided to publish TLS 1.3 without ESNI.

However, at the beginning of this year, we realized that there was actually a pretty good 80-20 solution: big Content Distribution Networks (CDNs) host a lot of sites all on the same machines. If they’re willing to convert all their customers to ESNI at once, then suddenly ESNI no longer reveals  a useful signal because the attacker can see what CDN you are going to anyway. This realization broke things open and enabled a design for how to make ESNI work in TLS 1.3 (see Alessandro Ghedini’s writeup of the technical details.) Of course, this only works if you can mass-configure all the sites on a given set of servers, but that’s a pretty common configuration.

How do I get it?

This is brand-new technology and Firefox is the first browser to get it. At the moment we’re not ready to turn it on for all Firefox users. However, Nightly users can try out this enhancing feature now by performing the following steps: First, you need to make sure you have DNS over HTTPS enabled (see: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/). Once you’ve done that, you also need to set the “network.security.esni.enabled” preference in about:config to “true”). This should automatically enable ESNI for any site that supports it. Right now, that’s just Cloudflare, which has enabled ESNI for all its customers, but we’re hoping that other providers will follow them. You can go to: https://www.cloudflare.com/ssl/encrypted-sni/ to check for yourself that it’s working.

What’s Next?

During the development of TLS 1.3 we found a number of problems where network devices (typically firewalls and the like) would break when you tried to use TLS 1.3. We’ve been pretty careful about the design, but it’s possible that we’ll see similar problems with ESNI. In order to test this, we’ll be running a set of experiments over the next few months and measuring for breakage. We’d also love to hear from you: if you enable ESNI and it works or causes any problems, please let us know.

Removing Old Versions of TLS

Martin Thomson

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

On the Internet, 20 years is an eternity.  TLS 1.0 will be 20 years old in January 2019.  In that time, TLS has protected billions – and probably trillions – of connections from eavesdropping and attack.

In that time, we have collectively learned a lot about what it takes to design and build a security protocol.

Though we are not aware of specific problems with TLS 1.0 that require immediate action, several aspects of the design are neither as strong or as robust as we would like given the nature of the Internet today.  Most importantly, TLS 1.0 does not support modern cryptographic algorithms.

The Internet Engineering Task Force (IETF) no longer recommends the use of older TLS versions.  A draft document describes the technical reasons in more detail.

We will disable TLS 1.1 at the same time.  TLS 1.1 only addresses a limitation of TLS 1.0 that can be addressed in other ways. Our telemetry shows that only 0.1% of connections use TLS 1.1.

Graph showing the versions that we intend to remove (TLS 1.0 and 1.1) have low usage

TLS versions for all connections established by Firefox Beta 62, August-September 2018

Our telemetry shows that many sites already use TLS 1.2 or higher (Qualys says 94%).  TLS 1.2 is a prerequisite for HTTP/2, which can improve site performance.  We recommend that sites use a modern profile of TLS 1.2 unless they have specialized needs.

For sites that need to upgrade, the recently released TLS 1.3 includes an improved core design that has been rigorously analyzed by cryptographers.  TLS 1.3 can also make connections faster than TLS 1.2. Firefox already makes far more connections with TLS 1.3 than with TLS 1.0 and 1.1 combined.

Be aware that these changes will appear in pre-release versions of Firefox (Beta, Developer Edition, and Nightly) earlier than March 2020.  We will announce specific dates when we have more detailed plans.

We understand that upgrading something as fundamental as TLS can take some time.  This change affects a large number of sites.  That is why we are making this announcement so far in advance of the March 2020 removal date of TLS 1.0 and TLS 1.1.

Other browsers have made similar announcements. Chrome, Edge, and Safari all plan to make the same change.

Delaying Further Symantec TLS Certificate Distrust

Wayne Thayer

Due to a long list of documented issues, Mozilla previously announced our intent to distrust TLS certificates issued by the Symantec Certification Authority, which is now a part of DigiCert. On August 13th, the next phase of distrust was enabled in Firefox Nightly. In this phase, all TLS certificates issued by Symantec (including their GeoTrust, RapidSSL, and Thawte brands) are no longer trusted by Firefox (with a few small exceptions).

In my previous update, I pointed out that many popular sites are still using these certificates. They are apparently unaware of the planned distrust despite DigiCert’s outreach, or are waiting until the release date that was communicated in the consensus plan to finally replace their Symantec certificates. While the situation has been improving steadily, our latest data shows well over 1% of the top 1-million websites are still using a Symantec certificate that will be distrusted.

Unfortunately, because so many sites have not yet taken action, moving this change from Firefox 63 Nightly into Beta would impact a significant number of our users. It is unfortunate that so many website operators have waited to update their certificates, especially given that DigiCert is providing replacements for free.

We prioritize the safety of our users and recognize the additional risk caused by a delay in the implementation of the distrust plan. However, given the current situation, we believe that delaying the release of this change until later this year when more sites have replaced their Symantec TLS certificates is in the overall best interest of our users. This change will remain enabled in Nightly, and we plan to enable it in Firefox 64 Beta when it ships in mid-October.

We continue to strongly encourage website operators to replace Symantec TLS certificates immediately. Doing so improves the security of their websites and allows the 10’s of thousands of Firefox Nightly users to access them.

Trusting the delivery of Firefox Updates

Julien Vehent

Providing a web browser that you can depend on year after year is one of the core tenet of the Firefox security strategy. We put a lot of time and energy into making sure that the software you run has not been tampered with while being delivered to you.

In an effort to increase trust in Firefox, we regularly partner with external firms to verify the security of our products. Earlier this year, we hired X41 D-SEC Gmbh to audit the mechanism by which Firefox ships updates, known internally as AUS for Application Update Service. Today, we are releasing their report.

Four researchers spent a total of 27 days running a technical security review of both the backend service that manages updates (Balrog) and the client code that updates your browser. The scope of the audit included a cryptographic review of the update signing protocol, fuzzing of the client code, pentesting of the backend and manual code review of all components.

Mozilla Security continuously reviews and tests the security of Firefox, but external verification is a critical part of our operations security strategy. We are glad to say that X41 did not find any critical flaw in AUS, but they did find various issues ranking from low to high, as well as 21 side findings.

X41 D-Sec GmbH found the security level of AUS to be good. No critical vulnerabilities have been identified in any of the components. The most serious vulnerabilities that were discovered are a Cross-Site Request Forgery (CSRF) vulnerability in the administration web application interface that might allow attackers to trigger unintended administrative actions under certain conditions. Other vulnerabilities identified were memory corruption issues, insecure handling of untrusted data, and stability issues (Denial of Service (DoS)). Most of these issues were constrained by requiring to bypass cryptographic signatures.

Three vulnerabilities ranked as high, and all of them were located in the administration console of Balrog, the backend service of Firefox AUS, which is protected behind multiple factors of authentication inside our internal network. The extra layers of security effectively lower the risk of the vulnerabilities found by X41, but we fixed the issues they found regardless.

X41 found a handful of bugs in the C code that handles update files. Thankfully, the cryptographic signatures prevent a bad actor from crafting an update file that could impact Firefox. Here again, designing our systems with multiple layers of security has proven useful.

Today, we are making the full report accessible to everyone in an effort to keep Firefox open and transparent. We are also opening up our bug tracker so you can follow our progress in mitigating the issues and side findings identified in the report.

Finally, we’d like to thank X41 for their high quality work on conducting this security audit. And,  as always, we invite you to help us keep Firefox secure by reporting issues through our bug bounty program.

Supporting Referrer Policy for CSS in Firefox 64

Christoph Kerschbaumer
Thomas Nguyen

The HTTP Referrer Value

Navigating from one webpage to another or requesting a sub-resource within a webpage causes a web browser to send the top-level URL in the HTTP referrer field. Inspecting that HTTP header field on the receiving end allows sites to identify where the request originated which enables sites to log referrer data for operational and statistical purposes. As one can imagine, the top-level URL quite often includes user sensitive information which then might leak through the referrer value impacting an end users privacy.

The Referrer Policy

To compensate, the HTTP Referrer Policy allows webpages to gain more control over referrer values on their site. E.g. using a Referrer Policy of “origin” instructs the web browser to strip any path information and only fill the HTTP referrer value field with the origin of the requesting webpage instead of the entire URL. More aggressively, a Referrer Policy of ‘no-referrer’ advises the browser to suppress the referrer value entirely. Ultimately the Referrer Policy empowers the website author to gain more control over the used referrer value and hence provides a tool for website authors to respect an end users privacy.

Expanding the Referrer Policy to CSS

While Firefox has been supporting Referrer Policy since Firefox 50 we are happy to announce that Firefox will expand policy coverage and will support Referrer Policy within style sheets starting in Firefox 64. With that update in coverage, requests originating from within style sheets will also respect a site’s Referrer Policy and ultimately contribute a cornerstone to a more privacy respecting internet.

For the Mozilla Security and Privacy Team,
  Christoph Kerschbaumer & Thomas Nguyen

September 2018 CA Communication

Wayne Thayer

Mozilla has sent a CA Communication to inform Certification Authorities (CAs) who have root certificates included in Mozilla’s program about current events relevant to their membership in our program and to remind them of upcoming deadlines. This CA Communication has been emailed to the Primary Point of Contact (POC) and an email alias for each CA in Mozilla’s program, and they have been asked to respond to the following 7 action items:

  1. Mozilla recently published version 2.6.1 of our Root Store Policy. The first action confirms that CAs have read the new version of the policy.
  2. The second action asks CAs to ensure that their CP/CPS complies with the changes that were made to domain validation requirements in version 2.6.1 of Mozilla’s Root Store Policy.
  3. CAs must confirm that they will comply with the new requirement for intermediate certificates issued after 1-January 2019 to be constrained to prevent use of the same intermediate certificate to issue both SSL and S/MIME certificates.
  4. CAs are reminded in action 4 that Mozilla is now rejecting audit reports that do not comply with section 3.1.4 of Mozilla’s Root Store Policy.
  5. CAs must confirm that they have complied with the 1-August 2018 deadline to discontinue use of BR domain validation methods 1 “Validating the Applicant as a Domain Contact” and 5 “Domain Authorization Document”
  6. CAs are reminded of their obligation to add new intermediate CA certificates to CCADB within one week of certificate creation, and before any such subordinate CA is allowed to issue certificates. Later this year, Mozilla plans to begin preloading the certificate database shipped with Firefox with intermediate certificates disclosed in the CCADB, as an alternative to “AIA chasing”. This is intended to reduce the incidence of “unknown issuer” errors caused by server operators neglecting to include intermediate certificates in their configurations.
  7. In action 7 we are gathering information about the Certificate Transparency (CT) logging practices of CAs. Later this year, Mozilla is planning to use CT logging data to begin testing a new certificate validation mechanism called CRLite which may reduce bandwidth requirements for CAs and increase performance of websites. Note that CRLite does not replace OneCRL which is a revocation list controlled by Mozilla.

The full action items can be read here. Responses to the survey will be automatically and immediately published by the CCADB.

With this CA Communication, we reiterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve.