Mozilla Security Blog

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

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

Sep 8 2014

kwilson

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

SECOM

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

Sep 2 2014

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

Aug 27 2014

jstevensen

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.

Sincerely,

Mozilla Security

mozilla::pkix ships in Firefox!

Aug 20 2014

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

Aug 1 2014

Stormy

116

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.

Thanks,

Stormy Peters
Director of Developer Relations

Joe Stevensen
Operations Security Manager

Improving Malware Detection in Firefox

Jul 23 2014

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.

June is Internet Safety Month!

Jun 2 2014

Sid Stamm

Happy Internet Safety Month, everyone!

In today’s world it is more critical than ever to be aware of security risks online. High-profile and broad attacks made news quite a bit in the last year. From the Heartbleed vulnerability to spikes in credit card theft and fraud, buzz about online privacy and security is on the rise. Even the White House has turned attention to cybersecurity.

The Ponemon Institute estimates 47% of Americans have had their personal information compromised! So now is a great time to do some routine maintenance this month and beef up your safety:

Download a secure and private browser: A Web browser like Mozilla Firefox supports phishing and malware detection and protection from spyware, and also warns you about potentially fraudulent sites. Additionally, Firefox and most other Web browsers offer a “Do Not Track” feature that lets you opt to not have your information tracked by websites like advertising networks. For a sensitive browsing session you can temporarily enable private browsing which will help keep traces of that session hidden.
Keep your software up-to-date: Ensure any software you download to your desktop or your mobile device – including apps and add-ons – stays updated.
Secure your passwords: Create a unique password for each of your accounts by using a variety of upper and lowercase letters, numbers and punctuation marks. The new Firefox Sync makes it even easier to access your bookmarks, history, Awesome Bar intelligence, passwords, form-fill data and open tabs from Firefox running on other computers and mobile phones.
Look for the S: Never purchase anything from a site that doesn’t have SSL/TLS encryption. You’ll know because the site’s address will start with https:// instead of http://. Additionally, never provide your credit card information via email.
Don’t sacrifice security for mobility: Don’t just stop at your home computer. Extend your security to browsing from your mobile phone by making sure you’re always connected to a secure wireless network or your mobile provider’s 3G network before you enter any personal information or passwords or do any online shopping.

The Web is awesome. While we easily get lost in all the amazing stuff we can do online, this June the Anti-Phishing Working Group and National Cyber Security Alliance are encouraging people to Stop, Think, Connect to stay safe online.

Introducing Mozilla Winter of Security 2014

May 15 2014

Curtis Koenig

At Mozilla, we have a loosely formed group called Security Automation, where people who build security tools can meet, exchange ideas, and show their work. We build projects around applications and operations security. Some of the things we’ve worked on include ZAP, Zest, Plug’n’Hack, Minion, MIG, Mozdef, ScanJS or Cipherscan. And, as you would expect from Mozilla, our work is public for all to see, use, and contribute to.

In the past, students requested to work on some of these projects. One trend we’ve seen is that many students are looking for real world projects to sink their teeth into. Something worth their attention, and something people will actually use.

In response we decided to create the Mozilla Winter of Security, or MWoS. MWoS is composed of 11 projects from the Security Automation effort, that directly map the needs at Mozilla. They are designed to solve real world problems in an innovative, and open way. We also made them autonomous, such that students don’t need to learn the inner-working of Mozilla in order to work on these projects.

Winter of Security, so called because we want students to get involved 800px-Redpandas4430 roughly between September and April. Each project has an advisor from Mozilla who will be dedicating a few hours every week to the students. We also ask that a professor oversees the team from a university point of view, and ensures the projects align with their curriculum.
Anyone can apply, under the condition that the university will give class credits and a grade for the work done in MWoS.

MWoS is a win for all. Students get a chance to work on real-world security projects, under the guidance of an experienced security engineer. Professors get to implement cutting-edge security projects into their programs. Mozilla and the community get better security tools, which that we would not have the resources to build or improve ourselves.

If you are a professor, tell your students about the Mozilla Winter of Security today. If you are a student, start assembling your team, and fill up the application form before July 15th, 2014. We limited this round to 11 projects, with one team per project, and will be selecting the best applications in August.

If you have questions, and want to discuss MWoS, you can reach us on IRC in the #security channel, or via the discussion page on the wiki. If you want details about a specific project, feel free to contact the project advisor directly on IRC.

MWoS is part of the wider Mozilla Security Mentorship program.

Red Panda photograph from WikiMedia Commons under theCreative CommonsAttribution-Share Alike 3.0 Unported license.

Checking Compliance Status with Updated CA Certificate Policy

May 13 2014

kwilson

In early 2013 Mozilla released version 2.1 of Mozilla’s CA Certificate Policy, which added a requirement for either the technical constraint or the audit of subordinate CA certificates, and requires CAs who issue SSL certificates to comply with the CA/Browser Forum Baseline Requirements. Then, in July, we updated Mozilla’s CA Certificate Enforcement Policy to make it clear that Mozilla will not tolerate misuse of publicly trusted certificates. CAs were given a grace period of just over one year to comply with the changes introduced in version 2.1 of the policy. So, today we sent an email to all Certificate Authorities (CAs) in Mozilla’s CA program to check on their progress.

The communication includes the following 5 action items for CAs.

Ensure that Mozilla’s spreadsheet of included root certificates has the correct link to your most recent audit statement, and that the date of the audit statement is correct.
Send Mozilla the link to your most recent Baseline Requirements audit statement.
Test Mozilla’s new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed.
Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here.
Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla’s CA program, as per Items #8, 9, and 10 of Mozilla’s CA Certificate Inclusion Policy.

The full CA Communication is available here, and responses will be tabulated here.

We closed the communication by re-iterating 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.

Mozilla Security Engineering Team