CSP for the web we have


Content Security Policy (CSP) is a good safety net against Cross Site Scripting (XSS). In fact, it’s the best one and I would recommend it to anyone building new sites.

For existing sites, implementing CSP can be a challenge because CSP introduces some restrictions by default and, if the code was written without these restrictions in mind, work will be required. Also, working around these issues can negate the benefits of applying a policy in the first place. In particular, inline scripts require thought; they’re commonly used and, if they’re allowed by your policy, the major benefit of CSP no longer applies. The only option available to make effective use of CSP, in the past, was to re-write the code to remove any existing inline scripts or styles.

Applying CSP to existing site might seem overwhelming at first but, considering the security benefit, the effort is well worth it. Fortunately, doing this has become much easier with CSP 2.

Some CSP 2 features:
CSP 2 provides some features that can really help; hash-source and nonce-source. These both provide a way of using inline scripts and styles without giving attackers free reign to inject things.

So how do they work? We’ll look at nonce-source first.

A CSP with a nonce-source might look like this:

content-security-policy: default-src 'self'; script-src 'nonce-2726c7f26c'

And the corresponding document might contain a script element that looks like this:

<script nonce="2726c7f26c">

There are 2 things to note here; firstly, it’s important that the nonce changes for each response (I’ve seen an example where it doesn’t!) and, secondly, it’s important that the nonce is sufficiently hard to predict.

Now, because the nonce changes in a way that isn’t predictable, the attacker doesn’t know what to inject and so, by only allowing script (or style) elements with valid nonce attributes, we can be sure that injections will fail.

And what about hash-source? Well, this is similar in that, again, a source in the CSP is used to ensure that a script or style element in the body is supposed to be there but the mechanism used differs. Rather than relying on an attribute on the script element in the document, hash-source provides a hash, in the CSP, of the script elements that are to be allowed in the document.

So for a script element like this:


You’d have a CSP containing a hash-source a bit like this:

content-security-policy: script-src 'sha256-cLuU6nVzrYJlo7rUa6TMmz3nylPFrPQrEUpOHllb5ic='

Obviously, you’d need to add a hash-source for each script or style you wanted to include in your document.

Which to use (and when):
So you may be wondering why there are two mechanisms (when both are designed to allow inline scripts and styles) and when you should use one rather than the other.
You should resist the temptation to use these mechanisms everywhere; these techniques are only intended for cases where removing inline scripts is not an option.

Nonce-source will be most useful in most cases because it is simpler. You only need to include a single source in your policy to cover a number of inline elements. The downside is that, since a nonce must only be used once, you need to generate a new header (and a new document) for each page load. This makes nonce-source a good option for dynamically generated pages, but completely unsuitable for static content.

Hash-source is more complicated; you have to generate hashes for each and every element you want to allow…. but, because it doesn’t rely on a value being unknown to an attacker, the CSP and the script element can remain the same. This makes hash-source a useful mechanism for protecting content that is served statically.

Words of warning:
Please be careful when using either of these mechanisms in dynamically generated content; if an attacker can inject content into something you’ve set a nonce attribute on (or something you generate a hash-source from) then you may have created a free bypass for an attacker.

The inline script restrictions imposed by CSP include script valued attributes (commonly used for DOM Level 0 event handlers, e.g. onclick); hash-source and nonce-source cannot help you with these.  Currently CSP does not provide mechanisms to apply directives to such script valued attributes but let’s see what the future brings!

RSA Signature Forgery in NSS

Daniel Veditz



A flaw in the Network Security Services (NSS) library used by Firefox and other products allows attackers to create forged RSA certificates. Mozilla has released updates to fix this vulnerability and you should apply these updates to ensure your safety on the internet.

Impact to Users

Users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for 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.


The following updates have been released for Mozilla client products:

Firefox 32.0.3
Firefox for Android 32.0.3
Firefox for Android 31.1.1
Firefox ESR 31.1.1
Firefox ESR 24.8.1

Thunderbird 31.1.2
Thunderbird 24.8.1

