Opened 11 months ago

Last modified 10 months ago

#32743 new defect

Remove tor-spec requirement of initiator-side V1 and V2 link handshakes

Reported by: opara Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, tor-spec
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


The tor spec says the following (section "2. Connections"):

In either case, once the responder has sent its certificate or certificates, the initiator counts them. If two certificates have been sent, it proceeds as in "certificates up-front"; otherwise, it proceeds as in "renegotiation" or "in-protocol".


To decide whether to do "renegotiation" or "in-protocol", the initiator checks whether the responder's initial certificate matches the criteria listed above.


All new relay implementations of the Tor protocol MUST support backwards-compatible renegotiation

Since the initiator can be a client or relay, I take this to mean that relays must allow V1 and V2 handshakes if the responder does not support a higher handshake version.

The tor code removed initiator support for V1 and V2 handshakes in #11150 for clients and relays. Since the official tor implementation does not support these handshakes for initiators, I don't see a reason to keep it in the spec. It also makes the code difficult to follow, and I've been confused looking at the code trying to understand how the initiators respond to these handshakes (assuming they did since it's in the spec), but it wasn't until finding the ticket above that I learned that it's been removed. So I think removing this requirement from the tor spec removes this discrepancy between tor and tor-spec, and also generally makes things more clear.

Child Tickets

Change History (4)

comment:1 Changed 11 months ago by nickm

Keywords: needs-proposal added

This is worth doing, but it needs a proposal; see "proposals/001-process.txt" for more information on the proposal process.

One reason it needs a proposal is that we need to avoid a so-called "fast zombies" problem; see proposal 266 for an introduction to that one. (But proposal 266 is from back in 2016, and should be superseded by proposals 264 and 272.)

We will have substantially more latitude here once 0.2.9 becomes unsupported in early 2020.

Would you be interested in working on an updated proposal here to try to figure out how to manage the transition here without causing a zombie swarm of old clients?

comment:2 Changed 11 months ago by nickm

I've asked Roger for stats on moria, and he reports that v1 connections received are only around .008% of total connections received, but v2 connections are about 3% of connections received. That latter is big enough that we should make sure that zombie v2 clients don't overwhelm the network.

comment:3 Changed 11 months ago by opara

I think we might be talking about two slightly different things here? This ticket is about changing tor-spec to match tor, with no changes to the tor code itself. So v1 and v2 handshakes would still be supported by responders (as they are now), but since v1 and v2 handshakes are no longer supported by initiators in the tor code, only that initiator requirement would be removed from tor-spec. It seems like you might be discussing dropping support for v1 and v2 altogether (which would require changes to the tor code)?

comment:4 Changed 10 months ago by dgoulet

Keywords: tor-spec added
Milestone: Tor: unspecified
Note: See TracTickets for help on using tickets.