[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #7944 [Flashproxy]: Standalone flash proxy

#7944: Standalone flash proxy
-------------------------+--------------------------------------------------
 Reporter:  akrey        |          Owner:  dcf
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:     
Component:  Flashproxy   |        Version:     
 Keywords:               |         Parent:     
   Points:               |   Actualpoints:     
-------------------------+--------------------------------------------------

Comment(by dcf):

 Replying to [comment:4 arma]:
 > Hey speaking of which: in the Flashproxy model, the Tor bridge needs
 some glue to pretend to be a webserver, since the Flash Proxy is only
 allowed to talk certain protocols.

 Yes, this glue is [`websocket-transport`
 https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-
 transport] and there is only one bridge I'm aware of running it (mine,
 tor1.bamsoftware.com). Letting the facilitator cope with more is #7945.

 > This outside-the-browser standalone Flash proxy wouldn't have such a
 requirement -- does that mean it could (should) just interface with normal
 Tor bridges directly?

 Yes, correct, which is potentially very exciting for ideas like #7167,
 combining obfsproxy with flash proxy, because it allows us to escape the
 outer (fingerprintable) layer of WebSocket. There's no reason why a client
 couldn't speak obfs2, for example, through a standalone flash proxy, to
 any old obfs2 bridge.

 Check comment:2:ticket:5578 regarding WebRTC, where I proposed having
 client registrations inform the facilitator of the types of connections
 they want. Currently we assume that all communication is WebSocket, both
 clientâproxy and proxyârelay. It gets more complicated when clientâproxy
 may be WebSocket, WebRTC, or raw TCP; and proxyârelay may be WebSocket,
 raw TCP, obfs2-in-WebSocket, or obfs2-in-raw TCP. E.g., a standalone proxy
 doesn't have to care whether it is carrying plain Tor or obfs2 in terms of
 making a connection, but it has to know which protocol the client plans to
 tunnel in order to connect to a bridge of the appropriate type.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7944#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs