Opened 7 years ago

Last modified 2 years ago

#7151 new defect

SSL Observatory not using Tor when FoxyProxy is enabled

Reported by: cypherpunks Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version: HTTPS-E 4.0dev1
Severity: Normal Keywords:
Cc: mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When FoxyProxy is enabled, and the SSL Observatory is enabled and set to use Tor, access to the Observatory seems to use FoxyProxy's rules instead of going through Tor, without HTTPS Everywhere noticing.

A workaround is to add the Tor proxy to FoxyProxy and a rule to use that for access to observatory.eff.org, but that will only work while in FoxyProxy's default mode.

If there's no way for HTTPS Everywhere to override FoxyProxy, then maybe it should at least test that access through Tor actually works as intended before submitting certificates.

Child Tickets

Change History (5)

comment:1 in reply to:  description ; Changed 7 years ago by gk

Replying to cypherpunks:

A workaround is to add the Tor proxy to FoxyProxy and a rule to use that for access to observatory.eff.org, but that will only work while in FoxyProxy's default mode.

You probably mean FoxyProxy's pattern mode, right?

If there's no way for HTTPS Everywhere to override FoxyProxy,

No, there is no such way to do that reliably as long as FoxyProxy is activated.

comment:2 in reply to:  1 Changed 7 years ago by pde

Cc: mikeperry added

Replying to gk:

No, there is no such way to do that reliably as long as FoxyProxy is activated.

I don't know anything about how FoxyProxy works, but the relevant places investigate if it was possible would be in this function or if that fails, a layer out in our applyFilter implementation.

comment:3 Changed 7 years ago by mikeperry

Use of FoxyProxy is also strongly discouraged by the Tor Project for reasons like this, and many many other potential info leaks.

FoxyProxy uses the same API that HTTPS-Everywhere does to decide which proxy to use. If FoxyProxy's callback happens to get called after ours, it overrides our proxy settings choices. In fact, it's quite possible that depending on various aspects of browser state, sometimes FoxyProxy may override HTTPS-Everywhere, and sometimes we may override FoxyProxy.

However, if someone wants to deep-dive into this madness, we *do* have checks to see if the Tor socks proxy is functional. We do this before asking the user if they would like to use Tor. See https://gitweb.torproject.org/https-everywhere.git/blob/3.0.2:/src/components/ssl-observatory.js#l683 and usages of this.proxy_test_successful.

Testing every time we submit a cert is excessive, though. Check.tp.o is already experiencing high load volumes.

comment:4 in reply to:  3 Changed 7 years ago by gk

Replying to mikeperry:

However, if someone wants to deep-dive into this madness, we *do* have checks to see if the Tor socks proxy is functional. We do this before asking the user if they would like to use Tor. See https://gitweb.torproject.org/https-everywhere.git/blob/3.0.2:/src/components/ssl-observatory.js#l683 and usages of this.proxy_test_successful.

Testing every time we submit a cert is excessive, though. Check.tp.o is already experiencing high load volumes.

How should checking whether the SOCKS proxy is functional help if FoxyProxy overrides HTTPS-E's decision which proxy to use? Deep-diving does not help IMO, just disabling FoxyProxy does.

comment:5 Changed 2 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.