SeaMonkey 2.29.1

Updates are also available for Beta and other development versions of these products.

Most users will receive these as automatic updates. In addition, they are available from our website for those who have disabled automatic updates (or from the Play store in the case of Firefox for Android).

Other products which incorporate the NSS library should upgrade their copy of NSS to one of the following:

NSS 3.16.5
NSS 3.17.1


We would like to thank the following researchers for reporting this issue:

Antoine Delignat-Lavaud of Inria Paris in team Prosecco
The Advanced Threat Research team at Intel Security

Additional information can be found in our advisory.

Phasing Out Certificates with SHA-1 based Signature Algorithms



Many of the certificates used by secure websites today are signed using algorithms based on a hash algorithm called SHA-1. The integrity of the hash algorithm used in signing a certificate is a critical element in the security of the certificate. Weaknesses in hash algorithms can lead to situations in which attackers can obtain fraudulent certificates. Mozilla, along with other browser vendors, is working on a plan to phase out support for the SHA-1 hash algorithm.

SHA-1 is nearly twenty years old, and is beginning to show its age. In the last few years, collision attacks undermining some properties of SHA-1 have been getting close to being practical. Collision attacks against the older MD5 hash algorithm have been used to obtain fraudulent certificates, so the improving feasibility of collision attacks against SHA-1 is concerning. In order to avoid the need for a rapid transition should a critical attack against SHA-1 be discovered, we are proactively phasing out SHA-1.

We encourage Certification Authorities (CAs) and Web site administrators to upgrade their certificates to use signature algorithms with hash functions that are stronger than SHA-1, such as SHA-256, SHA-384, or SHA-512. Mozilla’s CA Certificate Maintenance Policy section 8 says: “We consider the following algorithms and key sizes to be acceptable and supported in Mozilla products: SHA-1 (until a practical collision attack against SHA-1 certificates is imminent) …” NIST Guidance recommended that SHA-1 certificates should not be trusted beyond 2014. However, there are still many Web sites that are using SSL certificates with SHA-1 based signatures, so we agree with the positions of Microsoft and Google that SHA-1 certificates should not be issued after January 1, 2016, or trusted after January 1, 2017. In particular, CAs should not be issuing new SHA-1 certificates for SSL and Code Signing, and should be migrating their customers off of SHA-1 intermediate and end-entity certificates. If a CA still needs to issue SHA-1 certificates for compatibility reasons, then those SHA-1 certificates should expire before January 2017. More information is available in Mozilla’s list of Potentially Problematic CA Practices.

We plan to add a security warning to the Web Console to remind developers that they should not be using a SHA-1 based certificate. We will display an additional, more prominent warning if the certificate will be valid after January 1, 2017, since we will reject that certificate after that date. We plan to implement these warnings in the next few weeks, so they should be appearing in released versions of Firefox in early 2015. We may implement additional UI indicators later. For instance, after January 1, 2016, we plan to show the “Untrusted Connection” error whenever a newly issued SHA-1 certificate is encountered in Firefox. After January 1, 2017, we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox.

Please check your SSL and Code Signing certificates and replace any which use the SHA-1 hash algorithm, and contact mozilla.dev.security.policy if you have comments or concerns.

Mozilla Security Engineering Team

A Faster Content Security Policy (CSP)


With the establishment of CSP Level 2, Mozilla shifted gears and reimplemented CSP in C++. This security feature first shipped in Firefox 4 (2011), and until now was implemented in a combination of JavaScript and C++. The new implementation is based solely on C++ and without the need to connect two languages, which increases performance and simplifies the implementation. This allows us faster turnaround when deploying new features established by future layers of the CSP standard.

We’re thrilled to report that CSP in Firefox now works faster than ever.

Performance measurements:
We measured performance with a standard consumer laptop: we ran all csp mochitests in our testsuite (content/base/test/csp/) on a 2.5 GHz Intel Core i5 MacBook Pro with 8 GB RAM running Mac OS X 10.9.4 and an optimized build of Firefox (like the releases). In addition, we run the testsuite using nice -n -20 to minimize operating system scheduler effects. We performed 10 repetitions for each test to get stable results and report the geometric mean of these repetitions to remove outliers.

