Firefox 24.1.1 HSTS network.stricttransportsecurity.preloadlist

Since I haven’t seen it posted anywhere else, I thought some might find it useful to post the list of embedded URLs Firefox 24.1.1 includes for HSTS.  I found these URLs on my own machine by following these instructions (for OSX users):
1. Ideally with Firefox closed, open /Applications/ in SynalyzeIt or your favorite hex editor
2. Apply the encoding SynalyzeIt or your favorite hex editor proposes (ISO_8859-1:1987 in my case)
3. Search for network.stricttransportsecurity.preloadlist

The list of URLs that immediately follows after the text “https:// sts/use sts/subd includesubdomains test.currentTimeOffsetSeconds”:

An eclectic mix, no? Among the interesting omissions from this list that might surprise some users:
CDNs like Akamai, AWS


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:

  •, which according to a Qualys SSL handshake simulation test run on November 19th is not forward secret and does not mitigate BEAST attacks
  •, 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
  • 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.


Does Safari on OS X Mavericks Ignore Browsing History Preferences?

Bad Privacy Behavior on OS X Mavericks 10.9 with Safari Version 7.0 (9537.71)

I wanted to document some troubling behavior I recently noticed with Safari Version 7.0 (9537.71) shortly after upgrading OS X 10.9 Mavericks.

To limit advertiser tracking, I usually only ever use Safari in its Private Browsing Mode (Safari—>Private Browsing), and regularly Reset Safari (Safari—>Reset Safari…) in order to “Remove All Website Data…” in the middle of browsing sessions with Safari.

I also enable all the privacy-enhancing settings I can find in web browsers, which in the case of Safari Version 7.0 included the following settings in Safari’s Privacy tab of the Preferences menu:
– Selecting the “Ask websites not to track me” checkbox
– Selecting the “From third parties and advertisers” checkbox from the “Block cookies and other website data” options
– Selecting the “Do not preload Top Hit in the background” and “Prevent search engine from providing suggestions” checkboxes from the “Smart Search Field” options.
I also use two extensions with Safari–AdBlock Plus and Disconnect–but these behaviors occur with extensions disabled, too.

Persistent Local Storage

I’ve noticed that Safari often appears to re-spawn (or mysteriously fails to delete) local storage for many websites when using Safari’s Private Browsing and/or the Reset Safari features and then re-opening Safari. So it’s frustrating enough that Safari’s “Reset Safari” feature—which is presented to users as an opportunity to “Remove All Website Data…”—does not actually remove all website data unless you repeat the process at least twice in some cases for Local Storage.

But the problem I noticed with the most recent version of Safari is even more frustrating from a privacy standpoint.  To verify that Safari has actually deleted my cookies as the GUI suggests, I sometimes check my ~/Library/Cookies folder where Safari and other applications store cookies in files with names like, Cookies.binarycookies, and a file I had never seen before called HSTS.plist.  

A quick Google search revealed very little pertaining to this particular HSTS.plist file, but HSTS may stand for HTTP Strict Transport Security, a web standard that allows web servers to mandate browsers interact with it using only HTTPS connections.  I was surprised to see my previous (as in pre-Mavericks) browsing history comprised of over 100 sites I had visited within the past few months listed in this ~/Library/Cookies/HSTS.plist file.

HSTS.plist Structure

Opening my ~/Library/Cookies/HSTS.plist file in TextWrangler revealed the following structure:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “”&gt;
<plist version=”1.0″>
<key>HSTS Content Version</key>
<key>HSTS Store Schema Version</key>

 <… and so on, with “real” values of either infinity or -infinity ..>

<key>hstsd Disk Storage Schema Version</key>

Perhaps oddly, I also found no search results when I searched Google for “hstsd Disk Storage Schema Version”.

This ~/Library/Cookies/HSTS.plist file contained browsing history that I apparently had no way of permanently deleting, and which could potentially be used as a fingerprint for tracking (if accessible via WebKit) by Apple or others. Another thing that amazed me was that this file persisted in the sense that the HSTS.plist file and its original contents were replaced within a few minutes—perhaps via iCloud syncing…even though this machine did not have iCloud or any “Internet Accounts” enabled—even after multiple iterations of disabling all plug-ins, “Reset Safari..”, toggling “Private Browsing” on and off, and restarting the machine plus all of the following:

– Closing Safari and other applications, deleting the HSTS.plist file, restarting
– Closing Safari and other applications, deleting the re-spawned HSTS.plist file, saving a blank text file to ~/Library/Cookies/HSTS.plist, making its permissions read-only and myself owner, and then restarting
– Logging in with another user’s account (with Administrator rights), deleting the HSTS.plist file, and restarting
– Logging in with another user’s account (with Administrator rights), deleting the HSTS.plist file, saving a blank file with the same filename in that file’s location, setting its permission to read-only with another user as the owner, and then restarting

