Thus spake Nick Mathewson (nickm@xxxxxxxxxxxxx): > On Tue, Feb 1, 2011 at 12:08 AM, Mike Perry <mikeperry@xxxxxxxxxx> wrote: > [...] > > > > Appendix: List of key xxx-pluggable-transport.txt shortcomings > > > > 1. This pluggable transport does not need any intelligence or process > > launching on the Client side, aside from a way to tell Tor not to be > > so pedantic about ensuring identity key and IP address consistency. > > What pedanticism exactly do you mean? Matching the IP addr in the > netinfo cell, or something else? I actually don't know the full list there. I think the last time we tried to enumerate this, we decided that "try it and see what actually breaks" was a more efficient approach. > > 2. The relay side needs to be able to detect if it has both the > > permissions and the network ability to send spoofed packets. It needs > > to communicate this fact with the Relay Plugin by responding with the > > appropriate extrainfo lines, or with "METHODS: NONE" to indicate > > error. This relay-side handshake should be specified in the > > pluggable-transport spec. > > To be clear, you mean that the plugin checks whether it can spoof (and > tell Tor "I do nothing!" if it can't), or that Tor needs to find out > whether it can spoof and tell the plugin that whether it can spoof or > not. The first sounds reasonable. The second doesn't so much: most > Tors won't want to try to spoof, so building the checks into Tor > wouldn't make sense to me, unless I'm missing something. Yes, the first is what we want here. > > 3. The relay plugin side needs some way to communicate EXTRAINFO lines > > to be added to its extrainfo descriptor. In this proposal, we use the > > SMETHOD reply to do this. > > Needs spec, not just an example. Ok. Well, does the example I gave look like an instance of what we want to specify as the behavior? > > 4. Is extrainfo really the best place to keep this information? > > Shouldn't it just be in the relay/bridge descriptor? Putting it in > > extrainfo requires our TransportBridges to enable the wasteful > > DownloadExtraInfo=1 torrc setting, which will consume more scarce > > resources and RAM on what will probably be cheap routers with 32-64M > > of RAM. > > Hm. Relay/bridge descriptor should be okay, I guess. I'm not sure > why the TransportBridges are getting those anyway, though: I see why > the client needs it, but not what the transportbridge needs it. The transport bridge should avoid being an open proxy. I suppose it can only properly carry full TCP streams to an endpoint, but without restricting who those endpoints are, it becomes a reflector open to abuse such as portscans. > Also, why are transportbridges even running tor? They don't seem to > be doing anything particularly tor-like. Mostly for the consensus, for reasons above. Not strictly required, if we don't mind being an arbitrary SYN proxy. > > 5. How would we go about chaining an actual obfuscation mechanism with > > this transport? Would we just create new and separate transport called > > TriangleBoyOverHTTP, for example, or is there a better way to chain > > different mechanisms? > > On the client side, socks-over-socks-over-socks is not actually a > terrible way of doing things there. We'll need to distinguish between > which transports are chainable and which aren't, though[*], and maybe > revise the design to make sure there's a way to tell to tell tor to do > said chaining. > > On the server side, you need some way to distinguish which processing > method to do for incoming data. Separate ports seems ok there. We > still need to figure out the server side. > > [*] generally, obfuscation is chainable but transport isn't. This is not a bad generalization. Do we want to make this distinction (between obfuscation vs transport) elsewhere in the spec, I wonder? -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpcNcCSnAsrf.pgp
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev