[tor-commits] [torspec/master] Add my removing-obsolete-clients proposal as 266
nickm at torproject.org
nickm at torproject.org
Thu Jan 14 16:24:20 UTC 2016
commit 99acfe0bb19f0a0bcb7c1ec4866c817d91ade7c8
Author: Nick Mathewson <nickm at torproject.org>
Date: Thu Jan 14 11:24:16 2016 -0500
Add my removing-obsolete-clients proposal as 266
---
proposals/000-index.txt | 2 +
.../266-removing-current-obsolete-clients.txt | 204 ++++++++++++++++++++
2 files changed, 206 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 718dd31..411093b 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -186,6 +186,7 @@ Proposals by number:
263 Request to change key exchange protocol for handshake v1.1 [OPEN]
264 Putting version numbers on the Tor subprotocols [OPEN]
265 Load Balancing with Overhead Parameters [DRAFT]
+266 Removing current obsolete clients from the Tor network [DRAFT]
Proposals by status:
@@ -213,6 +214,7 @@ Proposals by status:
259 New Guard Selection Behaviour
260 Rendezvous Single Onion Services
265 Load Balancing with Overhead Parameters
+ 266 Removing current obsolete clients from the Tor network
NEEDS-REVISION:
190 Bridge Client Authorization Based on a Shared Secret
OPEN:
diff --git a/proposals/266-removing-current-obsolete-clients.txt b/proposals/266-removing-current-obsolete-clients.txt
new file mode 100644
index 0000000..3d8a6c3
--- /dev/null
+++ b/proposals/266-removing-current-obsolete-clients.txt
@@ -0,0 +1,204 @@
+Filename: 266-removing-current-obsolete-clients.txt
+Title: Removing current obsolete clients from the Tor network
+Author: Nick Mathewson
+Created: 14 Jan 2016
+Status: Draft
+
+
+1. Introduction
+
+ Frequently, we find that very old versions of Tor should no longer be
+ supported on the network. To remove relays is easy enough: we
+ simply update the directory authorities to stop listing relays that
+ advertise versions that are too old.
+
+ But to disable clients is harder.
+
+ In another proposal I describe a system for letting future clients go
+ gracefully obsolete. This proposal explains how we can safely
+ disable the obsolete clients we have today (and all other client
+ versions of Tor to date, assuming that they will someday become
+ obsolete).
+
+1.1. Why disable clients?
+
+ * Security. Anybody who hasn't updated their Tor client in 5
+ years is probably vulnerable to who-knows-what attacks. They
+ aren't likely to get much anonymity either.
+
+ * Withstand zombie installations. Some Tors out there were once
+ configured to start-on-boot systems that are now unmaintained.
+ (See 1.4 below.) They put needless load on the network, and help
+ nobody.
+
+ * Be able to remove backward-compatibility code. Currently, Tor
+ supports some truly ancient protocols in order to avoid breaking
+ ancient versions or Tor. This code needs to be maintained and
+ tested. Some of it depends on undocumented or deprecated or
+ non-portable OpenSSL features, and makes it hard to produce a
+ conforming Tor server implementation.
+
+ * Make it easier to write a conforming Tor relay. If a Tor relay
+ needs to support every Tor client back through the beginning of
+ time, that makes it harder to develop and test compatible
+ implementations.
+
+1.2. Is this dangerous?
+
+ I don't think so. This proposal describes a way to make older
+ clients gracefully disconnect from the network only when a majority
+ of authorities agree that they should. A majority of authorities
+ already have the ability to inflict arbitrary degrees of sabotage on
+ the consensus document.
+
+1.3. History
+
+ The earliest versions of Tor checked the recommended-versions field
+ in the directory to see whether they should keep running. If they
+ saw that their version wasn't recommended, they'd shut down. There
+ was an "IgnoreVersion" option that let you keep running anyway.
+
+ Later, around 2004, the rule changed to "shut down if the version is
+ _obsolete_", where obsolete was defined as "not recommended, and
+ older than a version that is recommended."
+
+ In 0.1.1.7-alpha, we made obsolete versions only produce a warning,
+ and removed IgnoreVersion. (See 3ac34ae3293ceb0f2b8c49.)
+
+ We have still disabled old tor versions. With Tor 0.2.0.5-alpha,
+ we disabled Tor versions before 0.1.1.6-alpha by having the v1
+ authorities begin publishing empty directories only.
+
+ In version 0.2.5.2-alpha, we completely removed support for the v2
+ directory protocol used before Tor 0.2.0; there are no longer any v2
+ authorities on the network.
+
+ Tor versions before 0.2.1 will currently not progress past fetching
+ an initial directory, because they believe in a number of directory
+ authority identity keys that no longer sign the directory.
+
+ Tor versions before 0.2.4 are (lightly) throttled in multihop
+ circuit creation, because we prioritize ntor CREATE cells over
+ TAP ones when under load.
+
+1.4. The big problem: slow zombies and fast zombies
+
+ It would be easy enough to 'disable' old clients by simply removing
+ server support for the obsolete protocols that they use. But there's
+ a problem with that approach: what will the clients do when they fail
+ to make connections, or to extend circuits, or whatever else they are
+ no longer able to do?
+
+ * Ideally, I'd like such clients to stop functioning _quietly_. If
+ they stop contacting the network, that would be best.
+
+ * Next best would be if these clients contacted the network only
+ occasionally and at different times. I'll call these clients
+ "slow zombies".
+
+ * Worse would be if the clients contact the network frequently,
+ over and over. I'll call these clients "fast zombies". They
+ would be at their worst when they focus on authorities, or when
+ they act in synchrony to all strike at once.
+
+ One goal of this proposal is to ensure that future clients to not
+ become zombies at all; and that ancient clients become slow zombies
+ at worst.
+
+
+2. Some ideas that don't work.
+
+2.1. Dropping connections based on link protocols.
+
+ Tor versions before before 0.2.3.6-alpha use a renegotiation-based
+ handshake instead of our current handshake. We could detect these
+ handshakes and close the connection at the relay side if the client
+ attempts to renegotiate.
+
+ I've tested these changes on versions maint-0.2.0 through
+ maint-0.2.2. They result in zombies with the following behavior:
+
+ The client contact each authority it knows about, attempting to
+ make a one-hop directory connection. It fails, detects a failure,
+ then reconnects more and more slowly ... but one hour later, it
+ resets its connection schedule and starts again.
+
+ In the steady state this appears to result in about two connections
+ per client per authority per hour. That is probably too many.
+
+ (Most authorities would be affected: of the authorities that existed
+ in 0.2.2, gabelmoo has moved and turtles has shut down. The
+ authorities Faravahar and longclaw are new. The authorities moria1,
+ tor26, dizum, dannenberg, urras, maatuska and maatuska would all get
+ hit here.)
+
+ (We could simply remove the renegotiation-detection code entirely,
+ and reply to all connections with an immediate VERSIONS cell. The
+ behavior would probably be the same, though.)
+
+ If we throttled connections rather than closing them, we'd only get
+ one connnection per authority per hour, but authorities would have to
+ keep open a potentially huge number of sockets.
+
+2.2. Blocking circuit creation under certain circumstances
+
+ In tor 0.2.5.1-alpha, we began ignoring the UseNTorHandshake option,
+ and always preferring the ntor handshake where available.
+
+ Unfortunately, we can't simply drop all TAP handshakes, since clients
+ and relays can still use them in the hidden service protocol. But
+ we could detect these versions by:
+
+ Looking for use of a TAP handshake from an IP not associated
+ with with any known relay, or on a connection where the client
+ did not authenticate. (This could be from a bridge, but clients
+ don't build circuits that go to an IntroPoint or RendPoint
+ directly after a bridge.)
+
+ This would still result in clients not having directories, however,
+ and retrying once an hours.
+
+3. Ideas that might work
+
+3.1. Move all authorities to new ports
+
+ We could have each authority known to older clients start listening
+ for connections at a new port P. We'd forward the old port to the new
+ port. Once sufficiently many clients were using the new ports, we
+ could disable the forwarding.
+
+ This would result in the old clients turning into zombies as above,
+ but they would only be scrabbling at nonexistent ports, causing less
+ load on the authorities.
+
+ [This proposal would probably be easiest to implement.]
+
+3.2. Start disabling old link protocols on relays
+
+ We could have new relays start dropping support for the old link
+ protocols, while maintaining support on the authorities and older
+ relays.
+
+ The result here would be a degradation of older client performance
+ over time. They'd still behave zombieishly if the authorities
+ dropped support, however.
+
+3.3. Changing the consensus format.
+
+ We could allow 'f' (short for "flag") as a synonym for 's' in
+ consensus documents. Later, if we want to disable all Tor versions
+ before today, we can change the consensus algorithm so that the
+ consensus (or perhaps only the microdesc consensus) is spelled with
+ 'f' lines instead of 'f' lines. This will create a consensus which
+ older clients and relays parse as having all nodes down, which will
+ make them not connect to the network at all.
+
+ We could similarly replace "r" with "n", or replace Running with
+ Online, or so on.
+
+ In doing this, we could also rename fresh-until and valid-until, so
+ that new clients would have the real expiration date, and old clients
+ would see "this consensus never expires". This would prevent them
+ from downloading new consensuses.
+
+ [This proposal would result in the quietest shutdown.]
More information about the tor-commits
mailing list