Requiring Better Cryptography in Firefox and Thunderbird Breaks Update Functionality

After updating Firefox and Thunderbird, I usually have a quick look through the many preferences listed in about:config because Firefox updates have a history of removing, breaking and changing privacy-related user preferences without notification.  Lately, these “changes” have all looked like concessions to the ad industry masked as “usability improvements” to make configuration less confusing for the average user.

While even I would not recommend requiring TLS 1.2 in Firefox for general browsing because it breaks a lot of “secure” sites, I still prefer to configure that requirement in one particular Firefox installation used exclusively for logging into Gmail, which does support TLS 1.2.  In the latest stable releases of Firefox as of today (and Thunderbird, which also supports TLS 1.2 if you use it to connect to Gmail), you would do that by navigating to the about:config menu and then:

  • changing security.tls.version.max to 3 to set TLS 1.2 as the maximum allowed (TLS 1.1 is the maximum allowed by default as of this writing)
  • changing security.tls.version.min to 3 to require TLS 1.2 as the minimum required
  • changing security.enable_tls_session_tickets to false to disable TLS client-initiated renegotiation for good measure
  • optionally disabling weak cipher suites for good measure

Together, these settings will ensure that Firefox uses the latest available TLS protocol and mitigates certain attacks.

Unfortunately for Firefox users, “hardening” your browser settings in this way actually breaks Firefox and Thunderbird update checking and add-on update checking, which prevents the security and privacy-conscious users who take the time to enable these settings from obtaining the latest and greatest Firefox, Thunderbird, and Add-On releases.  This normally wouldn’t be all that surprising or worthy of criticism because so many other servers are even worse, and TLS 1.2 adoption is still not as widespread as it should be.

But it was too ironic not to mention these deficiencies because Julien Vehent of Mozilla’s security team just wrote a blog post bragging about some improvements to Mozilla’s server-side TLS configuration.

I’ve pasted my thoughts on that blog post, which I also tried to leave as a comment on the blog post but doubt will be approved by the moderator:

These changes are a important step in the right direction, but failing to enable server-side TLS 1.2 for Firefox/Thunderbird update and add-on update checking for clients who have changed their settings to require TLS 1.2 remain important oversights in my view.  I understand the compatibility concerns associated with old, bad configurations, but still fail to see the downside of enabling TLS 1.2 by default in Thunderbird and Firefox by setting security.tls.version.max to 3.

Some more details on server-side issues that deserve to be addressed…
If Firefox users set security.tls.version.max and security.tls.version.min to 3 in about:config on both Firefox and Thunderbird to require TLS 1.2, users will not be notified of any updates to Firefox or Thunderbird.  Below, I’ve flagged a few issues with specific Mozilla servers that Firefox and Thunderbird users might care most about:

  • addons.cdn.mozilla.net, which according to a Qualys SSL handshake simulation test run on November 19th is not forward secret and does not mitigate BEAST attacks
  • versioncheck.addons.mozilla.org, which according to a Qualys SSL handshake simulation test run on November 19th is not forward secret, does not support TLS 1.2, allows client-initiated renegotiation, and leaves RC4 enabled
  • services.addons.mozilla.org weirdly failed several Qualys SSL tests attempted on November 19th, but I wouldn’t be surprised if it had the same issues as the servers above

<end probably-censored blog comment>

I didn’t take a look at any of the servers that Firefox and Thunderbird clients connect to in order to submit Telemetry, Health Report, and Crash Reporter data because I’ve disabled them all for privacy reasons, but I would not be surprised if those servers also failed to enable forward-secret TLS 1.2.  All of the above weaknesses in Mozilla server crypto configurations are potentially concerning from a security/privacy perspective because those servers receive potentially sensitive information about Firefox client configurations, usage habits, add-ons, etc. that could be leaked or subverted via certain attacks.  With that in mind, Julien Vehent and team at Mozilla should be recognized for doing better than most to improve server-side cryptography.

But Mozilla would also be well-advised to prioritize enabling (if not requiring by default) TLS 1.2–which is now more than five years old–on Mozilla servers that Mozilla software clients capable of supporting TLS 1.2 all depend on for core updating functionality before bragging about their TLS 1.2 implementation to users.

Advertisements
Standard