[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Downloading attachments with Tor - is this secure?



Scott Bennett writes:

>      While HTTPS-Everywhere may be a nice programming exercise for its
> author(s), it appears wholly unnecessary for Firefox users because Firefox
> users should *ALREADY* be using NoScript, which allows one to accomplish
> the same thing, but also provides mountains of other protective measures.
> Don't be fooled into thinking that HTTPS-Everywhere can protect your
> anonymity or your privacy.  If you and/or the OP continue to refuse to
> use NoScript, then sooner or later you and/or the OP will get burned and
> will thus be taught the hard way the lesson you should have understood by
> now.

NoScript provides important protections for Firefox users that HTTPS
Everywhere doesn't, but there are two kinds of gaps where HTTPS
Everywhere provides functionality that NoScript doesn't.  (HTTPS
Everywhere is also partly based on code from NoScript.)

(1) HTTPS Everywhere bundles a specific, and growing, list of sites
that support HTTPS, so you don't (necessarily) have to find those
sites yourself.

(2) NoScript only supports using HTTPS for an entire domain, but we
have several examples where sites support HTTPS only on parts of
the site, or even using a different hostname, requiring a more
specific translation rule and not just a hostname list.

For example, the Google support in the current HTTPS Everywhere
tree is currently _fifteen_ different substitution rules, and we
are already aware of several parts of Google's services that it
still handles slightly incorrectly and that will require additional
rules and exclusions.

Just adding "www.google.com" to your NoScript configuration will
provide quite a bit less correct functionality; to use a simple
example, Google Language Tools currently breaks if you try to access
it in HTTPS.  Google has also suggested that they may move HTTPS
support off of www.google.com entirely in order to help schools censor
access to Google services; if they do that, there will be an even more
conspicuous need for HTTPS Everywhere to rewrite URLs beginning with
"http://www.google.com/"; to something like "https://secure.google.com/";
or "https://ssl.google.com/";.

In fact, we already have a similar case with Wikimedia services,
where the rewrite rules understand things like

http://pt.wikipedia.org/wiki/Tiradentes

--> https://secure.wikimedia.org/wikipedia/pt/wiki/Tiradentes

http://la.wikisource.org/wiki/Carmina_(Catullus)/1

--> https://secure.wikimedia.org/wikisource/la/wiki/Carmina_(Catullus)/1

Again, NoScript currently can't do that kind of substitution.  If
you tried to force HTTPS access on, say, en.wikipedia.org, it would
just break because there is no HTTPS support on that host.

On the other hand, some users might definitely prioritize
confidentiality over availability and argue that the browser
should never load an HTTP resource from an HTTPS page (which I
understand was actually a common browser default in the past).
This policy would break some functionality on some pages, like
preventing certain images from displaying.  Some users might
think that's an appropriate trade-off because of the risks of
unencrypted access.  Currently HTTPS Everywhere doesn't include
any rules which deliberately do this when it would break some of
the page's functionality.  It's possible to implement that
behavior on your own machine with either NoScript or HTTPS
Everywhere if you know all of the relevant domain names (for
example, for Wikimedia you might block access to
"http://upload.wikimedia.org/";).

For Tor users, HTTPS Everywhere particularly provides protection
against exit node operators and their ISPs, while NoScript
particularly provides protection against sites trying to
recognize or track users.  (Of course, NoScript is also helpful
for defending against other kinds of threats.)  In this sense,
the protections provided by the two programs can be complementary.

-- 
Seth Schoen
Senior Staff Technologist                         schoen@xxxxxxx
Electronic Frontier Foundation                    https://www.eff.org/
454 Shotwell Street, San Francisco, CA  94110     +1 415 436 9333 x107
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/