Mitigating MIME Confusion Attacks in Firefox

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.

Consider a web application which allows users to upload image files but does not verify that the user actually uploaded a valid image, e.g., the web application just checks for a valid file extension. This lack of verification allows an attacker to craft and upload an image which contains scripting content. The browser then renders the content as HTML opening the possibility for a Cross-Site Scripting attack (XSS). Even worse, some files can even be polyglots, which means their content satisfies two content types. E.g., a GIF can be crafted in a way to be valid image and also valid JavaScript and the correct interpretation of the file solely depends on the context.

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:

The resource from “” was blocked due to MIME type mismatch (X-Content-Type-Options: nosniff).

Valid Content-Types for Stylesheets:
– “text/css”

Valid Content-Types for images:
– have to start with “image/”

Valid Content-Types for Scripts:
– “application/javascript”
– “application/x-javascript”
– “application/ecmascript”
– “application/json”
– “text/ecmascript”
– “text/javascript”
– “text/json”

MWoS 2015: Let’s Encrypt Automation Tooling

winterOfSecurity_logo_dark_vertical2The 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.

MWoS Let’s Encrypt Certificate Automation presentation on AirMozilla

Developing an ACME Module for Nginx

Author: Klaus Krapfenbauer

Note: The module is an incomplete proof-of-concept, available at

Continue reading …

Announcing the 2016 edition of Mozilla Winter of Security

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

  • MIG: A web interface for Mozilla Investigator
  • ZAP: Field Enumeration
  • ZAP: Form Handling
  • ZAP: Automated authentication detection and configuration
  • Plug’n’hack / ringleader: Support for e10s (and more)
  • NSS: Demos
  • NSS: Server integration
  • NSS: SHA-3 Implementation
  • NSS: Formal Verification
  • NSS: TLS Interoperability
  • ssh_scan: Improving Scalability and Feature Set
  • Security Testing Workflow and Toolchain for Python Websites and Services

A full list of projects with their details is available at

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!

Enhancing Download Protection in Firefox

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.

Expanded protection

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.

Improved user interface

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:

Yellow exclamation mark

Potentially unwanted or uncommon downloads

Red exclamation mark

Malicious downloads

Depending on the category, the default action button will be either “open” or “remove”:

Door hanger with yellow triangle and open button

Potentially unwanted downloads

Door hanger with blue "i" and open button

Uncommon downloads

Door hanger with red "x" and close button

Malicious downloads

and the following confirmation dialog was added to help users understand the risks involved:

Confirmation dialog box defaulting to "Remove file"

Potentially unwanted downloads

Confirmation dialog box defaulting to "Open"

Uncommon downloads

Confirmation dialog box defaulting to "Cancel"

Malicious downloads

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:

Menu with "Allow Download" selected using the mouse

Contextual menu

More control for users

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:

Security options showing two Safe Browsing options

Security options prior to Firefox 48

and this is how they changed in Firefox 48 to give users more control around download and browsing protection:

Security options showing three Safe Browsing options

Security options in Firefox 48

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:

  • Block dangerous and deceptive content: This enables warnings when visiting pages which contain malware or deceptive content. It is required by the rest of the Safe Browsing functionality.
  • Block dangerous downloads: This enables the download protection feature which may use a remote server to detect malicious executable files.
  • Warn me about unwanted and uncommon software: This extends the download protection feature to also warn about potentially unwanted and uncommon downloads.

Expert users are always welcome to explore (at their own risk) the additional internal configuration settings which are not exposed through the user interface.

March 2016 CA Communication

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.

The CA Communication has been emailed to the Primary Point of Contact (POC) for each CA in Mozilla’s program, and they have been asked to respond to 7 action items:

  1. Update us on their progress in eliminating use of SHA-1 as a certificate signature algorithm;
  2. Enter intermediate certificate data into the CA Community in Salesforce;
  3. Enter revoked intermediate certificate data into the CA Community in Salesforce;
  4. Stop issuing certificates with the problems listed here, because we are going to remove the workarounds from mozilla::pkix;
  5. Tell us their plans for removing root certificates that they have retired or are migrating their customers away from;
  6. Confirm their understanding that all certificates, including test certificates, must conform to Mozilla’s stated policies; and
  7. Update us on changes involving transfer of ownership of root certificates, according to our Root Transfer Policy.

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

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.

Payment Processors Still Using Weak Crypto

Part of how Mozilla protects the Web is by participating in the governance of the Web PKI, the system of security certificates that allows websites to authenticate themselves to browsers. Together with the other browsers and stakeholders in the Web, we agree on standards for how such certificates are issued.  We then require that these standards, plus a few additional ones specific to Mozilla, be applied to all certificates which are issued, directly or indirectly, by the “roots” that Firefox trusts.

