[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.



#11211: Multiple ServerTransportListenAddr entries should be allowed per transport.
-------------------------------------------------+-------------------------
 Reporter:  yawning                              |          Owner:
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  unspecified
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-bridge, pt, needs-proposal,      |  Actual Points:
  tor-pt, bridgedb-parsers, 028-triage, ipv6,    |
  tor-03-unspecified-201612                      |
Parent ID:  #10629                               |         Points:
 Reviewer:                                       |        Sponsor:  T/U
-------------------------------------------------+-------------------------

Comment (by kaie):

 I'm trying to contribute a fix for this issue.

 Would it be acceptable to use a different configuration syntax, that uses
 only a single line for each transport type, and allows multiple
 address:port combinations to be listed on the line, separated by space, as
 in the following example?

   ServerTransportListenAddr obfs3 0.0.0.0:443 [::]:443

 I discovered that the obfs4proxy tool already supports multiple addresses
 for the same transport type, as it already parses a comma separated list
 of type-address:port entries, which are passed to it by Tor in an
 environment variable.

 Looking at the Tor C code, it seems that many places assume that only a
 single configuration line (and state line) is used for any given transport
 type. My impression is, implementing the syntax I'm suggesting requires a
 much smaller amount of code changes.

 I'll attach an initial attempt to implement the above. It parses the above
 syntax, it passes the extended list to the external transport tool. It
 also saves extended TransportProxy lines into the state file, using the
 same approach that keeps a single line and allows multiple addresses.

 So far I've only tested with a test network, and only tested that the
 listeners are created. I haven't done real world testing yet.

 The code that loads and validates the state file only checks the first
 stored address:port, and will use the additional saved entries without
 validation. I've ran out of time today, this is a TODO.

 Looking forward to your feedback.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11211#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs