Phasing out Certificates with 1024-bit RSA Keys

kwilson

1

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

Sid Stamm

4

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

jstevensen

2

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!

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

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

Sid Stamm

14

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!

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

Curtis Koenig

20

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-Redpandas4430roughly 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

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.

  1. 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.
  2. Send Mozilla the link to your most recent Baseline Requirements audit statement.
  3. Test Mozilla’s new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed.
  4. Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here.
  5. 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

Hack in the Box HackWeekDay 2014

Paul Theriault

The Mozilla security team is proud to be once again sponsoring the Hack-in-the-Box HackWeekDay competition, this time at the Haxpo conference in Amsterdam, 28-30 May 2014. Come learn about Firefox OS, make apps to compete for great prizes and help shape the future of the mobile web.

This HackWeekDay event is the biggest yet, and will actually be run over the course of three separate days. There will daily prizes, and you can compete in as many days as you want:

  • Day 1: Firefox OS Homescreen & WebRTC applications
  • Day 2: Facebook Social/Parse APIs applications
  • Day 3: Combined app hacking competition – build on your apps from previous days, or come up with a new app, and compete for the grand prize of most 1337 app.

You can attend just one day, or compete in all three. For details of the prizes on offer and how to get involved, see the HackWeekDay page on the HITB website.

Firefox OS Homescreen & WebRTC applications

For the the first day (28th May), the competition will focus on creating Firefox OS App which incorporates one of the following themes:

  • Replaceable Homescreen: prototype new homescreen ideas for Firefox OS, and implement this using the new replaceable homescreen feature
  • WebRTC: prototype an app which uses WebRTC, taking advantage of WebRTC to access camera, microphone and/or peer-to-peer networking.

A group of Mozillians will be there to help developers test their entries on Firefox OS devices and award prizes (including the new Firefox OS Flame developer phones!)

Register Now!

How can people get prepared?

Interested developers who want to get started should get familiar with how to develop Apps for Firefox OS and learn about WebRTC:

If you want to develop on Firefox OS itself, see the Hacking on Gaia page on MDN.

What are we looking for in the entries?

  • Prototypes which effectively demonstrate a new or interesting feature
  • Innovative use of Web APIs
  • High quality execution (especially on the constraints of mobile)
  • Benefits for the security and privacy of Firefox OS users

What about others who can’t attend the conference ?

  • Make apps for the Mozilla marketplace
  • Volunteer to help Mozilla security team on Firefox OS (or anything else) (come find us on irc.mozilla.org#security or email security@mozilla.org)

Will the community be there?

Yes! Mozilla Nederland is planning a presence at the event.