We have been notified that some payment providers are using Web PKI certificates (i.e. certificates which chain up to roots trusted by Firefox) to secure the connection between central servers and payment terminals, for the purpose of transmitting payment data over the public Internet. Unfortunately, some of those non-browser users of the Web PKI have not kept up with the advances in security that the Web is achieving. The SHA-1 hash algorithm (used to validate the integrity of a certificate) has been declared obsolete in the Web PKI, but these providers have failed to upgrade these devices to support its replacement, SHA-2, despite the SHA-1 deadlines having been set years ago. As a result, many payment-related devices continue to require their servers to have certificates which use SHA-1 in order to be able to operate.

In particular, Worldpay PLC approached Mozilla through their Certificate Authority, Symantec, to request authorization to issue, in violation of standard policy, a limited number of SHA-1 certificates needed to support a large number of outdated devices. They made this request less than two weeks before the authorization needed to be effective. To avoid disruption for users of these devices, after a discussion on the mailing list, in this particular case we have decided to allow these certificates to be issued, but only under a set of conditions that ensure that the issuance of SHA-1 certificates is fully transparent and allowed only for purposes of transition to SHA-2.

This authorization means that Symantec can issue SHA-1 certificates that will enable Worldpay’s devices to keep operating a while longer, and that issuance will not be regarded by Mozilla as a defect. This decision only affects the Mozilla root program; other root programs may still consider the issuance of these certificates to be a mis-issuance.

We understand that there are payment processing organizations other than Worldpay that continue to have similar requirements for SHA-1 — either within the Web PKI or outside it. It is disappointing that these organizations are putting the public’s data at risk by using a weak, outdated security technology.  We encourage organizations with a continuing need for SHA-1 in the Web PKI to come forward as soon as possible and provide as much detail as possible about their plans for a transition to SHA-2.

Mozilla Winter of Security-2015 MozDef: Virtual Reality Interface

Mozilla runs Winter of Security (MWoS) every year to give folks an opportunity to contribute to ongoing security projects in flight. This year an ambitious group took on the task of creating a new visual interface in our SIEM overlay for Elastic  Search that we call MozDef: The Mozilla Defense Platform.

Security personnel are in high demand and analyst skill sets are difficult to maintain. Rather than only focusing on making people better at security, I’m a firm believer that we need to make security better at people. Interfaces that are easier to comprehend and use seem to be a worthwhile investment in that effort and I’m thrilled with the work this team has done.

They’ve wrapped up their project with a great demo of their work. If you are interested in security automation tools and alternative user interfaces, take a couple minutes and check out their work over at air mozilla.


Man-in-the-Middle Interfering with Increased Security

According to the plan we published earlier for deprecating SHA-1, on January 1, 2016, Firefox 43 began rejecting new certificates signed with the SHA-1 digest algorithm.  For Firefox users with unfiltered access to the Internet, this change probably went unnoticed, since there simply aren’t that many new SHA-1 certs being used.  However, for Firefox users who are behind certain “man-in-the-middle” devices (including some security scanners and antivirus products), this change removed their ability to access HTTPS web sites.  When a user tries to connect to an HTTPS site, the man-in-the-middle device sends Firefox a new SHA-1 certificate instead of the server’s real certificate.  Since Firefox rejects new SHA-1 certificates, it can’t connect to the server.

How to tell if you’re affected

If you can access this article in Firefox, you’re fine.  If you’re reading this in another browser, see if you can load the security blog (or any other HTTPS link) in Firefox.  Click “Advanced”, and if you see the error code “SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED”, then you’re affected.

What to do if you’re affected

The easiest thing to do is to install the newest version of Firefox.  You will need to do this manually, using an unaffected copy of Firefox or a different browser, since we only provide Firefox updates over HTTPS.

If you want to avoid reinstalling, advanced users can fix their local copy of Firefox by going to about:config and changing the value of “security.pki.sha1_enforcement_level” to 0 (which will accept all SHA-1 certificates).

You should also make sure that any systems you have that might be doing man-in-the-middle are up to date, for example, some anti-virus software or security scanning devices.  Some vendors have removed the use of SHA-1 in recent updates.

Commitment to deprecate SHA-1

We are still committed to removing support for SHA-1 certificates from Firefox.  The latest version of Firefox re-enables support for SHA-1 certificates to ensure that we can get updates to users behind man-in-the-middle devices, and enable us to better evaluate how many users might be affected.  Vendors of TLS man-in-the-middle systems should be working to update their products to use newer digest algorithms.

Improving Revocation: OCSP Must-Staple and Short-lived Certificates

Last year, we laid out a long-range plan for improving revocation support for Firefox. As of this week, we’ve completed most of the major elements of that plan. After adding OneCRL earlier this year, we have recently added support for OCSP Must-Staple and short-lived certificates. Together, these changes enable website owners several ways to achieve fast, secure certificate revocation.

