Communicating the Dangers of Non-Secure HTTP

Password Field with Warning Drop Down

HTTPS, the secure variant of the HTTP protocol, has long been a staple of the modern Web. It creates secure connections by providing authentication and encryption between a browser and the associated web server. HTTPS helps keep you safe from eavesdropping and tampering when doing everything from online banking to communicating with your friends. This is important because over a regular HTTP connection, someone else on the network can read or modify the website before you see it, putting you at risk.

To keep users safe online, we would like to see all developers use HTTPS for their websites. Using HTTPS is now easier than ever. Amazing progress in HTTPS adoption has been made, with a substantial portion of web traffic now secured by HTTPS:

Changes to Firefox security user experience
Up until now, Firefox has used a green lock icon in the address bar to indicate when a website is using HTTPS and a neutral indicator (no lock icon) when a website is not using HTTPS. The green lock icon indicates that the site is using a secure connection.

Address bar showing green lock at

Current secure (HTTPS) connection

Address bar at over HTTP

Current non-secure (HTTP) connection

In order to clearly highlight risk to the user, starting this month in Firefox 51 web pages which collect passwords but don’t use HTTPS will display a grey lock icon with a red strike-through in the address bar.

Control Center message when visiting an HTTP page with a Password field

Clicking on the “i” icon, will show the text, “Connection is Not Secure” and “Logins entered on this page could be compromised”.

This has been the user experience in Firefox Dev Edition since January 2016. Since then, the percentage of login forms detected by Firefox that are fully secured with HTTPS has increased from nearly 40% to nearly 70%, and the number of HTTPS pages overall has also increased by 10%, as you can see in the graph above.

In upcoming releases, Firefox will show an in-context message when a user clicks into a username or password field on a page that doesn’t use HTTPS.  That message will show the same grey lock icon with red strike-through, accompanied by a similar message, “This connection is not secure. Logins entered here could be compromised.”:

Login form with Username and Password field; Password field shows warning

In-context warning for a password field on a page that doesn’t use HTTPS

What to expect in the future
To continue to promote the use of HTTPS and properly convey the risks to users, Firefox will eventually display the struck-through lock icon for all pages that don’t use HTTPS, to make clear that they are not secure. As our plans evolve, we will continue to post updates but our hope is that all developers are encouraged by these changes to take the necessary steps to protect users of the Web through HTTPS.

For more technical details about this feature, please see our blog post from last year. In order to test your website before some of these changes are in the release version of Firefox, please install the latest version of Firefox Nightly.

Thank you to the engineering, user experience, user research, quality assurance, and product teams that helped make this happen – Sean Lee, Tim Guan-tin Chien, Paolo Amadini, Johann Hofmann, Jonathan Kingston, Dale Harvey, Ryan Feeley, Philipp Sackl, Tyler Downer, Adrian Florinescu, and Richard Barnes. And a very special thank you to Matthew Noorenberghe, without whom this would not have been possible.

Fixing an SVG Animation Vulnerability

At roughly 1:30pm Pacific time on November 30th, Mozilla released an update to Firefox containing a fix for a vulnerability reported as being actively used to deanonymize Tor Browser users.  Existing copies of Firefox should update automatically over the next 24 hours; users may also download the updated version manually.

Early on Tuesday, November 29th, Mozilla was provided with code for an exploit using a previously unknown vulnerability in Firefox.  The exploit was later posted to a public Tor Project mailing list by another individual.  The exploit took advantage of a bug in Firefox to allow the attacker to execute arbitrary code on the targeted system by having the victim load a web page containing malicious JavaScript and SVG code.  It used this capability to collect the IP and MAC address of the targeted system and report them back to a central server.  While the payload of the exploit would only work on Windows, the vulnerability exists on Mac OS and Linux as well.  Further details about the vulnerability and our fix will be released according to our disclosure policy.

The exploit in this case works in essentially the same way as the “network investigative technique” used by FBI to deanonymize Tor users (as FBI described it in an affidavit).  This similarity has led to speculation that this exploit was created by FBI or another law enforcement agency.  As of now, we do not know whether this is the case.  If this exploit was in fact developed and deployed by a government agency, the fact that it has been published and can now be used by anyone to attack Firefox users is a clear demonstration of how supposedly limited government hacking can become a threat to the broader Web.

