381006 - external protocol handlers and privacy

Status: RESOLVED INVALID

(Firefox :: Shell Integration, defect)

Description

[georgi - hopefully not receiving bugspam]

external protocol handlers and privacy

some people are trying to hide their ip address when browsing.
a poor man solution is tor (tor.eff.org) and http proxy on localhost.

most of the traffic is tunneled via tor.

external protocols reveal the ip:
sftp://server
<img src="sftp://server">

how to reproduce:
configure tor and http proxy, set proxy.
start
tcpdump 'host server'
visit a page containing <img src="sftp://server">
tcpdump shows connection to 'server' which means that the traffic is not
tunneled via tor.

trunk gives security error.

Comment 1

[Daniel Veditz [:dveditz]]

If you were really paranoid it's certainly possible to set up all your networking apps to go through tor, but if those apps are making independent networking connections I'm not sure what we're supposed to do about it. By default all external protocol handlers should be blocked and present a dialog before launching (except mailto, which doesn't immediately cause a network connection anyway). Don't blanket-allow them if you're trying to cloak.

There's an old bug about not allowing external handlers in contexts like IMG and IFRAME where we won't get any useful data anyway, perhaps that was fixed on the trunk (I'll check later).

More problematic is plugin/applet content -- Java in particular is scriptable and can make raw socket connections on its own. Same Origin, sure, but presumably it's the page serving up this content that's trying to see who you really are anyway.

Comment 2

[georgi - hopefully not receiving bugspam]

applets are known to leak privacy - the tor page mentions them iirc.

so if i am really paranoid and wished to use firefox for privacy would like an option: don't start any external app without asking.

sure, being anonymous at network level is better (proxying all ip stuff at the anonimizing router or botnet), but the tor page still recommends starting tor and the http proxy on |localhost| iirc

Comment 3

[georgi - hopefully not receiving bugspam]

using |tsocks| partially solves the problem.

ssh is socksified, but tor warns about leaking dns queries.

|tsocks| probably will solve the applet problems short of dns stuff.

Comment 4

[georgi - hopefully not receiving bugspam]

(In reply to comment #1)
> (except mailto, which doesn't immediately cause a network
> connection anyway). 

not sure this is entirely correct.

html enabled mail clients may load <img src=""> while composing. not sure.

Comment 5

[georgi - hopefully not receiving bugspam]

this is somewhat related to Bug 381146

Comment 6

[Daniel Veditz [:dveditz]]

I'm not sure you can use anything other than plain text in a mailto, but worth checking.

There are already feature requests to disable applets/plugins/objects, generally on a per-site basis (or rather, globally off with the ability to selectively enable) as requested in comment 2. Since we have that bug already and they aren't "protocol handlers" as in the summary of this bug let's leave that separate.

Other than mailto: what external protocol handlers do you have that are making connections without asking you first?

Comment 7

[georgi - hopefully not receiving bugspam]

(In reply to comment #6)
> I'm not sure you can use anything other than plain text in a mailto, but worth
> checking.
> 
> There are already feature requests to disable applets/plugins/objects,

sounds like the noscript extension

> 
> Other than mailto: what external protocol handlers do you have that are making
> connections without asking you first?
> 

hm, so far on linux just sftp. i am also interested in a complete list of invokable protocols.

will try macosx one of these days.

mailto: seems to use html just in seamonkey according to tests so far.

Comment 8

[georgi - hopefully not receiving bugspam]

on macosx telnet protocol gives semi scary warning about weakness in external application and this seems reasonable.

Comment 9

[georgi - hopefully not receiving bugspam]

on macosx |help| protocol behaves strangely - no error about unrecognized protocol, no visible effects.

safari opens help window.

Comment 10

[georgi - hopefully not receiving bugspam]

[sg:low?] privacy?

Comment 11

[Jesse Ruderman]

This sounds like something for the Tor proxy or Torbutton to solve.