Re: [tor-dev] DuckDuckGo, iOS and other stuff.
On 01/02/2012 02:39 PM, caine tighe wrote: there is serious value in ensuring Tor is an option for both Android and iOS. Currently we support Tor via Orbot on Android via the HTTP/S proxy method since the SOCKS method is known to have DNS leaks. I agree! As a side note, in Orweb v2, when you type a search in the location bar, it utilizes the DDG hidden service. The SOCKS method works fine if you support the right type of SOCKS. There is inherently nothing wrong with Tor's SOCKS support, and it is what we utilize for the Firefox Mobile ProxyMob add-on. application Covert Browser that claims to properly leverage Tor; however, since the source is closed, I remain unconvinced. This Regardless of the poor approach to transparency they have taken, it does seem that Tor integrated into a browser or search app directly is the only way to go on iOS at the moment. I don't quite understand what happens when multiple apps with Tor embedded in them are running at once, with the psuedo backgrounding/multitasking that iOS supports. It is also true that it is best to keep Tor running and connected as long as possible in order for it to be able to optimize circuits, update directories, and so on. If you are constantly starting and stopping it within one app, the performance may suffer. application stands to be both an interface to DuckDuckGo for quick and secure searching as well as a Tor enabled browser. It would be fantastic to have you take this on, as an open-source option is needed for iOS, and the Guardian Project isn't currently able to expand to that platform. best, +n ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Browser-based proxies for circumvention
A sample session goes like this: 1. The user starts a connector and a Tor client. The connector sends its address to the facilitator, so that a proxy will know where to connect to. (We call this step rendezvous.) 2. A flash proxy appears in a browser and asks the facilitator for an address. 3. The facilitator sends a remembered client address to the proxy. 4. The proxy connects to the client address. The client's connector receives the connection. 5. The proxy connects to a Tor relay, then begins copying data between its two sockets. Where is the list of all facilitators? There is only one (not that there couldn't be more), and its address is hardcoded into the proxy badge. I think I am confused about something: Why is it difficult for the censor to enumerate, and then block, the facilitators? -Kevin ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A modest proposal for a petname system in ideas/xxx-onion-nyms.txt
On 02/01/12 10:59, William Waites wrote: What if instead, we used a similar mechanism as we already have for the hidden services and do say hash(antani).nym and push that out to the introduction hosts. The introduction hosts would check if they can resolve it, if they can, the request is rejected, if they cannot then they keep the mapping (careful implementation to avoid race conditions here). Have an cache+expiry mechanism from there so the mapping isn't trivially lost when the hidden host goes offline. If I'm understanding you correctly... Let's say Mallory discovers a scripting error and exploits it to fork-bomb Alice's service. It has insufficient resources to keep the hidden service online but still responds to pings and even manages to serve an occasional static page on a non-hidden address, fooling Alice's home-grown monitoring solution. Alice of course notices the problem when she manually checks the service, but she attributes the failures to something else, leaving Mallory free to keep trying. Eventually Alice takes a vacation and Mallory is successful at keeping the service offline for $expiry_time. At this point the nym can be hijacked as no secret is needed to claim it. Am I missing something? Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A modest proposal for a petname system in ideas/xxx-onion-nyms.txt
On Tue, 03 Jan 2012 19:52:00 +, Julian Yon jul...@yon.org.uk said: jry Eventually Alice takes a vacation and Mallory is jry successful at keeping the service offline for $expiry_time. At jry this point the nym can be hijacked as no secret is needed to jry claim it. Two things here. Firstly, the advertisement of the nym with the introduction hosts would be signed with the hidden service's key, the pair (Hash(somenym), Srv_PubKey) would be kept cached around the network allowing it to be reclaimed should the hidden service move around. Similarly, to flesh things out, a nym could be released or transferred with a similarly signed message. Secondly, on the expiry, that idea was copied as I understood it from the original proposal, designed to mitigate nym squatting, and allowing nyms to be eventually recycled. I'm not necessarily convinced by it and haven't thought about this aspect very closely. A malicious nym squatter could trivially maintain lots of mappings directly anyways. And likewise a clever DOS designed to cause the registration to expire would make nym hijacking possible, and this is true, I think, wherever there is an expiry mechanism. Cheers, -w -- William Waites wwai...@tardis.ed.ac.uk Visiting Researcher, Laboratory for Foundations of Computer Science School of Informatics, University of Edinburgh pgpEjXSzTMmXg.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
