Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 50
    • Issues 50
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
    • A
      Anti-censorship
  • Pluggable Transports
  • trac
  • Issues
  • #7153

Closed
Open
Opened Oct 19, 2012 by Karsten Loesing@karsten

Don't require pluggable transport proxies to be SOCKS proxies

(Re-using text from Zack Weinberg for this description.)

There are pluggable transport proxies that don't actually act as a SOCKS proxy. For example, StegoTorus has its own configuration; it ignores everything told it in the SOCKS dialogue and always connects to the bridge that it knows about. If you want multiple StegoTorus bridges accessible to your Tor client, you need multiple "ClientTransportPlugin ... exec" specifications. This is only going to get worse when they move away from having everything set up on StegoTorus' command line, which has been direly needed for some time now.

Theoretically all of StegoTorus' configuration could be encapsulated in the SOCKS key-value-pairs-in-the-password hack that's described in 180-pluggable-transport.txt, but they never implemented that and they don't want to. They want to rip out all of the SOCKS code, in fact. The way they want it to work is

Bridge storus1 direct [keyid=...]
ClientTransportPlugin storus1 direct 127.0.0.1:8888

In this case, 'storus1' is not a "method", it's a human-readable identifier for the bridge that Tor will be connected to if it starts talking the OR protocol -- with no initial SOCKS exchange! -- on 127.0.0.1:8888.

"direct" should also be valid in CMETHOD/SMETHOD lines for the proxy-management protocol, with the same semantics. Zack says he hasn't really thought through how the server side of this stuff ought to work.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/anti-censorship/pluggable-transports/trac#7153