Opened 5 years ago

Last modified 8 months ago

#10629 new enhancement

PT spec changes for better interoperability with other projects

Reported by: infinity0 Owned by: yawning
Priority: Medium Milestone: Tor: unspecified
Component: Obfuscation/Pluggable transport Version:
Severity: Normal Keywords: SponsorS, pt-spec, pt-ng, pt-v2, tor-pt
Cc: thomasf@…, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by infinity0)

I spoke with the i2p guys today and here are some of their suggestions for the PT spec. These would make it easier for them (and future other projects) to use Tor's PTs.

Major improvements:

  • better spec documentation
    • less Tor jargon, split Tor-specific information into separate sections (e.g. Tor env vars)
    • some guidelines for non-Tor programs to use PTs
  • better handling of per-endpoint config params such as pubkeys, instead of current hack via SOCKS auth params

Smaller enhancements, "good to have":

  • possibility of letting a single process to act as both a client (outgoing) and server (incoming).
  • flashproxy must allow client-specific remote endpoints (already as #10196)
  • don't trust the entire localhost machine to make outgoing connections, e.g. if one users wants to run his own instance. two options here:
    • SSL connection with user/pass to the SOCKS transport client
    • use unix domain sockets. This also frees up ports, which is extra-useful in PT composition. Doesn't work on windows, though.

Child Tickets

TicketTypeStatusOwnerSummary
#7153projectnewDon't require pluggable transport proxies to be SOCKS proxies
#9163defectclosedRemove PT SOCKS argument length limit when SOCKS4 is used
#10047enhancementclosedasnPTs could self-shutdown when they detect their stdout is closed
#10671enhancementnewPluggable Transports: Improve method of transferring parameters to client-side transports
#11211enhancementassignednickmMultiple ServerTransportListenAddr entries should be allowed per transport.

Change History (22)

comment:1 Changed 5 years ago by infinity0

Owner: set to infinity0
Status: newassigned

comment:2 in reply to:  description Changed 5 years ago by nickm

This is pretty excellent; it will be good to drill down into these requirements more.

In my mind the biggest issue to consider here is backward compatibility: we want all the old PTs to keep working, and I2P probably wants to work with most (all?) of the old PTs, so we should make sure that any design decisions we make allow that.

With that in mind...

Replying to infinity0:

  • better spec documentation
  • less Tor jargon, split Tor-specific information into separate sections (e.g. Tor env vars)

Good idea. In particular, we should describe which of the TOR_* variables are actually Tor-specific, and which are just using our namespace.

  • some guidelines for non-Tor programs to use PTs

Right.

  • possibility of letting a single process to act as both a client (outgoing) and server (incoming).

That shouldn't be so hard.

[...]

  • better handling of per-endpoint config params, such as pubkeys (instead of current hack via SOCKS auth params)

This is one of the cases where we need to think about compatibility. I2P would need to support the SOCKS hack already if it wants to work with any existing PTs that use it, and PTs will need to support the SOCKS hack in the future if they want to work with existing versions of Tor.

It's okay to add a new message-passing framework, or to clean up the existing protocols into something cleaner, but as we do so we need to let old PTs continue to work, and we should make sure that we're actually creating less work for implementors of Tor, I2P, and PTs in the long run, rather than more.

  • SSL connection with user/pass to SOCKS client; currently we assume cleartext

This is possible as an extension, though IMO you should never run this on a remote system, so cleartext is fine.

  • (my own suggestion) allow unix domain sockets

Doable.

comment:3 Changed 5 years ago by nickm

Component: Pluggable transportTor

I'm moving this into the "Tor" milestone since we manage specs that describe what Tor does (and in the Tor spec) in terms of the Tor component.

comment:4 Changed 5 years ago by infinity0

Description: modified (diff)

Restructured the description to make it clear which ones are important vs optional.

comment:5 Changed 5 years ago by infinity0

Description: modified (diff)

comment:6 Changed 5 years ago by infinity0

I clarified the SSL SOCKs connection with the i2p devs. The intention isn't to use PT clients remotely, but rather to avoid giving access to other non-privileged users on the localhost machine.

So, for example, plaintext authentication to the PT client would work as well, assuming that non-priv users can't sniff traffic on localhost interfaces. (Not sure if this clashes with the current use of SOCKS auth for other things though.)

And to re-state, this is a minor point and is not intended to block them integrating or working with PTs. But it's something to keep in mind during this design work.

comment:7 in reply to:  6 Changed 5 years ago by yawning

Replying to infinity0:

I clarified the SSL SOCKs connection with the i2p devs. The intention isn't to use PT clients remotely, but rather to avoid giving access to other non-privileged users on the localhost machine.

So, for example, plaintext authentication to the PT client would work as well, assuming that non-priv users can't sniff traffic on localhost interfaces. (Not sure if this clashes with the current use of SOCKS auth for other things though.)

That's the case for every common OS out there (If someone makes tcpdump suid root, they get what they deserve), including Windows. I assume this is more of a defense in depth thing, since the traffic they pass over a PT should be encrypted anyway....

comment:8 Changed 5 years ago by asn

This might be diverting from "help other projects adopt PTs" to "how to improve the PT design", but here are some more things that should be improved:

  • Logging support. It's not clear how obfsproxy/etc. opreators are supposed to do logging atm, and it's not clear where the log file should be written. Solutions here include passing the log messages to Tor somehow, or forcing PTs to implement syslog support (or log in pt_state), or something like that.
  • It might also be worth standardizing the PT CLI interface. So for example, all PTs should use --log-file to specify a logfile and --log-min-severity to specify the logging severity (those were example names: it's what obfsproxy uses and they are awful). This might help in adding some sort of torrc switch which enables debug logging for all pluggable transports, for example.

comment:9 Changed 5 years ago by infinity0

Grouping in #10047.

comment:10 in reply to:  8 Changed 5 years ago by dcf

Replying to asn:

  • Logging support. It's not clear how obfsproxy/etc. opreators are supposed to do logging atm, and it's not clear where the log file should be written. Solutions here include passing the log messages to Tor somehow, or forcing PTs to implement syslog support (or log in pt_state), or something like that.

Apart from the question of where to write log files, it would be very nice if transports could tell tor to log something (so that it will end up in the log that Tor Launcher copies to the clipboard, for example).

tor keeps the stdout of each plugin process open; how about we add commands like

LOG DEBUG Received SOCKS connection.
LOG WARN Unable to find any foobars, this transport probably won't work.

tor could then copy those lines into its own log, prefixed by the transport name.

comment:11 Changed 5 years ago by nickm

BTW, if anybody's going to be at the hack day in Iceland next week, it would be cool to have a ~40 minute meeting to go through all this stuff. Can somebody agree to lead it, if so?

comment:12 in reply to:  11 Changed 5 years ago by asn

Replying to nickm:

BTW, if anybody's going to be at the hack day in Iceland next week, it would be cool to have a ~40 minute meeting to go through all this stuff. Can somebody agree to lead it, if so?

Yeah, I can do that.

comment:13 Changed 5 years ago by nickm

Milestone: Tor: 0.2.???

comment:14 Changed 4 years ago by yawning

Parent ID: #16755

comment:15 Changed 4 years ago by yawning

Component: TorPluggable transport
Keywords: SponsorS pt-spec added
Owner: changed from infinity0 to yawning

comment:16 Changed 4 years ago by thomasfr

Cc: thomasf@… added

comment:17 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:18 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:19 Changed 22 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:20 Changed 22 months ago by nickm

Keywords: pt-ng pt-v2 tor-pt added
Severity: Normal

comment:21 Changed 19 months ago by yawning

Parent ID: #16755
Status: assignednew

comment:22 Changed 8 months ago by dmr

Cc: dmr added
Note: See TracTickets for help on using tickets.