The three operations we tested were “APPENDPOLICY” (how long it takes to set a CSP for a site), “SHOULDLOAD” (how long it takes to check each requested resource for CSP compliance) and “ALLOWS” (how long it takes to check each inline script or stylesheet computation for CSP compliance).

Operation OLD CSP time (ms) NEW CSP time (ms) Improvement factor
APPENDPOLICY 1.0942 0.0704 15.54x
SHOULDLOAD 0.5081 0.0220 23.09x
ALLOWS 0.0767 0.0178 4.30x

Consider a hypothetical site with an active CSP, ten resource loads (images, script files, etc), and three inline scripts. That’s one APPENDPOLICY, ten SHOULDLOADs, and three ALLOW calls. The old implementation of CSP would spend 1.0942ms in APPENDPOLICY, 5.081ms in SHOULDLOAD and 0.2301ms in ALLOWS, or 6.4053ms time in CSP. The same page with our new implementation would spend about 0.3438ms in CSP, which is about a 95% speedup.

Because most sites load many resources, SHOULDLOAD performance is critical. While each site may trigger APPENDPOLICY once, the SHOULDLOAD code path is triggered for all images and external file loads that the site performs and is especially critical on sites with CSS image widgets, backgrounds, custom bullets, and more complicated graphics. Our tests show that the biggest improvement happens with SHOULDLOAD, suggesting this reimplementation targeted the most critical part of page execution performance.

What’s next:
We have seen CSP gradually adopted as a useful security tool on Web pages and we will continue working in the W3C to simplify usage and make CSP more powerful. We believe CSP has the potential to provide an even greater security benefit once adopted by more of the Web.

Christoph Kerschbaumer & Sid Stamm
Mozilla Security Engineering

Phasing out Certificates with 1024-bit RSA Keys



For many years, Mozilla, NIST, the CA/Browser Forum, and others have been encouraging Certification Authorities (CAs) to upgrade their 1024-bit RSA keys to a stronger cryptographic algorithm (either longer RSA keys or ECDSA). We are actively working with CAs to retire SSL and Code Signing certificates that have 1024-bit RSA keys in an effort to make the upgrade as orderly as possible, and to avoid having system administrators find themselves in emergency mode because their SSL keys were compromised. Our multi-pronged approach includes removing the SSL and Code Signing trust bits from 1024-bit root certificates in NSS, gathering telemetry about end-entity certificates with 1024-bit RSA keys, and then eventually showing an “Untrusted Connection” error when a certificate in the chain has an RSA key that is less than 2048 bits.

To help with migration off of 1024-bit root certificates, we are making changes in phases. The first phase involved removing or turning off trust bits for the following 1024-bit root certificates in Firefox 32.

In Firefox 32, the following 1024-bit CA certificates were either removed, or their SSL and Code Signing trust bits were turned off:

  • Entrust
    • CN = Entrust.net Secure Server Certification Authority
    • SHA1 Fingerprint: 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39
    • OU = ValiCert Class 1 Policy Validation Authority
    • SHA1 Fingerprint: E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E
  • GoDaddy
    • OU = ValiCert Class 2 Policy Validation Authority
    • SHA1 Fingerprint: 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6
  • EMC / RSA
    • OU = ValiCert Class 3 Policy Validation Authority
    • SHA1 Fingerprint: 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB
  • Symantec / VeriSign
    • OU = Class 3 Public Primary Certification Authority
    • SHA1 Fingerprint: A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
    • OU = Class 3 Public Primary Certification Authority
    • SHA1 Fingerprint: 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
  • NetLock
    • CN = NetLock Uzleti (Class B) Tanusitvanykiado
    • SHA1 Fingerprint: 87:9F:4B:EE:05:DF:98:58:3B:E3:60:D6:33:E7:0D:3F:FE:98:71:AF
    • CN = NetLock Expressz (Class C) Tanusitvanykiado
    • SHA1 Fingerprint: E3:92:51:2F:0A:CF:F5:05:DF:F6:DE:06:7F:75:37:E1:65:EA:57:4B