Enforcing Content Security By Default within Firefox

Before loading a URI, Firefox enforces numerous content security checks verifying that web content can not perform malicious actions. As a first line of defense for example, Firefox enforces the Same-Origin policy (SOP) which prevents malicious script on one origin from obtaining access to sensitive content on another origin. Firefox’ content security checks also ensure that web content rendering on a user’s desktop or mobile device can not access local files. Additionally Firefox supports and enforces: Cross-Origin Resource Sharing (CORS), Mixed Content Blocking, Content Security Policy (CSP), Subresource Integrity (SRI), and applies many more mitigation strategies to prevent web content from performing malicious actions. We refer the reader to Mozilla’s HTTP Observatory to find more information on the latest content security concepts and how to configure a site safely and securely. Worth mentioning is that over time not only the web evolves but also content security mechanisms necessary to ensure an end user’s security and privacy and hence it’s vital to provide an API that new security features within a browser can rely on.


Enforcing Content Security Historically

The name of Firefox’ layout engine is Gecko which reads web content, such as HTML, CSS, JavaScript, etc. and renders it on the user’s screen. For loading resources over the internet, Firefox relies on the network library called Necko. Necko is a platform-independent API and provides functionality for several layers of networking, ranging from transport to presentation layers. For historical reasons, Necko was developed to be available as a standalone client. That separation also caused security checks to happen in Gecko rather than Necko and caused Necko to be agnostic about load context.
As illustrated, Gecko performs all content security checks before resources are requested over the network through Necko. The downside of this legacy architecture is, that all the different subsystems in Gecko need to perform their own security checks before resources are requested over the network. For example, ImageLoader as well as ScriptLoader have to opt into the relevant security checks before initiating a GET request of the image or script to be loaded, respectively. Even though systematic security checks were always performed, those security checks were sprinkled throughout the codebase. Over time, various specifications for dynamically loading content have proven that such a scattered security model is error-prone.


Enforcing Content Security By Default

Instead of opting into security checks wherever resource loads are initiated throughout the codebase, we refactored Firefox so content security checks are enforced by default.
As illustrated, we revamped the security landscape of Firefox providing an API that centralizes all the security checks within Necko. Instead of performing ad hoc security checks for each network request within Gecko, our implementation enables Gecko to provide information about the load context so Necko can perform the relevant security checks in a centralized manner. Whenever data (script, css, image,…) is about to be requested from the network, our technique creates and attaches an immutable loadinfo-object to every network request which remains assigned to a network load throughout the whole loading process and allows Firefox to provide the same security guarantees for resource loads that encounter a server-side redirect.
For an in-depth description of our implementation, which will be fully enforced within Firefox (v. 53), we refer the reader to our publication Enforcing Content Security By Default within Web Browsers (DOI 10.1109/SecDev.2016.8) which was presented at the IEEE International Conference on Cybersecurity Development on November 4th, 2016.

Distrusting New WoSign and StartCom Certificates

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:

  1. Distrust certificates with a notBefore date after October 21, 2016 which chain up to the following affected roots. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the affected roots.
    • This change will go into the Firefox 51 release train.
    • The code will use the following Subject Distinguished Names to identify the root certificates, so that the control will also apply to cross-certificates of these roots.
      • CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
      • CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
      • CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
        CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
      • CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
      • CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL
  2. Add the previously identified backdated SHA-1 certificates chaining up to these affected roots to OneCRL.
  3. No longer accept audits carried out by Ernst & Young Hong Kong.
  4. Remove these affected root certificates from Mozilla’s root store at some point in the future. If the CA’s new root certificates are accepted for inclusion, then Mozilla may coordinate the removal date with the CA’s plans to migrate their customers to the new root certificates. Otherwise, Mozilla may choose to remove them at any point after March 2017.
  5. Mozilla reserves the right to take further or alternative action.

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.

Each of these CAs may re-apply for inclusion of new (replacement) root certificates as described in Bug #1311824 for WoSign, and Bug #1311832 for StartCom.

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

Phasing Out SHA-1 on the Public Web

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

Update on add-on pinning vulnerability

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.

Firefox AddressSanitizer builds have been moved

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:

Direct Download for Latest Firefox AddressSanitizer Build

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.

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!