Enforcing Content Security Historically
Enforcing Content Security By Default
Enforcing Content Security Historically
Enforcing Content Security By Default
Mozilla has discovered that a Certificate Authority (CA) called WoSign has had a number of technical and management failures. Most seriously, we discovered they were backdating SSL certificates in order to get around the deadline that CAs stop issuing SHA-1 SSL certificates by January 1, 2016. Additionally, Mozilla discovered that WoSign had acquired full ownership of another CA called StartCom and failed to disclose this, as required by Mozilla policy. The representatives of WoSign and StartCom denied and continued to deny both of these allegations until sufficient data was collected to demonstrate that both allegations were correct. The levels of deception demonstrated by representatives of the combined company have led to Mozilla’s decision to distrust future certificates chaining up to the currently-included WoSign and StartCom root certificates.
Specifically, Mozilla is taking the following actions:
If you receive a certificate from one of these two CAs after October 21, 2016, your certificate will not validate in Mozilla products such as Firefox 51 and later, until these CAs provide new root certificates with different Subject Distinguished Names, and you manually import the root certificate that your certificate chains up to. Consumers of your website will also have to manually import the new root certificate until it is included by default in Mozilla’s root store.
We believe that this response is consistent with Mozilla policy and is one which we could apply to any other CA that demonstrated similar levels of deception to circumvent Mozilla’s CA Certificate Policy, the CA/Browser Forum’s Baseline Requirements, and direct inquiries from Mozilla representatives.
Mozilla Security Team
An algorithm we’ve depended on for most of the life of the Internet — SHA-1 — is aging, due to both mathematical and technological advances. Digital signatures incorporating the SHA-1 algorithm may soon be forgeable by sufficiently-motivated and resourceful entities.
Via our and others’ work in the CA/Browser Forum, following our deprecation plan announced last year and per recommendations by NIST, issuance of SHA-1 certificates mostly halted for the web last January, with new certificates moving to more secure algorithms. Since May 2016, the use of SHA-1 on the web fell from 3.5% to 0.8% as measured by Firefox Telemetry.
In early 2017, Firefox will show an overridable “Untrusted Connection” error whenever a SHA-1 certificate is encountered that chains up to a root certificate included in Mozilla’s CA Certificate Program. SHA-1 certificates that chain up to a manually-imported root certificate, as specified by the user, will continue to be supported by default; this will continue allowing certain enterprise root use cases, though we strongly encourage everyone to migrate away from SHA-1 as quickly as possible.
This policy has been included as an option in Firefox 51, and we plan to gradually ramp up its usage. Firefox 51 is currently in Developer Edition, and is currently scheduled for release in January 2017. We intend to enable this deprecation of SHA-1 SSL certificates for a subset of Beta users during the beta phase for 51 (beginning November 7) to evaluate the impact of the policy on real-world usage. As we gain confidence, we’ll increase the number of participating Beta users. Once Firefox 51 is released in January, we plan to proceed the same way, starting with a subset of users and eventually disabling support for SHA-1 certificates from publicly-trusted certificate authorities in early 2017.
Questions about SHA-1 based certificates should be directed to the mozilla.dev.security.policy forum.
Earlier this week, security researchers published reports that Firefox and Tor Browser were vulnerable to “man-in-the-middle” (MITM) attacks under special circumstances. Firefox automatically updates installed add-ons over an HTTPS connection. As a backup protection measure against mis-issued certificates, we also “pin” Mozilla’s web site certificates, so that even if an attacker manages to get an unauthorized certificate for our update site, they will not be able to tamper with add-on updates.
Due to flaws in the process we used to update “Preloaded Public Key Pinning” in our releases, the pinning for add-on updates became ineffective for Firefox release 48 starting September 10, 2016 and ESR 45.3.0 on September 3, 2016. As of those dates, an attacker who was able to get a mis-issued certificate for a Mozilla Web site could cause any user on a network they controlled to receive malicious updates for add-ons they had installed.
Users who have not installed any add-ons are not affected. However, Tor Browser contains add-ons and therefore all Tor Browser users are potentially vulnerable. We are not presently aware of any evidence that such malicious certificates exist in the wild and obtaining one would require hacking or compelling a Certificate Authority. However, this might still be a concern for Tor users who are trying to stay safe from state-sponsored attacks. The Tor Project released a security update to their browser early on Friday; Mozilla is releasing a fix for Firefox on Tuesday, September 20.
To help users who have not updated Firefox recently, we have also enabled Public Key Pinning Extension for HTTP (HPKP) on the add-on update servers. Firefox will refresh its pins during its daily add-on update check and users will be protected from attack after that point.
This is a short announcement for all security researchers working on Firefox that use our pre-built AddressSanitzer (ASan) builds. Until recently, you could download these ASan builds from our FTP servers. Due to changes to our internal build infrastructure, these builds are no longer available from the usual location. Instead, they are available on a build system called TaskCluster. Most people just need the latest available build for testing purposes. Fortunately, this is easy to get:
For more advanced queries, TaskCluster offers a public API that can be used to interact with the system (e.g. to retrieve past builds). More information is available in the documentation.
Scanning the content of a file allows web browsers to detect the format of a file regardless of the specified Content-Type by the web server. For example, if Firefox requests script from a web server and that web server sends that script using a Content-Type of “image/jpg” Firefox will successfully detect the actual format and will execute the script. This technique, colloquially known as “MIME sniffing”, compensates for incorrect, or even complete absence of metadata browsers need to interpret the contents of a page resource. Firefox uses contextual clues (the HTML element that triggered the fetch) or also inspects the initial bytes of media type loads to determine the correct content type. While MIME sniffing increases the web experience for the majority of users, it also opens up an attack vector known as MIME confusion attack.
Starting with Firefox 50, Firefox will reject stylesheets, images or scripts if their MIME type does not match the context in which the file is loaded if the server sends the response header “X-Content-Type-Options: nosniff” (view specification). More precisely, if the Content-Type of a file does not match the context (see detailed list of accepted Content-Types for each format underneath) Firefox will block the file, hence prevent such MIME confusion attacks and will display the following message in the console:
Valid Content-Types for Stylesheets:
Valid Content-Types for images:
– have to start with “image/”
Valid Content-Types for Scripts:
The Mozilla Winter of Security of 2015 has ended, and the participating teams of students are completing their projects.
The Certificate Automation tooling for Let’s Encrypt project wrapped up this month, having produced an experimental proof-of-concept patch for the Nginx webserver to tightly integrate the ACME automated certificate management protocol into the server operation.
The MWoS team, my co-mentor Richard Barnes, and I would like to thank Klaus Krapfenbauer, his advisor Martin Schmiedecker, and the Technical University of Vienna for all the excellent research and work on this project.
Below is Klaus’ end-of-project presentation on AirMozilla, as well as further details on the project.
Author: Klaus Krapfenbauer
Note: The module is an incomplete proof-of-concept, available at https://github.com/mozilla/mwos-letsencrypt-2015
What security engineers do at Mozilla is critical — not for just Firefox users, but for the whole Web. If you’ve ever used the OWASP Zed Attack Proxy, read our security guidelines on SSH and TLS or evaluated your website using the HTTP Observatory, then you have benefitted from the work of Mozilla’s security teams. That’s why we make sure to recruit some of the world’s best talent in the field who want to have a real impact on the Web’s security.
Mozilla Winter of Security (MWoS) is an opportunity for us to do just that, inviting students to pair up with our engineers to contribute to some of Mozilla’s security projects. Today we are announcing that the third-ever MWoS is open for applications.
Every year, we select projects that present an interesting security challenge. For mentors, MWoS is an opportunity to open projects from the Mozilla ecosystem to external contributors, and receive help to make progress in areas they may not have time to focus on. For students, MWoS is a gateway to the open source security world and a chance to solve real-world problems. This mutually beneficial formula has led 33 students to write code for 16 security projects in the last two years. Several of these projects are now fully integrated in the work we do to keep Mozilla and the Internet safe. Take the TLS Observatory, a platform developed by Dimitris Bachtis from Greece (MWoS 2014) that helps operators configure HTTPS properly on their sites. Another example is the MIG Sandbox, a Go package implementing Linux seccomp to secure Mozilla Investigator, and written by Teodora Băluță, Vladimir Diaconescu and Constantin-Alexandru Tudorică from Romania (MWoS 2015).
This year, MWoS has expanded to include Mozilla’s Crypto team with five projects for NSS, the network security library of Firefox. Alongside cryptography, the 2016 edition of MWoS will feature twelve projects spread across various disciplines, including web and infrastructure security. The projects are:
A full list of projects with their details is available at https://wiki.mozilla.org/Security/Automation/Winter_Of_Security_2016.
To apply, teams must be engaged in a university program and their professor must agree to give the team credits for their MWoS project. Our experience tells us this requirement ensures students have the time and motivation to work on their project, and helps provide a better mentoring experience for everyone.
Applications open today and will close on September 15th. If you are a professor, we encourage you to tell your students about MWoS. If you are a student looking to have a real impact on the security of the Web, start assembling your team, and fill out the application form before September 15th. We will contact the teams and let them know if they have been selected within two weeks after the deadline.
If you have any questions about the MWoS program or the projects, please contact the mentors directly by email and on Mozilla’s #security IRC channel. We look forward to having you join us!
Protection against malicious downloads was added in Firefox 31 on Windows and in Firefox 39 on Mac and Linux. Thanks to Google’s expansion of their Safe Browsing service, Firefox 48 now extends our existing protection to include two additional kinds of downloads: potentially unwanted software and uncommon downloads.
The first new category, potentially unwanted software, is meant to flag software that makes unexpected changes to your computer, as explained in the Google policy. It is usually best to avoid this kind of software since it could (for example) collect your personal information without your consent and use techniques to make it difficult to uninstall.
The second category, uncommon downloads, covers downloads which may not be malicious or unwanted but that are simply not commonly downloaded. The purpose of this warning is to draw users’ attention to the fact that this may not be the download they think it is. For example, if you are looking to download a new version of Firefox or a popular software package such as VLC and get this warning, it is possible that you have been tricked into downloading a malicious file from a phishing site which has not yet been identified as such by the Google Safe Browsing service. You may want to double-check the address of the site where you downloaded this file and proceed with caution.
In addition to the new categories described above, we have made improvements to the user interface to make it easier for users to notice and understand these warnings.
Here is what the download button now looks like when a download has been flagged by download protection:
Depending on the category, the default action button will be either “open” or “remove”:
and the following confirmation dialog was added to help users understand the risks involved:
We have retained the ability for users to override all of these warnings via the contextual menu if they are convinced that the warning is erroneous:
The security options in Firefox had remained the same since browsing protection was first introduced in Firefox 3. This is what they looked like in Firefox 47:
and this is how they changed in Firefox 48 to give users more control around download and browsing protection:
While we believe that the vast majority of our users will prefer to keep all of the protections that Safe Browsing offers, we understand that some users may choose to disable parts of the Safe Browsing service based on the privacy guarantees they offer. Our new options aim to give concerned users the necessary level of control and to enable them to retain as much of the Safe Browsing service as they are comfortable with.
Here are what the new options mean:
Expert users are always welcome to explore (at their own risk) the additional internal configuration settings which are not exposed through the user interface.
Mozilla has sent a Communication to the Certification Authorities (CAs) who have root certificates included in Mozilla’s program. Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies and open-source projects in a variety of applications.
With this CA Communication, we re-iterate 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.