If you run an SSL-enabled website, this change will not impact you if your certificates and the CAs above it have 2048-bit keys or more. If your SSL certificate has a 1024-bit key, or was issued by a CA with a 1024-bit key, then you will need to get a new SSL certificate, and update the certificates in your Web server. If the intermediate certificate that you are using has a 1024-bit key, then you will need to download the 2048-bit intermediate certificate from the CA, and update the certificate chain in your Web server. For your convenience, links to the impacted CAs are provided in the list above.

The second phase of migrating off of 1024-bit root certificates involves the changes identified in Bugzilla Bug #986014 and Bug #1047011. The root certificates under consideration for the second phase are Thawte, VeriSign, Equifax, and GTE CyberTrust 1024-bit root certificates. These root certificates are operated by Symantec and Verizon Certificate Services, and we are planning these changes to be released in Firefox in early 2015. As always, these root certificate changes will be discussed in the mozilla.dev.security.policy forum.

The third and final phase of migrating off of 1024-bit root certificates involves the changes identified in Bugzilla Bug #986019, which relates to Equifax root certificates that are owned by Symantec. The plan for the third phase of 1024-bit root changes will be discussed in the mozilla.dev.security.policy forum. We are targeting to complete the migration off of 1024-bit root certificates in the first half of 2015, after which no 1024-bit root certificates will be trusted to identify websites or software makers.

Please check your SSL certificates and replace any with 1024-bit RSA keys, and contact mozilla.dev.security.policy if you have comments or concerns.

Mozilla Security Engineering Team

Public key pinning released in Firefox

Sid Stamm


Firefox now supports built-in public key pins, which means that a shortened list of acceptable certificate authorities (CAs) for participating sites is built into Firefox. In this first stage of pinning roll-out, protected domains include addons.mozilla.org and Twitter, to be followed by Google and other sites in upcoming versions of Firefox. That means that Firefox users will be even safer when visiting Mozilla and Twitter (and soon, Google). For the full list of pinned domains and rollout status, please see the Public Key Pinning wiki. Additionally, sites may advertise their support for pinning with the Public Key Pinning Extension for HTTP, which we plan to implement soon.

Public Key Pinning helps ensure that people are connecting to the sites they intend. It allows site operators to specify which CAs issue valid certificates for them, rather than accepting any one of the hundreds of built-in root certificates that ship with Firefox. If any certificate in the verified certificate chain corresponds to one of the known good (pinned) certificates, Firefox displays the lock icon as normal. When the root cert for a pinned site does not match one of the known good CAs, Firefox will reject the connection with a pinning error. This type of error can also occur if a CA mis-issues a certificate. In this way, key pinning can be used by sites to add another layer of trust to their servers’ deployment of TLS.

For more details on how Pinning works, check out Monica’s blog post

Update on reviewing our data practices and Bugzilla development database disclosure



As we indicated in the post titled “MDN Disclosure”, we began several remediation measures, including a review of data practices surrounding user data. We have kicked off a larger project to better our practices around data, including with respect to the various non-Mozilla projects we support. We are implementing immediate fixes for any discovered issues across the organization, and are requiring each business unit to perform a review of their data practices and, if necessary, to implement additional protections based on that review.

As we proceed through our broader remediation program, we discovered an incident that occurred in the Bugzilla community, one of the community projects we support. A member of the Bugzilla community discovered that development database dump files containing email addresses and encrypted passwords were posted on a publicly accessible server. They were alerted to this incident by a security bug filed by a contributor. See the Bugzilla community blog post for more information.

While it is important to note that the disclosure of this development database does not affect bugzilla.mozilla.org, we continue to believe that the broader community would benefit from our increased focus on data practices and therefore will continue with our plan of including the Bugzilla project as well as other community projects in the data practices initiatives we’ve described above.

