Hello everybody, We now have some flashproxy Tor Browser Bundles ready. These are alpha bundles, made by adding our files to the existing obfsproxy bundle. We would appreciate some testing and feedback. You can get the bundles here: Windows: https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-2.4.6-a... https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-2.4.6-a... OSX: https://people.torproject.org/~dcf/flashproxy/TorBrowser-FlashProxy-2.4.6-al... https://people.torproject.org/~dcf/flashproxy/TorBrowser-FlashProxy-2.4.6-al... 32-bit GNU/Linux: https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-gnu-lin... https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-gnu-lin... 64-bit GNU/Linux: https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-gnu-lin... https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-gnu-lin... To verify the signatures you will need David Fifield's public key. You can get it at: http://bamsoftware.com/david/david.asc or by fetching key 0x6BC758CBC11F6276 from: x-hkp://pool.sks-keyservers.net If your machine is behind a NAT device, you will need to configure port forwarding. The client listens for incoming WebSocket connections on port 9000 by default. If you want to forward a different port, you will need to edit your torrc. Find this line, ClientTransportPlugin websocket exec flashproxy-client --register :0 :9000 and change 9000 to the port you have chosen to forward. Once you have configured port forwarding you should be able to start the Browser Bundle as you normally would. Some specific things we would like feedback on are: - Is configuring port forwarding insurmountable for you? - If it didn't work, was it at least clear what was wrong? What was the output in the Vidalia log? - Were you able to use this as your main Tor process for a day? - Was it ever obvious to you that you had switched to another proxy (this would have broken existing circuits)? We have a wiki page setup for usability discussions at: https://trac.torproject.org/projects/tor/wiki/FlashProxyUsability Feel free to edit it. You can also leave comments on this trac ticket: https://trac.torproject.org/projects/tor/ticket/7425 Please send feedback, bug reports, etc. to the tor-dev list, or to dcf@torproject.org. Thanks. Alex
Alexandre:
- Is configuring port forwarding insurmountable for you?
It was always too much to ask the user to set up a port forwarding. Try asking your non-technical friends or family. You'll see. Alternatively search for RetroShare, emule, filesharing port forwarding and see how many people having trouble. There are also cases, where it is impossible to set up a port forwarding. Such cases include for example 3G networks, WiFi hotspots or all other networks where the admin won't do it for you. I think dropping the requirement for a port forwarding is crucial to let any non-geek users profit from it. Or wait for IPv6 and such problems will vanish?
It's unfortunately a limitation of the technology we are using. The proxies run as javascript code in peoples' web browsers, and use the WebSocket protocol to relay traffic from the client to the relay. This protocol is designed to allow bidirectional communication from a browser to a web server using a single connection, as a replacement for the current method, which is to constantly make new http requests to the server. In this scenario it doesn't really make sense for web browsers to accept connections, so browser implementations don't let you do it. So the user has to be able to accept connections on his end. You can get the full details on flash proxies here: https://crypto.stanford.edu/flashproxy/ Alex On 2012-12-13, at 12:10 PM, adrelanos <adrelanos@riseup.net> wrote:
Alexandre:
- Is configuring port forwarding insurmountable for you?
It was always too much to ask the user to set up a port forwarding. Try asking your non-technical friends or family. You'll see. Alternatively search for RetroShare, emule, filesharing port forwarding and see how many people having trouble.
There are also cases, where it is impossible to set up a port forwarding. Such cases include for example 3G networks, WiFi hotspots or all other networks where the admin won't do it for you.
I think dropping the requirement for a port forwarding is crucial to let any non-geek users profit from it. Or wait for IPv6 and such problems will vanish? _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Have you considered Hole punching techniques? [1] TCP, UDP, ICMP hole punching... There are many techniques. I don't know if the WebSocket protocol would prevent it. STUN [2] like techniques where a third non-firewalled server helps to traversal the NAT. (Only NAT, not used a proxy.) pwnat [3] also looks interesting. It doesn't need a third server and lets connect two nat'ed machines with each other. There are probable more things to consider. For example if the pwnat method (or any other nat traversal method) could later be easily used to fingerprint and censor the connection. [1] https://en.wikipedia.org/wiki/Hole_punching [2] https://en.wikipedia.org/wiki/STUN [3] http://samy.pl/pwnat/ Alexandre:
It's unfortunately a limitation of the technology we are using. The proxies run as javascript code in peoples' web browsers, and use the WebSocket protocol to relay traffic from the client to the relay.
This protocol is designed to allow bidirectional communication from a browser to a web server using a single connection, as a replacement for the current method, which is to constantly make new http requests to the server. In this scenario it doesn't really make sense for web browsers to accept connections, so browser implementations don't let you do it. So the user has to be able to accept connections on his end.
You can get the full details on flash proxies here:
https://crypto.stanford.edu/flashproxy/
Alex
On 2012-12-13, at 12:10 PM, adrelanos <adrelanos@riseup.net> wrote:
Alexandre:
- Is configuring port forwarding insurmountable for you?
It was always too much to ask the user to set up a port forwarding. Try asking your non-technical friends or family. You'll see. Alternatively search for RetroShare, emule, filesharing port forwarding and see how many people having trouble.
There are also cases, where it is impossible to set up a port forwarding. Such cases include for example 3G networks, WiFi hotspots or all other networks where the admin won't do it for you.
I think dropping the requirement for a port forwarding is crucial to let any non-geek users profit from it. Or wait for IPv6 and such problems will vanish? _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, Dec 13, 2012 at 06:38:03PM +0000, adrelanos wrote:
Have you considered Hole punching techniques? [1] TCP, UDP, ICMP hole punching... There are many techniques. I don't know if the WebSocket protocol would prevent it.
STUN [2] like techniques where a third non-firewalled server helps to traversal the NAT. (Only NAT, not used a proxy.)
pwnat [3] also looks interesting. It doesn't need a third server and lets connect two nat'ed machines with each other.
Better nat punching is on the 'future research' list. The main challenge is that if you're trying to provide a circumvention system, then relying on a "reliably reachable third party" is exactly what you can't do. Whether these various "look, no hands" punching tools and tricks can be done using only websockets on the remote side is a great question for somebody to answer. See also Jake's NAT investigation tech report at http://research.torproject.org/techreports.html (I'm cc'ing Christian Grothoff, as our resident nat punching expert.) --Roger
Roger Dingledine:
On Thu, Dec 13, 2012 at 06:38:03PM +0000, adrelanos wrote:
Have you considered Hole punching techniques? [1] TCP, UDP, ICMP hole punching... There are many techniques. I don't know if the WebSocket protocol would prevent it.
STUN [2] like techniques where a third non-firewalled server helps to traversal the NAT. (Only NAT, not used a proxy.)
pwnat [3] also looks interesting. It doesn't need a third server and lets connect two nat'ed machines with each other.
Better nat punching is on the 'future research' list.
The main challenge is that if you're trying to provide a circumvention system, then relying on a "reliably reachable third party" is exactly what you can't do.
I agree, the report you linked below gives indeed good reasons against.
Whether these various "look, no hands" punching tools and tricks can be done using only websockets on the remote side is a great question for somebody to answer.
I copied the relevant parts about pwnat from the report you linked below and tried to rephrase it to talk only about pwnat.
We consider pwnat to be out of scope at this time due because it requires specialized client software to access services offered behind a NAT device. The technique implemented by pwnat is much more attractive. It is generally friendly to privacy and does not rely on NAT router configuration.
Is "requires specialized client software" is really a blocker? UPnP and NAT–PMP are also "requires specialized third party libraries".
See also Jake's NAT investigation tech report at http://research.torproject.org/techreports.html
Great reading!
Roger Dingledine:
Whether these various "look, no hands" punching tools and tricks can be done using only websockets on the remote side is a great question for somebody to answer.
By the way, I found it in their design paper. Quote: The fact that clients must not be behind NAT is an impediment to usability. A NAT traversal mechanism that works within our threat model would be a great benefit. Typical NAT traversal technologies, such as STUN (Session Traversal Utilities for NAT) [21] and RTMFP (Real Time Media Flow Protocol) [22], rely on a stable third-party server to facilitate the connection, which is trivially de- feated by the censor blocking the third party by IP address. (Also we believe it is better to avoid informing a third party of each flash proxy connection if it can be avoided.) Tricks involving low-level packet manipulation, for example pw- nat [23], are not available to browser sockets. Ideally, any NAT traversal scheme will not require both the client and the proxy to know each other’s IP address, so that facilitator registration can remain unidirectional. New technologies like WebRTC [24] may fill this need in the future, if they become sufficiently popular that flash proxies’ use of them does not stand out as unusual.
Alexandre:
You can get the full details on flash proxies here:
I read the full paper. It's amazing.
On Thu, Dec 13, 2012 at 05:10:52PM +0000, adrelanos wrote:
Or wait for IPv6 and such problems will vanish?
In fact IPv6 is one solution to the NAT problem. To my surprise, there are a few IPv6 flash proxies operating. I was able to bootstrap and surf over a couple of them, using an he.net tunnel and without configuring port forwarding. There is a bug, though (https://trac.torproject.org/projects/tor/ticket/6124) which means the facilitator may give your address to IPv4-only proxies who are unable to connect to you. Once that is fixed, it will be reliable; until then, you just have to be a bit lucky. David Fifield
Alexandre:
Windows: https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-2.4.6-a... https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-2.4.6-a...
Thanks my platform. (Windows 7 64bit)
Some specific things we would like feedback on are:
- Is configuring port forwarding insurmountable for you?
I didn't have to do this. I guess I could do that, but "normal" end users might not. (I know about the FP design.)
- If it didn't work, was it at least clear what was wrong?
I thought the progress would have stopped here, but it just took much longer than expected. [Notice] Bootstrapped 50%: Loading relay descriptors. Starting TBB again, reduces the time. Might be the proxy that is in use, because on retrying again, I "stuck" at 85% or 90%.
What was the output in the Vidalia log?
The bridge log lines were the only difference.
- Were you able to use this as your main Tor process for a day?
Browsing is slower (due to the proxies in use I assume), but aside from that I could use it to get the information I require.
- Was it ever obvious to you that you had switched to another proxy (this would have broken existing circuits)?
Maybe I was lucky. I couldn't say that I noticed that. When I say proxy I'm referring to the JavaScript proxy that runs in the browser. It's an alpha bundle, but I did not expect it to dump everything where the executable was. (Tor Browser\) I thought I would be able to select where to extract. I also saw a, to some maybe scary, console. Might be alpha stuff. There might be more testing required for the durable of proxies. I report back if I find something strange. Regards, Sebastian (bastik_tor)
Thank you for testing! This report is very helpful. On Thu, Dec 13, 2012 at 07:59:31PM +0100, Sebastian G. <bastik.tor> wrote:
- If it didn't work, was it at least clear what was wrong?
I thought the progress would have stopped here, but it just took much longer than expected.
[Notice] Bootstrapped 50%: Loading relay descriptors.
Starting TBB again, reduces the time.
Might be the proxy that is in use, because on retrying again, I "stuck" at 85% or 90%.
That is interesting. I have often seen Tor stall at 50%. During that time there is no network traffic for about 60 seconds, so it's not just that downloading descriptors is slow. After about 60 seconds, it starts downloading descriptors. I haven't figured out why. Stalling at 85% might mean that you got only one proxy, when two are required to bootstrap, recently and for yet-unknown reasons. https://lists.torproject.org/pipermail/tor-dev/2012-December/004260.html If you go into the bundle and run the flashproxy-reg-email or flashproxy-reg-http program, that should be enough to get you more proxies without restarting Vidalia. You can get better debugging information by adding something like --log flashproxy.txt to the ClientTransportPlugin line in torrc.
- Were you able to use this as your main Tor process for a day?
Browsing is slower (due to the proxies in use I assume), but aside from that I could use it to get the information I require.
It's slower for at least three reasons. One is that you're extending the network path of the circuit (three Tor hops and one flash proxy hop). Another is that the websocket bridge relay isn't particularly fast. Another is that some browsers (only Firefox 10 at this point I think) don't support binary WebSocket frames and we use base64-encoded text frames for them instead.
It's an alpha bundle, but I did not expect it to dump everything where the executable was. (Tor Browser\) I thought I would be able to select where to extract.
I also saw a, to some maybe scary, console. Might be alpha stuff.
Oh, thank you. This is good to know. Probably I created the self-extracting executable in a different way than the official bundles. (BTW the procedure for making the Windows bundle is here: https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/bundle-windows.t....) David Fifield
The "scary console" mentioned in the test report is probably because of the console=true option in the pyinstaller spec file. I'll have a look and confirm. Alex On 2012-12-13, at 7:01 PM, David Fifield <david@bamsoftware.com> wrote:
Thank you for testing! This report is very helpful.
On Thu, Dec 13, 2012 at 07:59:31PM +0100, Sebastian G. <bastik.tor> wrote:
- If it didn't work, was it at least clear what was wrong?
I thought the progress would have stopped here, but it just took much longer than expected.
[Notice] Bootstrapped 50%: Loading relay descriptors.
Starting TBB again, reduces the time.
Might be the proxy that is in use, because on retrying again, I "stuck" at 85% or 90%.
That is interesting. I have often seen Tor stall at 50%. During that time there is no network traffic for about 60 seconds, so it's not just that downloading descriptors is slow. After about 60 seconds, it starts downloading descriptors. I haven't figured out why.
Stalling at 85% might mean that you got only one proxy, when two are required to bootstrap, recently and for yet-unknown reasons. https://lists.torproject.org/pipermail/tor-dev/2012-December/004260.html If you go into the bundle and run the flashproxy-reg-email or flashproxy-reg-http program, that should be enough to get you more proxies without restarting Vidalia.
You can get better debugging information by adding something like --log flashproxy.txt to the ClientTransportPlugin line in torrc.
- Were you able to use this as your main Tor process for a day?
Browsing is slower (due to the proxies in use I assume), but aside from that I could use it to get the information I require.
It's slower for at least three reasons. One is that you're extending the network path of the circuit (three Tor hops and one flash proxy hop). Another is that the websocket bridge relay isn't particularly fast. Another is that some browsers (only Firefox 10 at this point I think) don't support binary WebSocket frames and we use base64-encoded text frames for them instead.
It's an alpha bundle, but I did not expect it to dump everything where the executable was. (Tor Browser\) I thought I would be able to select where to extract.
I also saw a, to some maybe scary, console. Might be alpha stuff.
Oh, thank you. This is good to know. Probably I created the self-extracting executable in a different way than the official bundles. (BTW the procedure for making the Windows bundle is here: https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/bundle-windows.t....)
David Fifield _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Alexandre:
The "scary console" mentioned in the test report is probably because of the console=true option in the pyinstaller spec file. I'll have a look and confirm.
Alex
My report might be misleading. When I execute "tor-flashproxy-browser-2.4.6-alpha-2_en-US.exe" a console window pops up and I can see where the bundle is extracted to. (I expected a dialog, to which folder I'd like to extract it) I said "scary console" because on Windows you don't use the console (well yeah some do, but those don't count ;)) and seeing the console, without knowing what it actually is or does could lead to confusion. Beside the console during the extraction process (that's what I talked about in the report) I see console windows when I execute "flashproxy-reg-email.exe" or "flashproxy-reg-http.exe"; I don't think those will be a problem, because they just pop-up and are gone; wont miss them either. (Was not included in my report, because I hadn't executed them manually) Regards, Sebastian (bastik_tor)
Thanks for pointing this out. I always run the programs from a console, in which case there is no extra pop-up console, so I hadn't noticed the issue. We should be able to get rid of them in future releases. Alex On 2012-12-14, at 10:34 AM, "Sebastian G. <bastik.tor>" <bastik.tor@googlemail.com> wrote:
Alexandre:
The "scary console" mentioned in the test report is probably because of the console=true option in the pyinstaller spec file. I'll have a look and confirm.
Alex
My report might be misleading.
When I execute "tor-flashproxy-browser-2.4.6-alpha-2_en-US.exe" a console window pops up and I can see where the bundle is extracted to.
(I expected a dialog, to which folder I'd like to extract it)
I said "scary console" because on Windows you don't use the console (well yeah some do, but those don't count ;)) and seeing the console, without knowing what it actually is or does could lead to confusion.
Beside the console during the extraction process (that's what I talked about in the report) I see console windows when I execute "flashproxy-reg-email.exe" or "flashproxy-reg-http.exe"; I don't think those will be a problem, because they just pop-up and are gone; wont miss them either. (Was not included in my report, because I hadn't executed them manually)
Regards, Sebastian (bastik_tor) _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (5)
-
adrelanos -
Alexandre -
David Fifield -
Roger Dingledine -
Sebastian G. <bastik.tor>