Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#9164 closed defect (duplicate)

Is Flashproxy pluggable transport really working? Tests, comments and questions

Reported by: Aymeric Owned by: dcf
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I tried to test flash proxies and websockets with bridges.

So I modified a little bit flashproxy.js, see http://www.ianonym.com/test.html, mainly I modified the polling timer to the facilitator to 10s and activated the debug.

Probably it's related to #9008 but for most of the routers returned by the facilitator the websocket connexion failed, see file herattached.

During a period of time it worked only two times, and what is strange is that it failed afterwards with the "successful" routers.

And a direct websocket connexion attempt toward these "successfull" routers failed too.

I tried this with FF Nightly/Last and Chrome.

Does it exist some test routers for flashproxies?

Child Tickets

Attachments (1)

tor_ff2.html (8 bytes) - added by nickm 4 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 in reply to:  description Changed 4 years ago by arlolra

Replying to Aymeric:

So I modified a little bit flashproxy.js, see http://www.ianonym.com/test.html, mainly I modified the polling timer to the facilitator to 10s and activated the debug.

This wasn't necessary. The embed code can accept querystring parameters,

    embed.html?facilitator_poll_interval=10&initial_facilitator_poll_interval=10&debug=1

Probably it's related to #9008 but for most of the routers returned by the facilitator the websocket connexion failed, see file herattached.

Seems like #9008. There's at least one successful connection in the attached,
https://trac.torproject.org/projects/tor/attachment/ticket/9164/tor_ff2.html#L1180

During a period of time it worked only two times, and what is strange is that it failed afterwards with the "successful" routers.

And a direct websocket connexion attempt toward these "successfull" routers failed too.

This sounds confused. I'm not sure what you mean by router here.

Take for example,

Facilitator: got client:{ host: "xxx.xxx.xxx.xxx", port: 9000 } relay:{ host: "173.255.221.44", port: 9901 }.

In this scenario, you are the flashproxy. You've polled the facilitator and received a client IP. You then make two websocket connections, one to the client on port 9000 and one to the relay on port 9901. When the connections establish, your only job is to shuttle bits between those two ports. On each end, tor is running using the websocket (not flashproxy) pluggable transport.

The idea being that the flashproxies are ephemeral but in constant supply. The websocket PT exists independently of flashproxies and can be used for direct connections.

I would suggest taking a look at the diagram here,
https://crypto.stanford.edu/flashproxy/#how-it-works

Forgive me if you already understand all this and I'm misinterpreting your question.

comment:2 Changed 4 years ago by Aymeric

I indeed read the spec some time ago, just got the whole code to look at it, but really did this too fast and inverted client and relay in facilitator's answer.

So it's a duplicate of #9008, you can close it, but that's still keeping the browser busy for nothing.

Two remarks : websocket PT --> OK, but the terminology maybe is confusing here https://www.torproject.org/docs/pluggable-transports.html.en, and sometimes the metric image does not display on your site.

What are the criteria to know if a node is supporting the websocket PT (>= v0.2.4.12 ?)?

comment:3 Changed 4 years ago by dcf

Resolution: duplicate
Status: newclosed

Replying to arlolra:

This wasn't necessary. The embed code can accept querystring parameters,

    embed.html?facilitator_poll_interval=10&initial_facilitator_poll_interval=10&debug=1

But please don't override facilitator_poll_interval. Set up your own test network if you must use such aggressive parameters. The facilitator does not yet protect itself against proxies polling so frequently; that's #7823. If you are debugging connections, don't use the public facilitator. Use the client and relay query string parameters instead.

This is a duplicate to #9008. Unfortunately, most of the connections you get are likely to fail. It's nothing to worry about.

It's not surprising that a later WebSocket connection fails when it worked before. That just means they closed their Tor Browser Bundle and flashproxy-client is no longer listening.

Aymeric, please don't post flashproxy.js debug files that contain client IP addresses.

Changed 4 years ago by nickm

Attachment: tor_ff2.html added

comment:4 Changed 4 years ago by nickm

Removed the file with client IPs at dcf's request. I still have a copy if somebody needs it. dcf has promised to implement a safe-logging feature and have it by default.

comment:5 Changed 4 years ago by Aymeric

Yes, sorry, I remove my test too.

comment:6 in reply to:  4 Changed 4 years ago by dcf

Replying to nickm:

dcf has promised to implement a safe-logging feature and have it by default.

#9170.

comment:7 Changed 4 years ago by Aymeric

Even when the facilitator will be protected, is this not an issue to get so easily users' IP addresses?

comment:8 in reply to:  7 Changed 4 years ago by arlolra

Replying to Aymeric:

What are the criteria to know if a node is supporting the websocket PT (>= v0.2.4.12 ?)?

I'm not sure if you can query a node to see what pluggable transports it supports. In any case, there may only be as little as one. For testing purposes, I suggest you setup your own. See "How to run a relay",
https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/README#l100

Even when the facilitator will be protected, is this not an issue to get so easily users' IP addresses?

Hiding the fact that a client wishes to use Tor is not part of the flash proxy threat model. Also, as suggested above, the facilitator should be rate-limited to control how many client IPs are handed out to each requesting flash proxy. Please see the research paper,
https://crypto.stanford.edu/flashproxy/flashproxy.pdf

comment:9 Changed 4 years ago by Aymeric

I have my own already, see https://www.github.com/Ayms/node-Tor

While testing flashproxy (which I did really too fast, sorry again) I could not guess the system was so vulnerable, thought it was still in a testing phase.

I will read the paper again but against browsers I don't see what you can rate-limit (ie advantadges of the solution can be used against it).

And whether the js code is open or not, you should at least minify the online version, and wrap the code, and use prototype, etc, imho as everybody does.

And it's interesting to know what nodes are supporting what PT (Atlas?)

That's not negative comments, the concept is great, like webRTC, like hopefully things I am doing.

comment:10 in reply to:  9 Changed 4 years ago by bastik

Replying to Aymeric:

And it's interesting to know what nodes are supporting what PT (Atlas?)

Atlas does not support Bridges, yet.

Bridges report their supported transports to BridgeDB, but that should not apply to Flashproxy, as far as I know.

The data-source for Atlas, Onionoo [1], has some data available, although the format is not designed to be read by humans.

https://onionoo.torproject.org/details?type=bridge

If you look at "poolassignment [...] transport=" you see obfs2, obfs3 for some bridges. This is based on the information in which distribution pool(s) a bridge is. This information is not available for relays as those are public.

[1] Protocol overview: https://onionoo.torproject.org/

Note: See TracTickets for help on using tickets.