In an ideal world, the browser would perform an online status check (such as OCSP) whenever it verifies a certificate, and reject the certificate if the check failed. However, these checks can be slow and unreliable. They time out about 15% of the time, and take about 350ms even when they succeed. Browsers generally soft-fail on revocation in an attempt to balance these concerns.

To get back to stronger revocation checking, we have added support for short-lived certificates and Must-Staple to let sites opt in to hard failures. As of Firefox 41, Firefox will not do “live” OCSP queries for sufficiently short-lived certs (with a lifetime shorter than the value set in “security.pki.cert_short_lifetime_in_days”). Instead, Firefox will just assume the certificate is valid. There is currently no default threshold set, so users need to configure it. We are collecting telemetry on certificate lifetimes, and expect to set the threshold somewhere around the maximum OCSP response lifetime specfied in the baseline requirements.

OCSP Must-Staple makes use of the recently specified TLS Feature Extension. When a CA adds this extension to a certificate, it requires your browser to ensure a stapled OCSP response is present in the TLS handshake. If an OCSP response is not present, the connection will fail and Firefox will display a non-overridable error page. This feature will be included in Firefox 45, currently scheduled to be released in March 2016.

Updated Firefox Security Indicators

This article has been coauthored by Aislinn Grigas, Senior Interaction Designer, Firefox Desktop

Over the past few months, Mozilla has been improving the user experience of our privacy and security features in Firefox. One specific initiative has focused on the feedback shown in our address bar around a site’s security. The major changes are highlighted below along with the rationale behind each change.

Change to DV Certificate treatment in the address bar

Color and iconography is commonly used today to communicate to users when a site is secure. The most widely used patterns are coloring a lock icon and parts of the address bar green. This treatment has a straightforward rationale given green = good in most cultures. Firefox has historically used two different color treatments for the lock icon – a gray lock for Domain-validated (DV) certificates and a green lock for Extended Validation (EV) certificates. The average user is likely not going to understand this color distinction between EV and DV certificates. The overarching message we want users to take from both certificate states is that their connection to the site is secure. We’re therefore updating the color of the lock when a DV certificate is used to match that of an EV certificate.

Although the same green icon will be used, the UI for a site using EV certificates will continue to differ from a site using a DV certificate. Specifically, EV certificates are used when Certificate Authorities (CA) verify the owner of a domain. Hence, we will continue to include the organization name verified by the CA in the address bar.

Changes to Mixed Content Blocker UI on HTTPS sites

A second change we’re introducing addresses what happens when a page served over a secure connection contains Mixed Content. Firefox’s Mixed Content Blocker proactively blocks Mixed Active Content by default. Users historically saw a shield icon when Mixed Active Content was blocked and were given the option to disable the protection.

Since the Mixed Content state is closely tied to site security, the information should be communicated in one place instead of having two separate icons. Moreover, we have seen that the number of times users override mixed content protection is slim, and hence the need for dedicated mixed content iconography is diminishing. Firefox is also using the shield icon for another feature in Private Browsing Mode and we want to avoid making the iconography ambiguous.

The updated design that ships with Firefox 42 combines the lock icon with a warning sign which represents Mixed Content. When Firefox blocks Mixed Active Content, we retain the green lock since the HTTP content is blocked and hence the site remains secure.

For users who want to learn more about a site’s security state, we have added an informational panel to further explain differences in page security. This panel appears anytime a user clicks on the lock icon in the address bar.

Previously users could click on the shield icon in the rare case they needed to override mixed content protection. With this new UI, users can still do this by clicking the arrow icon to expose more information about the site security, along with a disable protection button.

mixed active content click and subpanel

Users can click the lock with warning icon and proceed to disable Mixed Content Protection.

Loading Mixed Passive Content on HTTPS sites

There is a second category of Mixed Content called Mixed Passive Content. Firefox does not block Mixed Passive Content by default. However, when it is loaded on an HTTPS page, we let the user know with iconography and text. In previous versions of Firefox, we used a gray warning sign to reflect this case.

We have updated this iconography in Firefox 42 to a gray lock with a yellow warning sign. We degrade the lock from green to gray to emphasize that the site is no longer completely secure. In addition, we use a vibrant color for the warning icon to amplify that there is something wrong with the security state of the page.

We also use this iconography when the certificate or TLS connection used by the website relies on deprecated cryptographic algorithms.

The above changes will be rolled out in Firefox 42. Overall, the design improvements make it simpler for our users to understand whether or not their interactions with a site are secure.

Firefox Mobile

We have made similar changes to the site security indicators in Firefox for Android, which you can learn more about here.