(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).<br>

<br>[1] <a href="https://gitweb.torproject.org/stegotorus.git">https://gitweb.torproject.org/stegotorus.git</a><br>[2] <a href="https://eprint.iacr.org/2012/494">https://eprint.iacr.org/2012/494</a><br><br><div class="gmail_quote">

On Sun, May 5, 2013 at 10:08 PM, Kostas Jakeliunas <span dir="ltr"><<a href="mailto:kostas@jakeliunas.com" target="_blank">kostas@jakeliunas.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">> have there been any attempts to produce a pluggable transport which would emulate http?<br><br></div>(Ah, I suppose there've been quite a bit of discussion indeed. (<a href="https://trac.torproject.org/projects/tor/ticket/8676" target="_blank">https://trac.torproject.org/projects/tor/ticket/8676</a>, etc.))<div class="HOEnZb">

<div class="h5"><br>
<br><div class="gmail_quote">On Sun, May 5, 2013 at 9:58 PM, Kostas Jakeliunas <span dir="ltr"><<a href="mailto:kostas@jakeliunas.com" target="_blank">kostas@jakeliunas.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>> If we had a PT that encapsulated obfs3 inside<br>
the body of http then this may work.<br><br></div>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.<div>


<div><br>
<br><div class="gmail_quote">On Sun, May 5, 2013 at 9:41 PM, Matthew Finkel <span dir="ltr"><<a href="mailto:matthew.finkel@gmail.com" target="_blank">matthew.finkel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>On Sun, May 05, 2013 at 04:18:56PM +0300, George Kadianakis wrote:<br>
> tor-admin <<a href="mailto:tor-admin@torland.me" target="_blank">tor-admin@torland.me</a>> writes:<br>
><br>
> > On Sunday 05 May 2013 14:50:51 George Kadianakis wrote:<br>
> >> It would be interesting to learn which ports they currently whitelist,<br>
> >> except from the usual HTTP/HTTPS.<br>
> >><br>
> >> I also wonder if they just block based on TCP port, or whether they<br>
> >> also have DPI heuristics.<br>
> >><br>
> >> On the Tor side, it seems like we should start looking into #7875:<br>
> >> <a href="https://trac.torproject.org/projects/tor/ticket/7875" target="_blank">https://trac.torproject.org/projects/tor/ticket/7875</a><br>
> >> _______________________________________________<br>
> > I am wondering if here is there a way for a user to ask bridgedb for a bridge<br>
> > with a specific port?<br>
> > _______________________________________________<br>
> > tor-dev mailing list<br>
> > <a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
> > <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
><br>
> If I remember correctly BridgeDB tries (in a best-effort manner) to<br>
> give users bridges that are listening on port 443. Obfuscated bridges<br>
> that bind on 443 are not very common (because of #7875) so I guess<br>
> that not many obfuscated bridges on 443 are given out.<br>
><br>
> In any case, I don't think that a user can explicitly ask BridgeDB for<br>
> a bridge on a specific port, but this might be a useful feature<br>
> request (especially if this "filtering based on TCP port" tactic<br>
> continues).<br>
<br>
</div>This may be a good feature to have, in general, but it does not sound like<br>
this will solve the current problem in Iran. The last report says<br>
they're whitelisting ports *and* protocols[1]. So even if a user attempts<br>
to use obfs3 on port 443 it'll likely be blocked because obfs3 is not a<br>
look-like-https protocol. If we had a PT that encapsulated obfs3 inside<br>
the body of http then this may work. CDA also says SSL/TLS connections<br>
are throttled to 5% of the normal speed [2], so that's no fun either.<br>
<br>
[1] <a href="https://twitter.com/CDA/status/331006059923795968" target="_blank">https://twitter.com/CDA/status/331006059923795968</a><br>
[2] <a href="https://twitter.com/CDA/status/331040305648369664" target="_blank">https://twitter.com/CDA/status/331040305648369664</a><br>
<div><div>_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>