Opened 14 months ago

Last modified 5 weeks ago

#26300 assigned defect

Attempt by … to open a stream on first hop of circuit. Closing.

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.3.3.6
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

dgoulet says in #24011:
An 0.2.9.15 relay just triggered this on my 0.3.3.6 relay:

Jun 03 17:17:16.642 [warn] Attempt by 94.19.103.117:48914 to open a stream on first hop of circuit. Closing.

The IP address there is a public relay here: ​https://metrics.torproject.org/rs.html#details/65663E6D2E761B0650AC8A3F74F1243209D562DE

Child Tickets

Change History (11)

comment:1 Changed 14 months ago by teor

Cc: dgoulet added
Version: Tor: 0.3.3.6

Let's log what kind of stream (exit or begindir) and which rsa or ed25519 keys the circuit was authenticated with.

comment:2 Changed 14 months ago by teor

Oh, let's also log whether the channel is marked as a client or not.

comment:3 Changed 14 months ago by arma

One scenario where this could happen: that relay used to be a client or a bridge, so it made an unauthenticated connection to dgoulet's relay. Then it changed to becoming a relay, but it kept the original connection open. Then later somebody tried to extend through that connection, and dgoulet's relay freaked out because a request came from an unauthenticated channel.

Suggested fix, option one: when we migrate from being a relay to a non-relay or back, we set the is_bad_for_new_circs flag on that channel, which will make us generate a new connection that authenticates the new way.

Suggested fix, option two: when we're considering whether a given connection is suitable for the circuit we're trying to put on it, we check how we authenticated on that connection, and if we didn't authenticate using the way we want, that isn't an acceptable connection to use for handling that circuit. So in that scenario we'll end up launching a new connection, and authenticating it the way we want.

I like option two because (a) it avoids the terrible situation where somebody toggles their tor to be a relay and not relay and relay and not relay and ... and they accumulate a growing set of connections, all with the is_bad_for_new_circs flag set. And Tim also had a reason for preferring option two. :)

comment:4 Changed 14 months ago by arma

Do we, when establishing a connection (in either direction), remember how we authenticated on it? We have things that remember how the *other* side authenticated. But what about our side?

comment:5 Changed 14 months ago by arma

Also, compatible with that log line is the possibility that that IP address has both a relay and a client on it, and the client made a (not authenticated, because it can't authenticate) channel to us, and then attempted a single-hop exit. No idea if that's what happened here, but it's compatible with that log line.

comment:6 Changed 13 months ago by dgoulet

Cc: dgoulet removed
Owner: set to dgoulet
Status: newassigned

comment:7 Changed 13 months ago by dgoulet

Status: assignedneeds_information

Oook... I've contacted one of the relay operator for which this warning came from to validate a series of theories like "Is the relay being used as a hidden service or/and client?"... Did the config changed when the warning appeared. And other questions like that.

I hope we'll get more information so I can try to reproduce this and understand it. For now, I'll put that in needs_information since I do not know how to go forward on this one without a way to reproduce.

comment:8 Changed 13 months ago by dgoulet

So relay operator responded. The gist is that they had a normal relay. They stopped it, then changed the configuration to become a bridge and start it again.

Somehow, my Guard node (who saw the warning) still had a channel object for that relay or some state that made it think it is a relay which triggered that warning...

comment:9 Changed 11 months ago by nickm

Keywords: fast-fix removed
Milestone: Tor: 0.3.4.x-finalTor: 0.3.6.x-final

comment:10 Changed 9 months ago by dgoulet

Milestone: Tor: 0.3.6.x-finalTor: unspecified

comment:11 Changed 5 weeks ago by gaba

Owner: dgoulet deleted
Status: needs_informationassigned

Releasing some old tickets.

Note: See TracTickets for help on using tickets.