[tor-talk] 1PassWord Firefox extension

[Mike Perry]

Graham & Heather Harrison:

> I am very new to Tor - just getting set up. I want to use 1Password as
> my password manager. I have been with them since they started and
> trust them more than any other similar application. The copy of their
> latest response on why 1P does not work with Tor is below. (I had
> originally only told them I was having problems with Ff 38.) I want
> information on whether it is possible to make 1P work without
> compromising Tor.

Kudos to the 1Password team. This is a surprisingly informative and
thoughtful response they gave you. I will clarify a couple points below.

There are actually some things they can do, though. Feel free to forward
my comments to the 1Password people.

Also, note that I have not tested 1Password or reviewed its code. Only
the nature of their response led me to believe they were capable of
taking Tor Browser's threat model into consideration, and were unlikely
to deliberately violate it. This might not rule out accidental
violations, though.

> OS X 10.6.8 and 10.10.3
> 
> The reason you can't use 1Password's extension inside Tor has to do
> with the modifications that TorProject makes to Firefox. They go to
> significant lengths to prevent information from being leaked (or able
> to be spied-upon) in non-Tor channels that might reveal your true IP
> address. This includes things like DNS leakage, but it also includes
> web sockets, which is what 1Password uses to communicate between the
> Mini (in your menubar) and the extension in Firefox. This requires
> that there not be anything blocking 127.0.0.1. 
> 
> As with most proxy/firewall software that customers add to their
> computers to increase security, we can tell them to add an exception
> to the whitelist for localhost (127.0.0.1), but in the case of Tor, I
> just don't know enough about the internals of how it goes about
> blocking things it deems potentially harmful to know whether adding an
> exception for 127.0.0.1 would be considered voiding the protection
> offered by Tor. The Tor proxy itself is contained on 127.0.0.1, port
> 9051, so bypassing for localhost might inadvertently induce a whole
> host of other, non-1Password applications/utilities/helper programs to
> pass information outside of the Tor channels, potentially exposing
> your real IP address. I just don't know. In my own testing just now, i
> can confirm that adding 127.0.0.1 to Tor's Preferences => Advanced =>
> Network Settings does indeed allow the 1Password extension to
> work...but at what cost to the anonymity afforded by Tor, I have no
> idea. You may wish to take this up with the To r devs themselves, or
> with someone who knows the internals of Tor better than me.

The specific cost is that you then allow websites to also attempt to
connect to these ports on your computer, which can be used to
fingerprint you. See for example
http://www.andlabs.org/tools/jsrecon.html and the specific item "Open
TCP Port and Local Network Fingerprinting" in the fingerprinting section
of the Tor Browser Design documentation:
https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability
(sorry, you will have to search for that "Open TCP Port and Local
Network Fingerprinting" text, we don't have a direct anchor to it).

I have observed banks attempting to fingerprint users upon login with
various forms of this local port scanning technique, which prompted us
to remove 127.0.0.1 from the destinations allowed to bypass the proxy.

> I'd also point out that this isn't going to be a "solvable" issue from
> our end. The 1Password extension needs to communicate with the Mini,
> and that's true across all browsers on the Mac (Safari, Chrome,
> Firefox, Opera), and that's not going to be changing. To the extent
> that this conflicts with Tor, that's going to be permanent
> unless/until Tor itself allows for local extensions to communicate via
> web socket. In short: I can't recommend you take these steps unless
> you do so with the explicit understanding that we don't warrant what
> effect doing so might have on the efficacy of Tor itself. The effect
> *might* be zero...or it might be significant indeed. Taking this step
> will indeed allow the 1Password browser extension to work in Tor's
> version of Firefox 38...but at what cost, we don't know, so this is an
> at-your-own-risk modification.

Actually, since 1Password is an addon, they can technically exempt their
specific requests from the proxy settings and allow only themselves to
connect directly to their specific port on 127.0.0.1, without allowing
websites to do the same. One way to do this is to create a low-level
XPCOM socket instead of a websocket. Another way is to use
nsIProtocolProxyService to disable proxy settings for this specific
request. Both of these approaches are possible from addon Javascript.

The XPCOM socket will bypass proxy settings straight-up, but it is
somewhat complicated to construct and very hairy to use. It may also
be removed in the transition away from XPCOM. I think it may be best
avoided in favor of nsIProtocolProxyService.

However, one downside of nsIProtocolProxyService is that it is hard to
tell the origin of the request, to ensure that it came from 1Password
and not some website trying to fingerprinting you to determine if you
have 1Password installed.

In the past, in HTTPS-Everywhere, we have used the hack of creating
special anchor-tag nonces appended to requests when we needed to do this
(ex: for the SSL observatory, to ensure those requests go over Tor if it
is present, but not configured).  Recently, however, we just landed a
new API that gives you access to the nsIChannel of the request, allowing
you to inspect it more thoroughly to ensure that it is yours.

Here's code examples of this, in case the 1Password team is curious.

The old way:
https://gitweb.torproject.org/https-everywhere.git/tree/src/components/ssl-observatory.js#n114

The new way:
https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isolator.js#n40

Unfortunately, Mozilla has not yet updated the nsIProtocolProxyService
documentation (at
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolProxyService)
to describe the new channel-based filter.

Here's where we landed the patch for the new API, though:
https://bugzilla.mozilla.org/show_bug.cgi?id=436344



-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20150828/8cd9feb0/attachment-0001.sig>