Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#4339 closed task (implemented)

Turn on the last part of proposal 110

Reported by: nickm Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: #2664 Points:
Reviewer: Sponsor:

Description

Tor 0.2.0.x is finally dead, as are the early, broken alphas of Tor 0.2.1.x. Let's see if we can enable the proposal 110 defenses at long last.

I'm targetting this for 0.2.3.x, but arma could easily convince me it was backportable to 0.2.2.x, so I'm going to base my branch there.

(I thought we had a ticket for this, but can't find it.)

Child Tickets

Change History (18)

comment:1 Changed 7 years ago by nickm

Status: newneeds_review

Please review branch "prop110" in my public repository, and test it on a relay or two.

Keep a lookout in your logs for warnings of the form: "EXTEND cell received, but not via RELAY_EARLY. Dropping". That means that a client without prop110 support sent you an extend cell, but did it wrong.

Open questions:

  • Are there still clients that don't do RELAY_EARLY right?
  • Do we care?
  • Instead of dropping the cell, should we destroy the circuit?

comment:2 Changed 7 years ago by Sebastian

Oct 29 02:44:51.808 [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. [34 similar message(s) suppressed in last 900 seconds]
Oct 29 03:00:36.188 [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. [29 similar message(s) suppressed in last 900 seconds]
Oct 29 03:15:39.471 [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. [28 similar message(s) suppressed in last 900 seconds]
Oct 29 03:30:49.401 [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. [36 similar message(s) suppressed in last 900 seconds]

comment:3 Changed 7 years ago by nickm

Hrm. I probably should have had it count the number of non-dropped EXTEND cells too so we know what fraction of users would be affected by this.

Okay, here are the possibilities to consider:

  • These are very old versions of Tor that some users are still running. We totally expect 0.2.0.x to break, for instance.
  • These are not-so-old (0.2.1.x and later) versions of Tor, but they're buggy here in a way we didn't expect. We should double-check that 0.2.1.x and later do the right thing.
  • This is one of the Tor clients that we didn't make -- jtor or onioncoffee or silvertunnel or something. We

Time for testing, I guess. From a quick look at the source, it seems that silvertunnel doesn't support RELAY_EARLY. (At least, Cell.java has other cell types, but not RELAY_EARLY. Not VERSIONS or NETINFO either, afaict.) And JTor has RELAY_EARLY in its list of cell types, but afaict it never actually uses it (if I'm looking at the right version of the source).

So this might just be nonconformant clients.

Oh, are they nonconformant? To be fair, the spec says only:

   When speaking v2 of the link protocol or later, clients MUST only send
   EXTEND cells inside RELAY_EARLY cells.

so that would seem to imply that if you don't upgrade to v2 protocol support, you don't have to use RELAY_EARLY cells. But then the spec turns around and says:

   [In a future version of Tor, relays will reject any EXTEND cell not
   received in a RELAY_EARLY cell.  See proposal 110.]

so it's not like anybody can say we didn't warn them we'd break eventually.

So I think our next steps here are to contact jtor (hi Bruce!) and silvertunnel people (hi silvertunnel people!) and let them know that we're thinking of doing this migration on the 0.2.3.x timeframe, so they aren't blindsided. Then we should investigate our own clients and make sure that nothing supported will break. And I should tweak that log message to say how many cells _did_ go through.

Thoughts?

comment:4 Changed 7 years ago by arma

Type: enhancementtask

Sounds like we should be sure, in the next 0.2.2 stable announcement, to say that 0.2.0 is end-of-life. (It is and has been for a while, but we never said it.)

comment:5 Changed 7 years ago by nickm

arma wisely suggests that we should make this controlled with a consensus parameter.

comment:6 Changed 7 years ago by nickm

We've made the announcement that 0.2.0 is dead (as of the 0.2.2.35 release announcement). I have pushed a new rebased "prop110_v2" branch that ignores the no-nonearly-extend-cells if the consensus parameter "AllowNonearlyExtend" is set.

I think we should merge this now. Thoughts?

comment:7 Changed 7 years ago by arma

Merge sounds good to me.

Just as an afterthought: clients that do the old thing will keep trying to make circuits, since they want to have some preemptive circuits up and for some reason they can't establish them. How painful will this be? I think it will just be 5 circuit attempts per minute per such client (for an hour after the client starts or tries to open a stream). And once the guards upgrade, there won't be much cpu involved in failing the circuits (since the clients will use create_fast for the first hop and get refused when they attempt to extend to the second hop). Sound about right? It's a shame that they can't be told to back off.

comment:8 Changed 7 years ago by arma

<Sebastian> 16:53 < wanoskarnet> Statement "V1 connections don't understand
RELAY_EARLY." is incorrect, more correct is -- Tor implementation that can
talk v1 only don't understand EARLY. Did you know you can still to send
relay_early over v1 if you could rewrite client? is it some
forwadrbackwardrighttoleftcompatibility?
<Sebastian> 17:13 < wanoskarnet> Did you know 40 of 0.2.0.x currently working
relays will work like diode for building circuits with 110v2? depends
position it will or not will to works.

comment:9 Changed 7 years ago by arma

I totally expect some weird behavior as parts of the network upgrade here.

A) As relays upgrade, they will prevent people from doing long-path attacks through them. Good.

B) As relays upgrade, old clients will concentrate their circuits on the ones that haven't upgraded. Bad.

At some point we may find ourselves wanting to cut relays out of the network that don't enforce the relay_early semantics. I don't think we're anywhere close to there yet.

comment:10 Changed 7 years ago by arma

Merged it. Nick, please close once you've read these comments and you're satisfied.

comment:11 Changed 7 years ago by arma

also, consider whether it should go into 0.2.2 also. I'm not sure.

comment:12 Changed 7 years ago by Sebastian

As merged, the code will print a warn on all guards almost every 15 minutes (like this one [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. [38 similar message(s) suppressed in last 900 seconds])

comment:13 Changed 7 years ago by nickm

I am against merging this into 0.2.2. If we need to think about it this much, a backport is the wrong answer.

I'm making the message a protocol_warn, and bumping the interval to 1 hour.

We should kick all 0.2.0.x Tors out of the consensus. Can somebody open a ticket for that?

I will open a ticket for wanoskarnet's issue. (See append_cell_to_circuit_queue for the location of the ticket.)

comment:14 in reply to:  13 Changed 7 years ago by nickm

Replying to nickm:

I will open a ticket for wanoskarnet's issue. (See append_cell_to_circuit_queue for the location of the ticket.)

This is #4786 . The impact there is that we don't ever send RELAY_EARLY cells over a v1 connection with any current version of Tor, since we expect that v1 connections mean "0.2.0.x or earlier." So if any party in the circuit has negotiated a v1 connection, we'll get the extend cells rejected. Even with a #4786 fix, we'll have the problem if any party but the first has not upgraded, and negotiates a v1 connection. This doesn't seem to be a frequent occurrence, though.

comment:15 in reply to:  13 Changed 7 years ago by rransom

Replying to nickm:

We should kick all 0.2.0.x Tors out of the consensus. Can somebody open a ticket for that?

#4788

comment:16 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Okay, all remaining issues have tickets, and all those are tickets are closed. Closing this one as implemented.

comment:17 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:18 Changed 6 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.