<div dir="ltr">[Taking this discussion to tor-dev.]<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 1, 2013 at 6:32 AM, George Kadianakis <span dir="ltr"><<a href="mailto:desnacked@riseup.net" target="_blank">desnacked@riseup.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Kevin P Dyer <<a href="mailto:kpdyer@gmail.com" target="_blank">kpdyer@gmail.com</a>> writes:<br>
<br>
> Hi George/David,<br>
><br>
<br>
Hi Kevin,<br>
<div><br>
> I spoke with Roger at USENIX. He said you're the pluggable transport (PT)<br>
> gatekeepers. Please bear with me while I get up to speed.<br>
><br>
> My goals:<br>
> 1. I want Format-Transforming Encryption (FTE) [4] to be a "deployed" PT in<br>
> the PT TBB.<br>
> 2. I want FTE to be integrated seamlessly with your existing deployment<br>
> process.<br>
><br>
> My initial roadblocks:<br>
><br>
> === Building/Testing Tor on Linux/OSX/Windows<br>
> I'm trying to understand exactly how the current build/release process<br>
> works for tor. In regards to the PT TBB it seems like there are a few<br>
> resources [1,2,3]. However, is there a canonical documentation on how the<br>
> release process works? I'm especially interested in what you guys are doing<br>
> to produce builds on Windows. Are you using virtualization or do you have a<br>
> few physical build machines?<br>
><br>
> Prior to doing anything with FTE. I'd love to be able to create my own<br>
> build environment that produces that current obfs2+obfs3+flash_proxy<br>
> bundles [6] across all 4 OS/architecture configurations.<br>
><br>
<br>
</div>Building PTTBBs is mainly done by David these days. He has documented<br>
his process here:<br>
<a href="https://gitweb.torproject.org/pluggable-transports/bundle.git" target="_blank">https://gitweb.torproject.org/pluggable-transports/bundle.git</a><br>
(For example for Windows you would look here:<br>
<a href="https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bundle-windows.txt" target="_blank">https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bundle-windows.txt</a>)<br>
<br>
The release process is not standarized. David is doing PTTBB releases<br>
in a best-effort manner.<br></blockquote><div><br></div><div>Right. On first glance, looks like this process will increase in complexity (and utilize more of David's time) as the number of PTs increases.</div><div><br>
</div><div>I need to better understand the build process, then.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
> === Implementing Managed Mode in FTE<br>
> I've implemented preliminary functionality for "managed" mode in FTE.<br>
> However, I think I'm confused about the role of managed mode.<br>
><br>
> Say I add "Bridge fte IP:port" to torrc. Is "IP:port" supposed to be a tor<br>
> bridge, or a server-side PT service? If it's the former, then it seems that<br>
> the PT is completely responsible for managing a list of its own PT servers.<br>
> If it is the latter, I can't figure out how to dynamically determine, via<br>
> the "managed" environmental variables, how to capture user-entered<br>
> "IP:port" information in Vidalia.<br>
><br>
<br>
</div>It is the latter. <IP:port> points to the server-side PT service. It<br>
does *not* point to the ORPort of the bridge (we don't care about it).<br>
<div><br>
> Concretely, if I have "Bridge fte IP1:port" and ""Bridge fte IP2:port" in<br>
> my torrc, how does "IP1:port" and "IP2:port" get propagated to my PT via<br>
> the managed interface?<br>
><br>
<br>
</div>The <IP:port> is *not* passed to your transport using the managed<br>
mode. Instead, <IP:port> is passed to your transport using the SOCKS<br>
protocol. That is, when Tor wants to connect to the bridge, it does a<br>
SOCKS handshake to your transport, and asks your transport to connect<br>
to <IP:port>.</blockquote><div><br></div><div>Is this documented anywhere?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
> === How do we invoke PTs?<br>
> I had this discussion with Roger, but I don't see any open tickets or clear<br>
> discussion on this already. If we have N>1 PTs and at least one bridge per<br>
> PT, how do we select which PT (and which bridge associated with that PT) to<br>
> use? Determinism is bad because then only one PT is used. Booting up all<br>
> PTs is bad, especially if (say) the PTs make network connections prior to<br>
> any incoming SOCKS connections. Selecting a random PT is potentially bad,<br>
> too, depending upon how hostile and persistent and stateful the adversary<br>
> is.<br>
><br>
<br>
</div>That's an interesting question. I'm not sure if the process of Tor<br>
picking bridges is deterministic or not. I should test it out. David<br>
might know.<br>
<br>
(A good scenario would be that Tor treats bridges like guards and<br>
selects some at random to build circuits.)</blockquote><div><br></div><div>We should definitely try to flesh this out.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
> We should probably chat about this. (Maybe you already have and I'm out of<br>
> the loop?) It is especially important as the number of PTs increases.<br>
><br>
> I'm happy to take this discussion (or a subset of it) public, if you think<br>
> it'll help others. I just didn't want to spam tor-dev/tor-assistants with<br>
> this initial email.<br>
><br>
<br>
</div>Yes, let's take it public.<br>
Feel free to CC tor-dev in your next reply.<br></blockquote><div><br></div><div>Done.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
BTW, on the topic of deploying your PT, have you seen:<br>
<a href="https://lists.torproject.org/pipermail/tor-dev/2013-August/005231.html" target="_blank">https://lists.torproject.org/pipermail/tor-dev/2013-August/005231.html</a> ?<br>
<br>
FTE seems to be missing out on the code quality front.<br>
The Python code is quite complex and undocumented. There is also some<br>
C++ code in the codebase that is also complex and undocumented. We<br>
have decided that we won't ship C/C++ code in PTs, except if it's dead<br>
easy to review or if it has gotten heavily scrutinized. Any chance<br>
that the C++ code could be written in a memory-safe language?</blockquote><div><br></div><div>Roughly, FTE has an offline mode (building DFAs, needs to be done once) and an online mode (transporting data, deployed to everyone.) In terms of C++ code, there are ~300 line of C++ code used in online mode that were implemented for performance-critical algorithms. Implementing this code in Python will slow FTE down by at least an order of magnitude. I'll document why I made this decision.</div>
<div><br></div><div>Alternatively, any suggestions for a memory-safe language that allows hooks for Python and affords the same performance as C++?</div>
<div><br></div><div>In terms of reducing complexity of the Python code, and increasing code documentation, do you have concrete suggestions? It would be great if you could raise a few issues on FTE's github [7]. My time is limited and I would prefer to focus on the things you care about.</div>
<div><br></div><div>Thanks,</div><div>Kevin </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div>
> [1] <a href="https://gitweb.torproject.org/pluggable-transports/bundle.git" target="_blank">https://gitweb.torproject.org/pluggable-transports/bundle.git</a><br>
> [2] <a href="https://lists.torproject.org/pipermail/tor-dev/2013-June/005056.html" target="_blank">https://lists.torproject.org/pipermail/tor-dev/2013-June/005056.html</a><br>
> [3] <a href="https://gitweb.torproject.org/builders/tor-browser-bundle.git" target="_blank">https://gitweb.torproject.org/builders/tor-browser-bundle.git</a><br>
> [4] <a href="https://kpdyer.com/fte/" target="_blank">https://kpdyer.com/fte/</a><br>
> [5]<br>
> <a href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt" target="_blank">https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt</a><br>
> [6] <a href="https://www.torproject.org/docs/pluggable-transports.html.en" target="_blank">https://www.torproject.org/docs/pluggable-transports.html.en</a><br>
</div></div></blockquote></div>[7] <a href="https://github.com/redjack/FTE" target="_blank">https://github.com/redjack/FTE</a></div></div>