[HTTPS-Everywhere] Two fairly serious leaks

Seth David Schoen schoen at eff.org
Tue Jul 6 23:56:40 PDT 2010


... found with Wireshark this evening.

(1) Firefox search bar completions.

If you type anything into the Firefox search bar (to the right of
the address bar), Firefox tries to look it up using the URLs
specified in the files referenced in $profile/search.json

e.g. /usr/lib/firefox-3.5.9/distribution/searchplugins/en-US/google.xml
for Firefox 3.5.9 on Ubuntu defines

http://suggestqueries.google.com/complete/search?output=firefox&client=firefox&hl={moz:locale}&q={searchTerms}

and /usr/lib/firefox-3.5.9/distribution/searchplugins/en-US/wikipedia.xml
defines something like

http://en.wikipedia.org/w/api.php&action=opensearch&search={searchTerms}

For some reason, HTTPS Everywhere rules that match these URLs seem
not to be able to force the search into HTTPS (or even to change
which host is being queried!?), but they apparently can change the
path within the URL (!?!?!?).  For instance the rule

<rule from="^http://en.wikipedia.org/w/api.php" to="https://nowhere.example.com/my-rewrite-rule-doesnt-work.php"/>

appears to cause a Wikipedia search bar entry for [this is weird] to
generate a request to

http://en.wikipedia.org/my-rewrite-rule-doesnt-work.php?action=opensearch&search=this+is+weird

which is weird.  Also, it's unencrypted. :-(

(Note: I'm talking about the typeahead suggestions, not about the
results of actually performing the search.  As far as I can tell,
actually doing the search seems to be OK in that HTTPS Everywhere
will correctly rewrite the URL before it is requested.)

(2) HTTP Prefetch.

If you search for anything at all on Google via the search bar -- though
maybe not by other means -- the returned page will contain HTML like

<link rel=prefetch href="http://en.wikipedia.org/wiki/QWERTY">

where the href attribute contains the URL of the first hit.  Firefox
will _automatically retrieve this URL in the background_; what's more,
_HTTPS Everywhere rewrite rules that would have applied to it will
be ignored_.  For example, if I manually navigate to
http://en.wikipedia.org/wiki/QWERTY or go there by following
the Google link to that page, I get
https://secure.wikimedia.org/wikipedia/en/wiki/QWERTY, as I expect.
But if I look with Wireshark, it turns out that my browser has
also requested http://en.wikipedia.org/wiki/QWERTY in the clear,
even before I clicked on anything.

See

https://developer.mozilla.org/en/link_prefetching_faq

which says that we can turn off this behavior with

user_pref("network.prefetch-next", false);

but adds

  that if link prefetching needs to be disabled then there must be
  something wrong with the implementation. We would rather improve the
  implementation if it does not work correctly, than expect users to
  locate and tweak some obscure preference.

(That FAQ seems not to have anticipated our threat model at all...)

-- 
Seth Schoen
Senior Staff Technologist                         schoen at eff.org
Electronic Frontier Foundation                    https://www.eff.org/
454 Shotwell Street, San Francisco, CA  94110     +1 415 436 9333 x107



More information about the HTTPS-everywhere mailing list