[tor-dev] Draft proposal -- no number yet: How to safely drop support for old clients.
Hi, Nick Mathewson: Draft proposal -- no number yet: How to safely drop support for old clients. I feel like "safely" sounds too fluffy and not reflective of the proposal. - How to force-drop support for old clients. or - How to depreciate support for old clients. The second of these seems the most suitable. Frequently, we find that very old versions of Tor should no longer be supported on the network. Where can we find research on the impact? 3.4. Disabling all versions that don't support this proposal With all due respect, doesn't Microsoft do stuff like this? Is the impact so large that they require this level of action? if we want to disable all Tor versions before today that do not support this proposal. Is the proposal for 5 years in the past, pre this version, or can/will the cutoff be specified willy-nilly? It might be good to make any disable-switches advisory rather than mandatory. Ultimately, if this is the approach, and it is in the hands of each client operator, this could be good. Though it would be great to hear from those who use previous versions to thwart limitations in "upgrades" to Firefox, such as the way media is streamed, amongst other things :) Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Draft proposal -- no number yet: How to safely drop support for old clients.
Hi, comments inline. On 09/30/2015 12:01 PM, Nick Mathewson wrote: Early versions of Tor checked the recommended-versions field in the directory to see whether they should keep running. If they didn't recognize you did the thing where you To override this, a Tor instance may include a configuration option, "IgnoreDisabledVersion VERSION". It is an error to set this option when *not* running with a disabled version. This does not work unless the client already has a consensus that they have parsed so they know they're running a disabled version. I appreciate the sentiment here (don't allow people to blindly set the option), but I'm not sure it's worth it. 3.4. Disabling all versions that don't support this proposal We should allow 'n' (short for "node") as a synonym for 'r' 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 'n' lines instead of 'r' lines. This will create a consensus which older clients and relays parse as having no nodes. Hrm. I'm not a fan of this, it seems like a pretty sad hack. I don't have an alternative ready unfortunately. 3.5. In the event of overzealous retries We need to be sure that client running versions from 0.2.1 through 0.2.6 respond gracefully to the responses above. In particular, we need to make sure that they don't continually retry the connections that fail in these ways: that would put a lot of extra load on the network. Above, I recommend stalling connections rather than just closing them. This may prevent the risk of retries, at the risk of using additional relay resources. Stalling is much less preferable than closing to me. We should actually do the analysis and do it well to know if we actually have to do it, imo. Cheers Sebastian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Draft proposal -- no number yet: How to safely drop support for old clients.
> On 30 Sep 2015, at 12:01, Nick Mathewson wrote: > > [This isn't done yet, but I've shown it to enough people that I should > share it with the list.] > > 1. Introduction and background > > 1.1. Motivation > > 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 them. > > But to disable clients is harder. We can do as we did with v1 > directories in Tor 0.2.0.5-alpha, and make them know about no relays > at all. > > ... > 1.2. History > > Early versions of Tor checked the recommended-versions field in the > directory to see whether they should keep running. If they didn't > recognize their own version, they would stop (what?). > ... > 3.2. Disabling versions prior to 0.2.4.11-alpha. > > Starting in version Tor 0.2.4.11-alpha, we implemented proposal 214. > This proposal added a new link protocol, version 4. Earlier version versions > of Tor never support it; newer versions of Tor always advertise their > support for it. > > We could treat the presence of any link protocol of version 4 or > later as indicating the presence of 0.2.4.11-alpha. Upon receiving a version 3 or earlier as indicating the presence of a version less than 0.2.4.11-alpha. > connection from such a version, we could throttle the bytes we give > it, drop its circuits, or stop reading. > > [TODO: which?] Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Draft proposal -- no number yet: How to safely drop support for old clients.
[This isn't done yet, but I've shown it to enough people that I should share it with the list.] 1. Introduction and background 1.1. Motivation 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 them. But to disable clients is harder. We can do as we did with v1 directories in Tor 0.2.0.5-alpha, and make them know about no relays at all. Stepping back -- why should we disable very old clients at all? Here are some reasons why: * 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 anonymity either. * Withstand zombie installations. Some Tors out there were once configured to start-on-boot on now-unmaintained systems. They put needless load on the network, and can't be easily disposed of. * Disable backward-compatibility code. Currently, Tor supports some truly ancient protocols in order to avoid breaking ancient versions. If we disable these protocols without turning off the clients that use them, we run the risk that those clients will run wild, retrying their connections to the network over and over. This document describes a designs for use with future versions of Tor to better support client deprecation and removal. It also describes how we can safely disable existing client versions that do not support this proposal. 1.2. History Early versions of Tor checked the recommended-versions field in the directory to see whether they should keep running. If they didn't recognize 1.3. Goals and requirements We need older clients to stop putting (much) load on the network. Having them stop working entirely is not sufficient: they need to stop working in such a way that they don't keep using up resources. In the future, when we disable a client, it would be a good thing to provide some means to warn users in advance that they need to upgrade, and to provide advice about doing so. It might be good to make any disable-switches advisory rather than mandatory. 2. Adding a disable-clients switch to consensus documents I specify a new consensus element: disable-versions. It may appear any number of times in a consensus document. The syntax is: disable-versions SP SOFTWARE SP ROLE SP DATE SP VERSIONS DATE = A date in -MM-DD format ROLE = "relay", or "all". SOFTWARE = "Tor" VERSIONS = VERSION_RANGE VERSIONS = VERSIONS SP VERSION_RANGE VERSION_RANGE = VERSION VERSION_RANGE = VERSION..VERSION [TODO: Specify voting.] If the current version is listed in any disabled-versions line for its current role, then we should warn the user. If the current date is on after the date specified (starting midnight UTC), we should disable the host as follows: * If 'relay' is the disabled role, then we should enter ClientOnly mode. * If 'all' is the disabled role, we should enter DisableNetwork mode. Note that the DisableNetwork behavior means that once a client is disabled, it will not fetch new consensuses. To override this, a Tor instance may include a configuration option, "IgnoreDisabledVersion VERSION". It is an error to set this option when *not* running with a disabled version. [ALTERNATIVE: Make RequireLinkProtocol, RequireCircuitProtocol, etc lines for the consensus. Any Tor not supporting those protocols should behave as above. This allows non-Tor implementations to respect these fields.] 3. Disabling current client versions. 3.1. Disabling versions that use the v2 handshake These versions (before 0.2.3.6-alpha) use a renegotiation-based handshake instead of our current handshake. When we detect a renegotiation attempt, we can close the connection, or stop reading on it. 3.2. Disabling versions prior to 0.2.4.11-alpha. Starting in version Tor 0.2.4.11-alpha, we implemented proposal 214. This proposal added a new link protocol, version 4. Earlier version of Tor never support it; newer versions of Tor always advertise their support for it. We could treat the presence of any link protocol of version 4 or later as indicating the presence of 0.2.4.11-alpha. Upon receiving a connection from such a version, we could throttle the bytes we give it, drop its circuits, or stop reading. [TODO: which?] 3.3. Disabling versions prior to 0.2.5.x 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 det