We are committed to continuing to improve our data practices to minimize the likelihood of these and other types of incidents.


Mozilla Security

mozilla::pkix ships in Firefox!

David Keeler

In April, we announced an upcoming certificate verification library designed from the ground up to be fast and secure. A few weeks ago, this new library – known as “mozilla::pkix” – shipped with Firefox and is enabled by default. Please see the original announcement for more details.
Along with using more verifiably secure coding practices, we took the opportunity to closely adhere to the X.509 certificate verification specifications for the Internet. For example, we prevent certificates from being misused in ways that legacy libraries often do not. This protects user data and promotes an overall more secure Web.
However, this sometimes comes at a compatibility cost. Some certificates issued by certificate authorities not in Mozilla’s Root CA program may no longer work in the same way. We are currently evaluating how we can best balance security with usability with regard to these certificates.
If you encounter compatibility issues, please read the Certificate Primer which contains information for creating a compatible certificate hierarchy.

MDN Database Disclosure



We have just concluded an investigation into a disclosure affecting members of Mozilla Developer Network. We began investigating the incident as soon as we learned of the disclosure. The issue came to light ten days ago when one of our web developers discovered that, starting on about June 23, for a period of 30 days, a data sanitization process of the Mozilla Developer Network (MDN) site database had been failing, resulting in the accidental disclosure of MDN email addresses of about 76,000 users and encrypted passwords of about 4,000 users on a publicly accessible server. As soon as we learned of it, the database dump file was removed from the server immediately, and the process that generates the dump was disabled to prevent further disclosure. While we have not been able to detect malicious activity on that server, we cannot be sure there wasn’t any such access.

We are known for our commitment to privacy and security, and we are deeply sorry for any inconvenience or concern this incident may cause you.

The encrypted passwords were salted hashes and they by themselves cannot be used to authenticate with the MDN website today. Still, it is possible that some MDN users could have reused their original MDN passwords on other non-Mozilla websites or authentication systems. We’ve sent notices to the users who were affected. For those that had both email and encrypted passwords disclosed, we recommended that they change any similar passwords they may be using.

In addition to notifying users and recommending short term fixes, we’re also taking a look at the processes and principles that are in place that may be made better to reduce the likelihood of something like this happening again. If you have questions, please reach out to security@mozilla.org.


Stormy Peters
Director of Developer Relations

Joe Stevensen
Operations Security Manager

Improving Malware Detection in Firefox

Sid Stamm


We are always looking for ways to help protect people better from the constant threat of malicious software. For years Firefox has utilized Google’s Safe Browsing phishing and malware protection to help keep you from accidentally visiting dangerous sites. This protection feature works by checking the sites that you visit against lists that Firefox downloads of reported phishing and malware sites. (For more details, check out this page.)

Firefox is about to get safer.

Until recently, we only had access to lists of reported malicious web sites, now the Safe Browsing service monitors malicious downloaded files too. The latest version of Firefox (as of July 22) will protect you from more malware by comparing files you download against these lists of malicious files, and blocking them from infecting your system.

The next version of Firefox (released in September) will prevent even more malicious downloads on Windows. When you download an application file, Firefox will verify the signature. If it is signed, Firefox then compares the signature with a list of known safe publishers. For files that are not identified by the lists as “safe” (allowed) or as “malware” (blocked), Firefox asks Google’s Safe Browsing service if the software is safe by sending it some of the download’s metadata. Note this online check will only be performed in Firefox on Windows for those downloaded files that don’t have a known good publisher. Most of the common and safe software for Windows is signed and so this final check won’t always need to happen.

In our preliminary testing, we estimate this new malware protection cuts the amount of malware that slips through Firefox’s protections in half. That’s a lot of malware that will be stopped in its tracks.

And of course if you don’t want to send Google data about the few downloads that don’t match these lists, you can turn off malware protection. But we believe eradicating malware is critical for most people, and expect this new feature to help work behind the scenes to keep you safe as you browse.

For more details, head on over to Monica’s blog post.