Using fseventer, I was able to see that this HSTS.plist file (and the browsing history it contained) re-spawning behavior occurred whenever I opened Safari and toggled Private Browsing mode. At least on this machine, HSTS.plist never re-spawns itself unless I’m connected to the internet.

This leaves me puzzled, so I would appreciate any reactions or responses you may have in the comments.  Could this be:
– malware?  This seems less likely, since a scan of the hard drive in safe mode with clamXav turned up clean.
– an artifact of a previous non-standard configuration?  Perhaps this behavior is somehow related to something like Safari Mobile Bookmarks Sync (which I had disabled), or some sort of upgrade hiccup associated with upgrading a fully-patched copy of OS X Mountain Lion 10.8.5 to OS X Mavericks 10.9 a few days prior?
– a potential new cookie-like vector that Apple and/or advertisers could potentially use to fingerprint users via a snapshot of their HTTPS browsing history, even when using Safari’s Private Browsing mode?  This would be an outrage.
– a new “feature” associated with Safari’s implementation of HSTS?  Given the potential privacy implications, this would also be an outrage.

Aside from completely wiping the machine and reinstalling everything from scratch, I’m not sure what to do to get this artifact of old browsing history off of my machine. Even if this ~/Library/Cookies/HSTS.plist is just a simple cache of HSTS-enabled websites visited, it’s highly undesirable because it leaks browsing history–even in Private Browsing mode, and even across the GUI-accessible history and cache-clearing functions–and appears to be a highly persistent potential vector for fingerprinting users.


Ghostery is Malware: A Story of Censored Firefox Extension Ratings

About two months ago, I had created a Mozilla Extension Ratings account (with username extensionratings) and submitted the Firefox Extension Rating for Ghostery below.  My constructive but critical review was quickly censored from being visible on Ghostery’s review page–I’m not sure if it was by Mozilla or Ghostery at this point. But since the link to the review itself still worked (but wasn’t visible to others without knowing the URL), I decided to create a Twitter account with username GhosteryCritic that was later suspended by Twitter–perhaps because I had mentioned too many other users in flagging my review to Mozilla, Ghostery, Evidon, and others.  Unfortunately the e-mail server needed to reset my Twitter account has since stopped operating, and the only remaining evidence of that Twitter account is a single tweet from one of the blogs that had (incorrectly, in my opinion) touted the potential privacy benefits of Ghostery.  After contacting the Mozilla team about what its (or Ghostery’s) censorship of critical reviews using their forms, Mozilla deleted my account and along with it, the review that–despite being censored from the view of other users in less than an hour–was also removed from its original URL at Ghostery deleted the same review (and my user account on their support site) after I posted the same feedback (below) to there for clarification.  There are several take-aways from this experience:

  • Mozilla censors negative but constructive add-on ratings, potentially with developer input
  • Ghostery ignores constructive criticism and censors critical questions on its own forum

In both cases, this completely contradicts the corporate culture (and in the case of Mozilla, operating model) that these two organizations purport to espouse.  Keeping in mind that my original review was written in July and applies to an earlier version of Ghostery, I wanted to share the full text:

After reading some mixed reviews and after using this extension for a while myself, I decided to do some digging around “under the hood” even though I’ve never used Ghostery’s GhostRank “feature,” which shares your browsing history with the company. I concluded that this add-on is a total scam, and doesn’t block tracking by Facebook, Google, and others–even when its notifications suggest otherwise.

For example, Ghostery version 2.9.6 is hard-coded to re-inject Facebook tracking scripts even when it doesn’t show related Facebook script content. You can see this for yourself in lines 101-119 after opening a file called ghostery.js in the subdirectory named /extensions/ of your Firefox profile folder.

This is in addition to the various “surrogate scripts” that Ghostery claims aren’t related to tracking (but *would* easily still track you if an ad-tracking company had any sense, since they explicitly connect you to 3rd-party sites). You can see this list for yourself in the /extensions/ file (open with text editor) of your Firefox profile folder.

Ghostery also gives your info to Google by explicitly white-listing Google’s domain, which you can also verify in a text editor with lines 159 and 160 of the ghostery-content-policy.js file found in the extensions/ subdirectory of your Firefox profile folder.

Ghostery’s use of the OpenSans-Bold font installed with the extension in your Firefox profile folder’s /extensions/ subdirectory can be used to fingerprint browsers, further decreasing user privacy. For more on these privacy compromises, see EFF’s Pantopiclick project.

You can see a list of the many sites where Ghostery doesn’t actually block scripts for “compatibility” reasons (i.e. corporate partners paid them off) by opening the file called ghostery-compatibility.json from your Firefox profile’s extensions/ subdirectory.

This extension deceives users into thinking that they’re not being tracked by ad companies when GhostRank is disabled. My own experience with Ghostery, however, suggests that this is not the case. Barring a detailed and thorough explanation of the above from the developer, I wouldn’t touch this extension with a ten-foot pole.