Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4788 closed defect (implemented)

Reject all relays and bridges running 0.2.0.x

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

Description

If we are going to start enforcing proposal 110's requirement that EXTEND relay commands only be sent inside RELAY_EARLY cells (#4339), we must remove all servers (both relays and bridges) running Tor 0.2.0.x from the network.

This needs to be a dirauth-only change; clients and non-dirauth servers must still accept and mirror descriptors for 0.2.0.x servers.

Child Tickets

Attachments (2)

version_bw_summary (715 bytes) - added by nickm 7 years ago.
summary of Bandwidth= values by declared version in current consensus
old_relays.txt (21.6 KB) - added by atagar 7 years ago.
fingerprint/version/contact for relays prior to 0.2.1.30

Download all attachments as: .zip

Change History (15)

Changed 7 years ago by nickm

Attachment: version_bw_summary added

summary of Bandwidth= values by declared version in current consensus

comment:1 Changed 7 years ago by nickm

Attached is a quick summary of how the total Bandwidth= lines in the consensus break down by version. About .0005 of the total (that's 5% of 1%!) is in versions 0.2.0.x. About 2% of the total bandwidth is on versions of 0.2.1.x before 0.2.1.30.

By server count, this works out to 20 of 2367 listed servers on 0.2.0.x, and 214 of 2367 on 0.2.1.x before 0.2.1.30.

I say that we should have the authorities stop voting for anything before 0.2.1.30.

comment:2 Changed 7 years ago by atagar

Minor question from the peanut gallery - are we gonna be notifying the people with contact info? If we go through with this then I'd be happy to handle that.

comment:3 Changed 7 years ago by arma

The proposal 110 first half went into 0.2.1.3-alpha, and a bugfix went into 0.2.1.19. So to accomplish the goal described here, we should change dirserv_get_status_impl() from

  /* Tor 0.2.0.26-rc is the oldest version that currently caches the right
   * directory information.  Once more of them die off, we should raise this
   * minimum. */
  if (platform && !tor_version_as_new_as(platform,"0.2.0.26-rc")) {
    if (msg)
      *msg = "Tor version is far too old to work.";
    return FP_REJECT;
  } else if (platform && tor_version_as_new_as(platform,"0.2.1.3-alpha")
                      && !tor_version_as_new_as(platform, "0.2.1.19")) {
    /* These versions mishandled RELAY_EARLY cells on rend circuits. */
    if (msg)
      *msg = "Tor version is too buggy to work.";
    return FP_REJECT;
  }

to

  /* Tor 0.2.1.3-alpha introduced the RELAY_EARLY enforcement, and
   * 0.2.1.19 fixed a bug that mishandled RELAY_EARLY cells on rend
   * circuits. */
  if (platform && !tor_version_as_new_as(platform,"0.2.1.19")) {
    if (msg)
      *msg = "Tor version is far too old to work.";
    return FP_REJECT;
  }

If we prefer to be more thorough, we might append

  } else if (platform && !tor_version_as_new_as(platform,"0.2.1.30")) {
    /* These versions have security vulnerabilities that make them too
     * risky to include. */
    if (msg)
      *msg = "Tor version is vulnerable. Please upgrade!";
    return FP_REJECT;
  }

I'd be ok with that.

Changed 7 years ago by atagar

Attachment: old_relays.txt added

fingerprint/version/contact for relays prior to 0.2.1.30

comment:4 Changed 7 years ago by atagar

I have a slightly higher count than nickm from my cached descriptor (257 relays prior to version 0.2.1.30), see attached. Of those 107 have some sort of contact information set. Notifying them...

comment:5 Changed 7 years ago by nickm

thanks for sending out that email! We should also tell tor-relays and tor-talk for good measure before we deploy this.

comment:6 Changed 7 years ago by nickm

If we're killing everything that is vulnerable to CVE-2011-0427 , we should also reject 0.2.2.1-alpha through 0.2.2.20-alpha inclusive. That's not much bandwidth (less than 1/1000 of the total); it's also only ~8 servers.

If we were feeling bold, we could require that 0.2.2.x tors be 0.2.2.30-rc or later; that would reject 9 more servers and almost no more bandwidth.

comment:7 Changed 7 years ago by nickm

Status: newneeds_review

See branch bug4788 in my public repository

comment:8 Changed 7 years ago by atagar

We should also tell tor-relays and tor-talk for good measure before we deploy this.

Good idea, done.

If we're killing everything that is vulnerable to CVE-2011-0427, we should also reject 0.2.2.1-alpha...

When we're sure of what we're dropping I'll contact them too.

Cheers! -Damian

comment:9 Changed 7 years ago by nickm

Since I don't currently have a reason to reject 0.2.2.21-alpha through 0.2.2.30-rc (other than "there are not many of them!"), I am going to say "no" on that one, and go with the approach from my bug4788 branch.

So the rejected versions are just going to be "everything that suffers from CVE-2011-0427". That is,

  • Everything before 0.2.1.30. [So 0.2.1.30 is the first allowed version.]
  • Everything from 0.2.2.1-alpha through 0.2.1.20-alpha (inclusive). [So 0.2.2.21-alpha is the first allowed 0.2.2.x version.]

Also, I've merged the bug4788 branch into the repo.

comment:10 Changed 7 years ago by atagar

Everything from 0.2.2.1-alpha through 0.2.1.20-alpha (inclusive).

Minor typo, should be '0.2.2.1 through 0.2.2.20'. I'm spotting ten relays in that range, three with contact info...

1. DA9375C27869639525531BC367152C7AF8B8CC44
  version: 0.2.2.20-alpha

2. 6C971352BE4A9282BBBF33E41900A5EF437E817E
  version: 0.2.2.15-alpha

3. 44375B37C584AEC75FB1490D9A8605C69DBE0631
  version: 0.2.2.15-alpha

4. 7F99B1B2FC1661CF7D280B23D4EAFA6673E7F0DF
  version: 0.2.2.15-alpha

5. F69BB942FA90661F2EB9BC36C8C084E53C466C11
  version: 0.2.2.13-alpha

6. A58E0F05C1939725D7247BA60BA3135DB88209BC
  version: 0.2.2.10-alpha

7. 07C022756545E9764E0E9511114AF196811DF396
  version: 0.2.2.13-alpha
  contact: TOR Master <tormaster@as1101.net>

8. 6DBE31F8132CE1516F36E54DABDC7EF4FB6472B9
  version: 0.2.2.15-alpha
  contact: bobtaser at gmail dot  com

9. 029C90B4F3FFA9070A58A98C8BFB100AD85D5E9B
  version: 0.2.2.15-alpha

10. ED4A9ECD7351D697CBEEB7BB785D3B326073EDE6
  version: 0.2.2.13-alpha
  contact: second dot cummings at gmail dot com

3 of 10 have contact info

Sent a notice to them.

comment:11 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

ok. I think we can call this closed then. Thanks, atagar!

comment:12 Changed 7 years ago by nickm

Keywords: tor-auth added

comment:13 Changed 7 years ago by nickm

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