Re: [tor-dev] Iran
Is any IP6 in Iran? IP6 is blocked too? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Iran
On 5/9/13 1:34 AM, Jacob Appelbaum wrote: Maybe OONI ppl can help with that? I have an idea that I think might help. It isn't related to any current pluggable transport. I think we could pump out a transport that would not be easy to block. It would be also be very interesting to be able to play with the DPI system from an internal iranian intranet address space, if someone have an access from linux box. -naif ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Iran
Andrea Shepard: On Sun, May 05, 2013 at 10:40:52AM +, Nima wrote: Iran is actively dropping connections to *any* unknown port right after *60secs*. Pluggable Transport successfully connects to Tor network, Although it can not make a circuit in many ISPs including Mobin. -- Nima 0x1C92A77B I disapprove of what you say, but I will defend to the death your right to say it --Evelyn Beatrice Hall Hmmm... what does it behave like during those 60 seconds? Is it throttled, or can we get data through by cycling through a series of fresh TCP connections? What does it do with UDP packets? Same thing. they target both TCP and UDP packets. Could a datagram-based protocol defeat this? If they're interfering there, what about using TCP-looking packets to fake it? I.e., send SYNs with the data we really want to get through in the body and let them waste resources on their routers tracking connections that don't even really exist. I'd love to know this, but so far I haven't had a chance to get my hands on that network. We might be able to do something creative tho! More than 30 ppl have sent queries to Tor Farsi help desk. Most of them are willing to help. Maybe we should write a very tiny small program, which will run few tests and write results in a log file. So we can give it to our volunteers inside Iran to run it and send us the result. Maybe OONI ppl can help with that? -- Nima 0xA4D4C009DB191C92A77B I disapprove of what you say, but I will defend to the death your right to say it --Evelyn Beatrice Hall 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] Iran
Maybe OONI ppl can help with that? I have an idea that I think might help. It isn't related to any current pluggable transport. I think we could pump out a transport that would not be easy to block. Contact me off list if you'd like to help me with it. All the best, Jacob ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Iran
On Sun, May 05, 2013 at 10:40:52AM +, Nima wrote: Iran is actively dropping connections to *any* unknown port right after *60secs*. Pluggable Transport successfully connects to Tor network, Although it can not make a circuit in many ISPs including Mobin. -- Nima 0x1C92A77B I disapprove of what you say, but I will defend to the death your right to say it --Evelyn Beatrice Hall Hmmm... what does it behave like during those 60 seconds? Is it throttled, or can we get data through by cycling through a series of fresh TCP connections? What does it do with UDP packets? Could a datagram-based protocol defeat this? If they're interfering there, what about using TCP-looking packets to fake it? I.e., send SYNs with the data we really want to get through in the body and let them waste resources on their routers tracking connections that don't even really exist. -- Andrea Shepard and...@torproject.org PGP fingerprint: 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5 pgpUmFVkGYq97.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Iran
George Kadianakis: Nima n...@redteam.io writes: Iran is actively dropping connections to *any* unknown port right after *60secs*. Pluggable Transport successfully connects to Tor network, Although it can not make a circuit in many ISPs including Mobin. Ugh. This sucks. What do you mean by unknown port? Which ports do they allow? Not sure yet. Mostly like they've whitelisted the known protocols. I didn't have a chance to login to my box yet :/ https://twitter.com/search?q=%23filternetsrc=hash -- Nima 0x1C92A77B I disapprove of what you say, but I will defend to the death your right to say it --Evelyn Beatrice Hall 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] Iran
On Sunday 05 May 2013 14:50:51 George Kadianakis wrote: It would be interesting to learn which ports they currently whitelist, except from the usual HTTP/HTTPS. I also wonder if they just block based on TCP port, or whether they also have DPI heuristics. On the Tor side, it seems like we should start looking into #7875: https://trac.torproject.org/projects/tor/ticket/7875 ___ I am wondering if here is there a way for a user to ask bridgedb for a bridge with a specific port? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Iran
On Sun, May 05, 2013 at 04:18:56PM +0300, George Kadianakis wrote: tor-admin tor-ad...@torland.me writes: On Sunday 05 May 2013 14:50:51 George Kadianakis wrote: It would be interesting to learn which ports they currently whitelist, except from the usual HTTP/HTTPS. I also wonder if they just block based on TCP port, or whether they also have DPI heuristics. On the Tor side, it seems like we should start looking into #7875: https://trac.torproject.org/projects/tor/ticket/7875 ___ I am wondering if here is there a way for a user to ask bridgedb for a bridge with a specific port? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev If I remember correctly BridgeDB tries (in a best-effort manner) to give users bridges that are listening on port 443. Obfuscated bridges that bind on 443 are not very common (because of #7875) so I guess that not many obfuscated bridges on 443 are given out. In any case, I don't think that a user can explicitly ask BridgeDB for a bridge on a specific port, but this might be a useful feature request (especially if this filtering based on TCP port tactic continues). This may be a good feature to have, in general, but it does not sound like this will solve the current problem in Iran. The last report says they're whitelisting ports *and* protocols[1]. So even if a user attempts to use obfs3 on port 443 it'll likely be blocked because obfs3 is not a look-like-https protocol. If we had a PT that encapsulated obfs3 inside the body of http then this may work. CDA also says SSL/TLS connections are throttled to 5% of the normal speed [2], so that's no fun either. [1] https://twitter.com/CDA/status/331006059923795968 [2] https://twitter.com/CDA/status/331040305648369664 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Iran
have there been any attempts to produce a pluggable transport which would emulate http? (Ah, I suppose there've been quite a bit of discussion indeed. ( https://trac.torproject.org/projects/tor/ticket/8676, etc.)) On Sun, May 5, 2013 at 9:58 PM, Kostas Jakeliunas kos...@jakeliunas.comwrote: If we had a PT that encapsulated obfs3 inside the body of http then this may work. I'm probably missing some previous discussions which might have covered it, but: have there been any attempts to produce a pluggable transport which would emulate http? Basically, have the transport use http headers, and put all encrypted data in the body (possibly prepending it with some html tags even)? This sounds like a nice idea. On Sun, May 5, 2013 at 9:41 PM, Matthew Finkel matthew.fin...@gmail.comwrote: On Sun, May 05, 2013 at 04:18:56PM +0300, George Kadianakis wrote: tor-admin tor-ad...@torland.me writes: On Sunday 05 May 2013 14:50:51 George Kadianakis wrote: It would be interesting to learn which ports they currently whitelist, except from the usual HTTP/HTTPS. I also wonder if they just block based on TCP port, or whether they also have DPI heuristics. On the Tor side, it seems like we should start looking into #7875: https://trac.torproject.org/projects/tor/ticket/7875 ___ I am wondering if here is there a way for a user to ask bridgedb for a bridge with a specific port? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev If I remember correctly BridgeDB tries (in a best-effort manner) to give users bridges that are listening on port 443. Obfuscated bridges that bind on 443 are not very common (because of #7875) so I guess that not many obfuscated bridges on 443 are given out. In any case, I don't think that a user can explicitly ask BridgeDB for a bridge on a specific port, but this might be a useful feature request (especially if this filtering based on TCP port tactic continues). This may be a good feature to have, in general, but it does not sound like this will solve the current problem in Iran. The last report says they're whitelisting ports *and* protocols[1]. So even if a user attempts to use obfs3 on port 443 it'll likely be blocked because obfs3 is not a look-like-https protocol. If we had a PT that encapsulated obfs3 inside the body of http then this may work. CDA also says SSL/TLS connections are throttled to 5% of the normal speed [2], so that's no fun either. [1] https://twitter.com/CDA/status/331006059923795968 [2] https://twitter.com/CDA/status/331040305648369664 ___ 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
Re: [tor-dev] Iran
If we had a PT that encapsulated obfs3 inside the body of http then this may work. I'm probably missing some previous discussions which might have covered it, but: have there been any attempts to produce a pluggable transport which would emulate http? Basically, have the transport use http headers, and put all encrypted data in the body (possibly prepending it with some html tags even)? This sounds like a nice idea. On Sun, May 5, 2013 at 9:41 PM, Matthew Finkel matthew.fin...@gmail.comwrote: On Sun, May 05, 2013 at 04:18:56PM +0300, George Kadianakis wrote: tor-admin tor-ad...@torland.me writes: On Sunday 05 May 2013 14:50:51 George Kadianakis wrote: It would be interesting to learn which ports they currently whitelist, except from the usual HTTP/HTTPS. I also wonder if they just block based on TCP port, or whether they also have DPI heuristics. On the Tor side, it seems like we should start looking into #7875: https://trac.torproject.org/projects/tor/ticket/7875 ___ I am wondering if here is there a way for a user to ask bridgedb for a bridge with a specific port? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev If I remember correctly BridgeDB tries (in a best-effort manner) to give users bridges that are listening on port 443. Obfuscated bridges that bind on 443 are not very common (because of #7875) so I guess that not many obfuscated bridges on 443 are given out. In any case, I don't think that a user can explicitly ask BridgeDB for a bridge on a specific port, but this might be a useful feature request (especially if this filtering based on TCP port tactic continues). This may be a good feature to have, in general, but it does not sound like this will solve the current problem in Iran. The last report says they're whitelisting ports *and* protocols[1]. So even if a user attempts to use obfs3 on port 443 it'll likely be blocked because obfs3 is not a look-like-https protocol. If we had a PT that encapsulated obfs3 inside the body of http then this may work. CDA also says SSL/TLS connections are throttled to 5% of the normal speed [2], so that's no fun either. [1] https://twitter.com/CDA/status/331006059923795968 [2] https://twitter.com/CDA/status/331040305648369664 ___ 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
Re: [tor-dev] Iran
(Sorry, last email for now --) I see that StegoTorus is an Obfsproxy fork that extends it to a) split Tor streams across multiple connections to avoid packet size signatures, and b) embed the traffic flows in traces that look like html, javascript, or pdf. However, its public repo seems to haven't been updated for more than nine months. [1] Also, 'Format-Transforming Encryption' looks interesting, but I take it not much in terms of implementation beyond a research paper [2] (which looks interesting). [1] https://gitweb.torproject.org/stegotorus.git [2] https://eprint.iacr.org/2012/494 On Sun, May 5, 2013 at 10:08 PM, Kostas Jakeliunas kos...@jakeliunas.comwrote: have there been any attempts to produce a pluggable transport which would emulate http? (Ah, I suppose there've been quite a bit of discussion indeed. ( https://trac.torproject.org/projects/tor/ticket/8676, etc.)) On Sun, May 5, 2013 at 9:58 PM, Kostas Jakeliunas kos...@jakeliunas.comwrote: If we had a PT that encapsulated obfs3 inside the body of http then this may work. I'm probably missing some previous discussions which might have covered it, but: have there been any attempts to produce a pluggable transport which would emulate http? Basically, have the transport use http headers, and put all encrypted data in the body (possibly prepending it with some html tags even)? This sounds like a nice idea. On Sun, May 5, 2013 at 9:41 PM, Matthew Finkel matthew.fin...@gmail.comwrote: On Sun, May 05, 2013 at 04:18:56PM +0300, George Kadianakis wrote: tor-admin tor-ad...@torland.me writes: On Sunday 05 May 2013 14:50:51 George Kadianakis wrote: It would be interesting to learn which ports they currently whitelist, except from the usual HTTP/HTTPS. I also wonder if they just block based on TCP port, or whether they also have DPI heuristics. On the Tor side, it seems like we should start looking into #7875: https://trac.torproject.org/projects/tor/ticket/7875 ___ I am wondering if here is there a way for a user to ask bridgedb for a bridge with a specific port? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev If I remember correctly BridgeDB tries (in a best-effort manner) to give users bridges that are listening on port 443. Obfuscated bridges that bind on 443 are not very common (because of #7875) so I guess that not many obfuscated bridges on 443 are given out. In any case, I don't think that a user can explicitly ask BridgeDB for a bridge on a specific port, but this might be a useful feature request (especially if this filtering based on TCP port tactic continues). This may be a good feature to have, in general, but it does not sound like this will solve the current problem in Iran. The last report says they're whitelisting ports *and* protocols[1]. So even if a user attempts to use obfs3 on port 443 it'll likely be blocked because obfs3 is not a look-like-https protocol. If we had a PT that encapsulated obfs3 inside the body of http then this may work. CDA also says SSL/TLS connections are throttled to 5% of the normal speed [2], so that's no fun either. [1] https://twitter.com/CDA/status/331006059923795968 [2] https://twitter.com/CDA/status/331040305648369664 ___ 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
Re: [tor-dev] Iran
On Sun, May 05, 2013 at 10:44:01PM +0300, Kostas Jakeliunas wrote: Also, 'Format-Transforming Encryption' looks interesting, but I take it not much in terms of implementation beyond a research paper [2] (which looks interesting). [2]https://eprint.iacr.org/2012/494 I haven't tried it yet, but they do have an implementation and are inviting testers. http://fte.kpdyer.com/ David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
