[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