Hello,
I've been working on a dumb hack that lets me do things like this: https://imgur.com/3mah244 (Yes, that's a single Tor Browser instance, separate windows used for illustrative purposes.)
It's still very raw and doesn't do everything I want it to do, so I'm not really releasing the code yet, but I have some questions regarding how Tor Browser behaves when setting the SOCKS username for isolation purposes.
Ideally I want my shim to enforce isolation between the various upstreams (Tor, I2P, whatever) correctly to avoid cross-protocol probing (and to shield the I2P administration interface from eeevil websites).
This appears to be straight forward if the application is Tor Browser because IsolateSOCKSAuth is always used at first glance (I will assume for now that if users decide to use things like torsocks that do not use isolation this way that they know what they are doing).
My question is, what causes Tor Browser to set the SOCKS username to "--unknown--" and what the behavior should be in that case if:
* The destination is a ".onion" address.
* The destination is a ".i2p" address.
* The destination is the I2P management console.
I'm fairly sure this should be "deny".
* The destination is any other address (will be dispatched over Tor if running, I don't think I will attempt to support I2P outproxies because they suck). (I think allow because things break otherwise?)
For destinations that are ".onion"/".i2p", I plan to be fairly strict about making sure the SOCKS5 target and the username matches (I need to be more relaxed for sites on the regular intertubes since cross-site resources are loaded (I may make this behavior configurable...). Is this dumb? Is it common for "foo.onion" to load resources off "bar.onion"? How about in I2P land?
The final form of my shim will support running with any combination of "nothing" (Tor Browser just for the "privacy benefits", probably unsafe, I may reconsider this), I2P, and Tor (Though the most useful configuration is probably I2P + Tor).
Thanks in advance,
Yawning Angel:
[snip]
My question is, what causes Tor Browser to set the SOCKS username to "--unknown--" and what the behavior should be in that case if:
Ideally, "--unknown--" would only be used for requests originating from privileged browser code and not belonging to a website/resource a user requested. This would encompass things like extensions update requests, browser update requests, blocklist checks, requests issued by installed extensions to name just a few. In reality, however, we are not there yet (see e.g. #13670, #15599, #15555, #15569 + plus there is at least one bug I have not filed yet).
- The destination is a ".onion" address.
#15499 should give you an idea (although I am not sure whether that ticket is still valid)
- The destination is a ".i2p" address.
I don't know. Maybe we/you should coordinate that with the I2P folks?
The destination is the I2P management console.
I'm fairly sure this should be "deny".
Sounds good.
- The destination is any other address (will be dispatched over Tor if running, I don't think I will attempt to support I2P outproxies because they suck). (I think allow because things break otherwise?)
I am not sure, honestly. What do you have in mind?
[snip]
The final form of my shim will support running with any combination of "nothing" (Tor Browser just for the "privacy benefits", probably unsafe, I may reconsider this), I2P, and Tor (Though the most useful configuration is probably I2P + Tor).
Sounds useful, indeed. But I think we should make clear to users that this will not be a proper Tor Browser replacement as you need knowledge of the browser state to make correct assumptions on whether to put requests into the "--unknown--" bucket or not. And I currently don't see how your shim is able to accomplish that.
Georg
On Mon, 01 Jun 2015 07:43:50 +0000 Georg Koppen gk@torproject.org wrote:
My question is, what causes Tor Browser to set the SOCKS username to "--unknown--" and what the behavior should be in that case if:
Ideally, "--unknown--" would only be used for requests originating from privileged browser code and not belonging to a website/resource a user requested. This would encompass things like extensions update requests, browser update requests, blocklist checks, requests issued by installed extensions to name just a few. In reality, however, we are not there yet (see e.g. #13670, #15599, #15555, #15569 + plus there is at least one bug I have not filed yet).
Ah ok. That explains why I saw "--unknown--" when browsing reddit with my shim running.
- The destination is a ".onion" address.
#15499 should give you an idea (although I am not sure whether that ticket is still valid)
I think spacebook uses subdomains, but in the .onion space, so suffix based validation (socks username, and the requested destination both end in ".onion") is sufficient here.
- The destination is a ".i2p" address.
I don't know. Maybe we/you should coordinate that with the I2P folks?
I'm fairly sure just matching on suffix is also ok here.
The destination is the I2P management console.
I'm fairly sure this should be "deny".
Sounds good.
This is the only way I'm messing with/using the Isolation information currently. The management console appears to work.
- The destination is any other address (will be dispatched over
Tor if running, I don't think I will attempt to support I2P outproxies because they suck). (I think allow because things break otherwise?)
I am not sure, honestly. What do you have in mind?
[snip]
The final form of my shim will support running with any combination of "nothing" (Tor Browser just for the "privacy benefits", probably unsafe, I may reconsider this), I2P, and Tor (Though the most useful configuration is probably I2P + Tor).
Sounds useful, indeed. But I think we should make clear to users that this will not be a proper Tor Browser replacement as you need knowledge of the browser state to make correct assumptions on whether to put requests into the "--unknown--" bucket or not. And I currently don't see how your shim is able to accomplish that.
Well, it's real Tor Browser, just talking to an intermediary SOCKS proxy rather than the one exposed by Tor. I currently propagate the SOCKS username/password if possible (it's not for I2P, and no analog to the isolation exists, so stuff like new identity/new circuit will be a lot of work). Behavior without I2P running (or browsing stuff I dispatch to Tor) is identical to normal Tor Browser, given certain limitations[0].
Tor Browser already does the work of placing requests in the correct bucket for me, I'm just trying to use the work Tor Browser does to prevent cross protocol probing/attacks.
Maybe the right thing to do here would be to dispatch based on the isolation info and not the destination, since that doesn't give away the presense of the shim:
* If the socks username ends in ".i2p" send it to I2P regardless of destination. * If the socks username ends in ".onion" send it to Tor regardless of destination. * Otherwise send it to the default upstream provider (Tor in most cases).
(Note: The I2P management interface is special cased, and always will be special cased, since it's extra sensitive.)
But yeah. There will be tons of warning labels. Just trying to figure out a good way to get I2P and Tor to co-exist in a single Tor Browser instance while being relatively safe[1].
Regards,
-
Georg Koppen -
Yawning Angel