[tor-bugs] #23662 [Core Tor/Tor]: prop224: Service edge-case where it re-uploads descriptor with same rev counter

[Tor Bug Tracker & Wiki]

#23662: prop224: Service edge-case where it re-uploads descriptor with same rev
counter
-----------------------------+------------------------------------
 Reporter:  asn              |          Owner:  (none)
     Type:  defect           |         Status:  new
 Priority:  Medium           |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor     |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------------
Description changed by asn:

Old description:

> There is an edge case where if a service's HSDir connection times out
> before getting a 200 back, Tor will open a second connection with the
> same `outbuf` as the previous one and retry the upload. See
> `connection_ap_detach_retriable()` which gets called from
> `connection_ap_expire_beginning()`.
>
> That's a problem for v3 HSes, since that logic bypasses the HS subsystem
> and the rev counter does not get incremented for the second upload.
>
> The problem is that if the first connections ends up succeeding (even tho
> it timed out), the second connection will fail because of rev counter
> issues.
>
> This is not a reachability issue since one of the two conns will
> eventually succeed and the right descriptor will be uploaded. However it
> generates a log_warn on the service-side that might be annoying, and a
> log_info on the HSdir side.

New description:

 There is an edge case where if a service's HSDir connection times out
 before getting a 200 back, Tor will open a second connection with the same
 `outbuf` as the previous one and retry the upload. See
 `connection_ap_detach_retriable()` which gets called from
 `connection_ap_expire_beginning()` which detaches the stream from the
 circuit and marks it as pending again.

 That's a problem for v3 HSes, since that logic bypasses the HS subsystem
 and the rev counter does not get incremented for the second upload.

 The problem is that if the first connections ends up succeeding (even tho
 it timed out), the second connection will fail because of rev counter
 issues.

 This is not a reachability issue since one of the two conns will
 eventually succeed and the right descriptor will be uploaded. However it
 generates a log_warn on the service-side that might be annoying, and a
 log_info on the HSdir side.

 The right fix here might involve intercepting that retry, and piping it
 through the HS subsystem. But this will require refactoring.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23662#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online