Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
Tor
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,067
    • Issues 1,067
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 17
    • Merge Requests 17
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • 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
  • Core
  • Tor
  • Issues
  • #25139

Closed
Open
Opened Feb 04, 2018 by Damian Johnson@atagar

Link protocol negotiation without common version

Hi lovely core tor folks. I'm presently teaching Stem to communicate over tor's ORPort, and wanted to check about edge case behavior I ran into with the integ tests.

The first step of establishing an ORPort connection is to negotiate the protocol. This is done by...

  • Sending a VERSIONS cell with the link protocol versions we support.
  • Receive a VERSIONS cell in reply with versions the other side supports.
  • All further cells are formatted using the highest common link protocol version.

This is all well and good, but when there isn't a common link protocol version the sender never receives a VERSIONS reply. That is to say, if I send a VERSIONS cell with 3, 4, or 5 things work, but if I send a cell with only other values (1, 2, 6, 20, etc) negotiation terminates right away.

The tor-spec is clear that the connection will be closed, but not if the caller should expect a VERSIONS reply...

If they have no such version in common, they cannot communicate and MUST close the connection.

Personally I have a slight preference for the sender to get a VERSIONS reply, then mutually close the socket. This way the caller will know why the connection was closed...

  • "They're a newer tor version than me and only speak higher protocol versions."

... verses...

  • "This is a really old relay that doesn't speak modern protocol versions."

Just food for thought. I'm not heartbroken that connections end right away - just makes for a vague error response to the user.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/core/tor#25139