Opened 7 years ago

Last modified 23 months ago

#7179 new defect

Ths SSL Observatory feature leaks DNS requests without the TBB

Reported by: gk Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: intrigeri@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

HTTPS-Everywhere is leaking DNS requests no matter whether I use Tor or not (but note that the TBB is not affected. See below for the reason). All tests were made in a clean new profile with FF 16.0.1 and HTTPS-E 3.0.2 installed.

The reason is that

Ci.nsIProxyInfo.TRANSPARENT_PROXY_RESOLVES_HOST

is _not_ enough to be sure to not leak DNS requests if you build your proxy settings manually and using applyFilter(). This is actually a Mozilla (Necko) bug documented here:

https://bugzilla.mozilla.org/show_bug.cgi?id=536093

The only workaround I am currently aware of is setting "network.dns.disablePrefetch" to |true|, a thing which is done in the TBB. Then there are no requests leaking.

Child Tickets

TicketStatusOwnerSummaryComponent
#8675closedpdeUnnecessary connection to check.torproject.orgHTTPS Everywhere/EFF-HTTPS Everywhere

Change History (10)

comment:1 Changed 7 years ago by pde

This is Extremely Annoying. We don't really want to inflict this performance hit on the whole browser in order to achieve confidentiality for DNS requests for a single domain :(. If we could only get this API to exist we could submit to the Observatory's IP address while verifying the server has a cert for observatory.eff.org.

comment:2 Changed 7 years ago by pde

I wonder if we could manually whitelist the observatory.eff.org end-entity cert as trusted for that IP address. The same way that the browser would do it if you clicked through the cert warning. That would be terrible, and we'd probably have to ship the IP address as a constant value in the extension, hampering our operational flexibility, but it would work.

comment:3 Changed 7 years ago by pde

Hrm. In a less hacky direction, we should also look at the patch which closed this ticket. The existence of per-domain functionality like this makes me hopeful that there could be a way to disable this for a single domain.

comment:4 Changed 7 years ago by mikeperry

A PAC approach sounds plausible (if you can actually create PAC rules from addons), but I don't think the x-prefetch-control header/meta will work for the cert submission case, as it's just a single AJAX call and that header appears to be a response header...

Though note we have always wanted IP-based fetches to actually make use of the observatory exit enclave for stream isolation, and this lack of isolation is the main reason why we disable the observatory and its popup. In TBB we should still be able to achieve this isolation by patching it so that we can send a unique SOCKS username+password for the observatory request (thus using the tor 0.2.3.x stream isolation support), but for non-TBB tor users, they're sort of screwed without the enclave unless *all* their other apps support isolation... As to if this is more serious than fixing the DNS leak as quickly and cleanly as possible, I'm not sure. Maybe it's not.

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

Replying to mikeperry:

A PAC approach sounds plausible

Yes, but be aware that there are fun bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=468868. Dunno, if you get away with setting the TRANSPARENT_PROXY_RESOLVES_HOST flag as this is strictly speaking not touching the preference in question. And watch still out for DNS leaks. I found plenty of them recently in certain circumstances if a PAC file is used specifying a SOCKS proxy. Affected Firefox versions are all up to and including 17. These leaks are not reproducible in FF 18 anymore, I guess due to https://bugzilla.mozilla.org/show_bug.cgi?id=769764 and its fallout.

(if you can actually create PAC rules from addons)

Should not be a problem although it might be tricky to constrain the usage of that PAC rules just to single requests assuming the user has content loaded into some tabs...

comment:6 Changed 7 years ago by pde

Cc: intrigeri@… added

Marking #8675 as a dupe of this bug and importing watchers.

comment:7 Changed 7 years ago by pde

This bug is marked "critical". A few points about this:

  • the leak only occurs when the user runs tor (or maybe jondo too?)
  • the serves to indicate that the user is running tor + https everywhere
  • that's not terrible for most tor users, but maybe it's actually Bad™ if you're using a bridge?

If the latter is true we should actually push through one of those ugly fixes.

comment:8 in reply to:  7 Changed 7 years ago by gk

Replying to pde:

This bug is marked "critical". A few points about this:

  • the leak only occurs when the user runs tor (or maybe jondo too?)

JonDo is not affected as it is usually configured as an HTTP proxy if combined with Firefox (or any other web browser).

comment:9 Changed 5 years ago by jsha

Priority: criticalnormal

I'm downgrading priority on this to normal. Please speak up if you think that's incorrect. I agree with pde's analysis. We're leaking the fact that the user is using tor + https everywhere, but both of those facts can already be discovered based on network traffic. We'd still like to fix this but I don't think it's critical.

comment:10 Changed 23 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.