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

dgoulet says in #24011 (moved): 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

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified priority::medium severity::normal status::new type::defect version::tor 0.3.3.6 labels

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

Trac:
Cc: N/A to dgoulet
Version: N/A to Tor: 0.3.3.6

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

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. :)

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?

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.

Trac:
Owner: N/A to dgoulet
Status: new to assigned
Cc: dgoulet to N/A

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.

Trac:
Status: assigned to needs_information

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...

Trac:
Keywords: fast-fix deleted, N/A added
Milestone: Tor: 0.3.4.x-final to Tor: 0.3.6.x-final

Trac:
Milestone: Tor: 0.3.6.x-final to Tor: unspecified

Releasing some old tickets.

Trac:
Owner: dgoulet to N/A
Status: needs_information to assigned

Change tickets that are assigned to nobody to "new".

Trac:
Status: assigned to new

moved to tpo/core/tor#26300 (closed)