Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #23080
Closed (moved) (moved)
Open
Created Aug 02, 2017 by David Fifield@dcf

connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the format of ExtORPort USERADDR

(Originally noticed in comment:3:ticket:18628.)

Proposal 196, which defines the ExtORPort protocol, implies that the USERADDR command must include a port number, here:

     [0x0001] USERADDR: an address:port string that represents the
       client's address.

and here:

3.1.2.1. USERADDR

  An ASCII string holding the TCP/IP address of the client of the
  pluggable transport proxy.

But connection_ext_or_handle_cmd_useraddr calls tor_addr_port_split, which makes the port number optional.

It seems that connection_ext_or_handle_cmd_useraddr in fact accepts all these formats for USERADDR:

  • 1.2.3.4 (implied port=0)
  • 1.2.3.4:5678
  • 1:2::3:4 (implied port=0)
  • [1:2::3:4] (implied port=0)
  • [1:2::3:4]:5678 If this is intended, then I'd like proposal 196 to say that the port is optional, and square brackets are optional in the case of IPv6.

For what it's worth, obfs4proxy and meek-server take proposal 196 at face value and always include a port in USERADDR (meek-server always uses the fictitious port number 1 because it doesn't know the true remote port).

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking