> On 21 Jun 2017, at 14:27, David Fifield <david@xxxxxxxxxxxxxxx> wrote: > > On Wed, Jun 21, 2017 at 01:16:20PM +1000, teor wrote: >> In general, is there a separate document or proposal that describes >> how Tor will implement the relevant interfaces? There doesn't seem >> to be much on Tor-specific issues in this spec. >> >> There is one "Tor" note in the spec, maybe it should be in that >> separate document? Or maybe there should be more Tor notes in the >> spec? > > As I understand it, one of the goals of the PT 2.0 spec is to make it > easier for projects *other* than Tor to use pluggable transports. The > current spec (the 1.0 spec) basically doesn't work for anyone other than > desktop Tor-... There are also edge cases where it works badly even for desktop Tor. >> On 21 Jun 2017, at 13:16, teor <teor2345@xxxxxxxxx> wrote: >> >> I ask because we have had some issues in Tor with PT 1.0, >> because Tor Browser uses a fake IPv4 address for transports like meek. >> This interacts really badly with ReachableAddresses and similar. >> >> Any new Tor code will need to resolve this issue by using non-address >> identifiers or a defined placeholder address. >> >> We have also had bugs where tor connects to the actual bridge address >> rather than a proxy. So using a placeholder address for all PTs might >> be a good idea for security in tor. >> Tor users often configure ReachableAddresses (or similar) and expect >> pluggable transports to respect them. Is there a standard way of >> telling a transport which addresses it can't connect to? >> >> Or, alternately, is there a standard way for a transport to tell tor >> which addresses it is actually using *before* it connects to it? > If I understand correctly, Tor wouldn't have to implement glue code to > interface with the Go API. It could continue spawning subprocesses, > similar to what it does now. The executables it invokes, if they are > written in Go, will likely internally use a PT library that uses the 2.0 > spec's API, but Tor wouldn't have to know those details. I wasn't talking about interfaces, I was talking about the configs exchanged via the protocol regardless of interface. If we want to fix some of these application issues, we need to make sure the protocol provides the means to do so. Regardless of how tor interfaces or updates its PT interface. > PT 1.0 succeeded in being "pluggable" in one sense: it's easy to hotswap > a lot of circumvention technologies within Tor. But it failed in being > "pluggable" in another sense: it's not easy to share common transport > modules beyond Tor (in either direction). It would be great if the new > spec can realize that second sense of pluggability. It would be great if this new spec could also fix some of the issues around transport addresses, regardless of the application using it. Or, we could rule those issues explicitly out of scope, essentially pushing them onto each individual transport and application to deal with in a custom manner. (Or, more likely, to ignore.) For example: >> The client protocol is missing a standard way to configure: >> * a local bind address >> * a remote server address >> * other common PT info >> >> Is this intentional? >> If so, do we really want each transport defining its own slightly >> different JSON keys for common items like addresses? >> Even worse, what if they format addresses inconsistently? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev