Stop connecting to check.torproject.org on every browser startup

[crisalis]

Or at least offer the possibility to disable this checkup and assume the browser isn't (or is) using tor.
This is phoning home and that doesn't make sense for a privacy extension.

[fuglede]

I never looked at the SSL Observatory in any great detail but this might be as simple as adding

if (!this.myGetBoolPref("enabled"))

to https://github.com/EFForg/https-everywhere/blob/master/src/components/ssl-observatory.js#L130.

[DerekTurtleRoe]

@fuglede I thought Tor was checked for some reason to establish certain compatibility settings?

[fuglede]

@vgturtle127: Proxy settings to be precise (at least if we are talking about the same part of the code).

[rugk]

But these proxy settings should only be checked when the proxy settings are actually configured, shouldn't they?

[jsha]

@Hainish, can you take a look at this one?

[Bisaloo]

Any update on this? This is still an issue in the latest version of https-everywhere.

[Hainish]

This is high on my priority list, I'll look into it next week.

[Hainish]

I'm not overly concerned with requests to check.torproject.org that are actually going over Tor. In that case, we can expect privacy to be reasonably assured. This may not always be the case: if for instance we are accessing Tor via a system proxy, the XMLHttpRequest may be sending out identifying headers. But let's set aside that concern for a moment.

Following the logic of getProxySettings, we should not be making requests to check.torproject.org without the use of Tor under normal circumstances. Following the line-by-line breakdown:

L832: We are using the Tor Browser and extensions.https_everywhere._observatory.use_tor_proxy is set to true. (request will be made over tor settings set in the tor browser)
L852: We are using a custom proxy set by the user (request will not be made over Tor) or we have a direct connection but we're not running the check test (not relevant for this issue)
L857 Otherwise (request will be attempted with a system-wide installation of Tor running on 9050)

The only one of these three that results in the request not going over Tor in normal circumstances is the middle conditional. In that case, most users are protected because it's rare that users will manually set an observatory proxy in about:config. This may however be a concern for more advanced users. For such cases, I'll open a pull request to ensure that the Tor check is not performed over a custom set proxy.

While investigating this issue I was concerned about DNS leaks. I ran a packet dump and fired up a clean HTTPS Everywhere profile (the startup sequence of which would reach the 'otherwise' conditional above, trying to make the request over socks localhost:9050) but observed no DNS requests being made to check.torproject.org.

[Hainish]

Looking at it now, within Tor Browser seems like we never actually succeed with the first conditional, because the testProxySettings is called while the Tor circuit is still being built. We should fix this, possibly with a callback upon the main window being drawn.

[Hainish]

Strikingly, the above has probably been an issue since the days of Torbutton.

[gunesacar]

Does HTTPS Everywhere still connect to check.tpo even when the SSL Observatory is disabled?

If relevant, I'm asking in the context of Tor Browser.

I understand this is not a privacy issue if it goes through Tor, but would be nice to avoid if it's unneeded. Sorry if this is already the case, but couldn't make sure reading the code.

[Hainish]

@gunesacar in Tor Browser, Tor connectivity will be tested (even if the observatory is disabled) by connecting to check.tpo. This is in order to provide the appropriate UX for observatory settings.

[gunesacar]

@Hainish Thanks!

[davidjb]

Is this still an issue? Looking at uBlock Origin's I'm seeing behind-the-scene requests are requests going to https://check.torproject.org/?TorButton=true#[ID snip]. I've configured uBlock to block this; but prior to that there were 2 XHR requests to that URL; a minute apart after turning my computer on this morning.

There's no assurance that HTTPS Everywhere is making this request (because uBlock Origin doesn't know who did), but it's the only addon I have related to Tor. I'm running HTTPS Everywhere 5.2.8 with SSL Observatory disabled in regular Firefox 50.1.

[ddraws]

I'm on Nightly 55, SSL Observatory disabled, same issue.

[Hainish]

Thanks for the notifications, this was fixed in #10028 and will be deployed in 5.2.18.