commit 1e074bfe15908069f1b61d4f9d95a3168e997a57 Author: Nick Mathewson <nickm@torproject.org> Date: Wed Jun 12 21:12:35 2013 -0400 Add three older documents removed from tor.git --- attic/authority-policy.txt | 89 +++++++++++++++++++++ attic/torel-design.txt | 181 ++++++++++++++++++++++++++++++++++++++++++ attic/v3-authority-howto.txt | 84 ++++++++++++++++++++ 3 files changed, 354 insertions(+) diff --git a/attic/authority-policy.txt b/attic/authority-policy.txt new file mode 100644 index 0000000..7072082 --- /dev/null +++ b/attic/authority-policy.txt @@ -0,0 +1,89 @@ + +0. Overview. + + This document contains various informal policies for how to operate + a directory authority, how to choose new ones, etc. + +1. How to pick a new directory authority. + + Here's our current guidelines for how to pick new directory + authorities. + + (These won't ever be formal criteria -- we need to keep this flexible + so we can adapt to new situations.) + + o Stability: + - Must be a low-downtime Tor server (computer as well as network). + - Must have a static IP. + - The operator must have been running a stable Tor server for at least + 3 months. + - Must intend for this server to stick around for the next 12 months + or more. + - Must not hibernate. + - Should not be an exit node (as this increases the risk both of + downtime and of key compromise). + + o Performance: + - Must have sufficient bandwidth: at least 10mbit/s symmetric, + though in practice the inbound traffic can be considerably less. + + o Availability: + - Must be available to upgrade within a few days in most cases. + (While we're still developing Tor, we periodically find bugs that + impact the whole network and require authority upgrades.) + - Should have a well-known way to contact the administrator + via PGP-encrypted message. + + o Integrity: + - Must promise not to censor or attack the network and users. + - Should be run by somebody that Tor (i.e. Roger) knows. + - Should be widely regarded as fair/trustworthy, or at least + known, by many people. + - If somebody asks you to backdoor or change your server, legally or + otherwise, you will fight it to the extent of your abilities. If + you fail to fight it, you must shut down the Tor server and notify + us that you have. + + o Diversity + - We should avoid situations that make it likelier for multiple + authority failures to happen at the same time. Therefore... + - It's good when authorities are not all in the same country. + - It's good when authorities are not all in the same jurisdictions. + - It's good when authorities are not all running the same OS. + - It's good when authorities are not all using the same ISP. + - It's good when authorities are not all running the same + version of Tor. + - No two authorities should have the same operator. + - Maximal diversity, however, is not always practical. Sometimes, + for example, there is only one version of Tor that provides a + given consensus generation algorithm. + - A small group of authorities with the same country/jurisdiction/OS is + not a problem, until that group's size approaches quorum (half the + authorities). + +2. How to choose the recommended versions + + The policy, in a nutshell, is to not remove versions without a good + reason. So this means we should recommend all versions except: + + - Versions that no longer conform to the spec. That is, if they wouldn't + actually interact correctly with the current Tor network. + - Versions that have known security problems. + - Versions that have frequent crash or assert problems. + - Versions that harm the performance or stability of the current Tor + network or the anonymity of other users. For example, a version + that load balances wrong, or a version that hammers the authorities + too much. + + +> some use the slight variant of requiring a *good* reason. +> excellent reasons include "there's a security flaw" +> good reasons include "that crashes every time you start it. you would think ++tor is dumb if you tried to use that version and think of it as tor." +> good reasons include "those old clients do their load balancing wrong, and ++they're screwing up the whole network" +> reasons include "the old one is really slow, clients should prefer the new ++one" +> i try to draw the line at 'good reasons and above' + + diff --git a/attic/torel-design.txt b/attic/torel-design.txt new file mode 100644 index 0000000..610cbe2 --- /dev/null +++ b/attic/torel-design.txt @@ -0,0 +1,181 @@ +Design For A Tor DNS-based Exit List + +Status: + + This is a suggested design for a DNS Exit List (DNSEL) for Tor exit nodes. + See http://exitlist.torproject.org/ for an implementation. + +Why? + + It's useful for third parties to be able to tell when a given connection + is coming from a Tor exit node. Potential applications range from + "anonymous user" cloaks on IRC networks like oftc, to networks like + Freenode that apply special authentication rules to users from these + IPs, to systems like Wikipedia that may want to make a priority of + _unblocking_ shared IPs more liberally than non-shared IPs, since shared + IPs presumably have non-abusive users as well as abusive ones. + + Since Tor provides exit policies, not every Tor server will connect to + every address:port combination on the Internet. Unless you're trying to + penalize hosts for supporting anonymity, it makes more sense to answer + the fine-grained question "which Tor servers will connect to _me_?" than + the coarse-grained question "which Tor servers exist?" The fine-grained + approach also helps Tor server ops who share an IP with their Tor + server: if they want to access a site that blocks Tor users, they + can exclude that site from their exit policy, and the site can learn + that they won't send it anonymous connections. + + Tor already ships with a tool (the "contrib/exitlist" script) to + identify which Tor nodes might open anonymous connections to any given + exit address. But this is a bit tricky to set up, so only sites like + Freenode and OFTC that are dedicated to privacy use it. + Conversely, providers of some DNSEL implementations are providing + coarse-grained lists of Tor hosts -- sometimes even listing servers that + permit no exit connections at all. This is rather a problem, since + support for DNSEL is pretty ubiquitous. + + +How? + + Keep a running Tor instance, and parse the cached-routers and + cached-routers.new files as new routers arrive. To tell whether a given + server allows connections to a certain address:port combo, look at the + definitions in dir-spec.txt or follow the logic of the current exitlist + script. If bug 405 is still open when you work on this + (https://bugs.torproject.org/flyspray/index.php?do=details&id=405), you'll + probably want to extend it to look at only the newest descriptor for + each server, so you don't use obsolete exit policy data. + + FetchUselessDescriptors would probably be a good torrc option to enable. + + If you're also running a directory cache, you get extra-fresh + information. + + +The DNS interface + + Standard DNSEL, if I understand right, looks like this: There's some + authoritative name server for foo.example.com. You want to know if + 1.2.3.4 is in the list, so you query for an A record for + 4.3.2.1.foo.example.com. If the record exists and has the value + 127.0.0.2[DNSBL-EMAIL], 1.2.3.4 is in the list. If you get an NXDOMAIN + error, 1.2.3.4 is not in the list. If you ask for a domain name outside + of the foo.example.com zone, you get a Server Failure error[RFC 1035]. + + Assume that the DNSEL answers queries authoritatively for some zone, + torhosts.example.com. Below are some queries that could be supported, + though some of them are possibly a bad idea. + + + Query type 1: "General IP:Port" + + Format: + {IP1}.{port}.{IP2}.ip-port.torhosts.example.com + + Rule: + Iff {IP1} is a Tor server that permits connections to {port} on + {IP2}, then there should be an A record with the value 127.0.0.2. + + Example: + "1.0.0.10.80.4.3.2.1.ip-port.torhosts.example.com" should have the + value 127.0.0.2 if and only if there is a Tor server at 10.0.0.1 + that allows connections to port 80 on 1.2.3.4. + + Example use: + I'm running an IRC server at w.x.y.z:9999, and I want to tell + whether an incoming connection is from a Tor server. I set + up my IRC server to give a special mask to any user coming from + an IP listed in 9999.z.y.x.w.ip-port.torhosts.example.com. + + Later, when I get a connection from a.b.c.d, my ircd looks up + "d.c.b.a.9999.z.y.x.w.ip-port.torhosts.example.com" to see + if it's a Tor server that allows connections to my ircd. + + + Query type 2: "IP-port group" + + Format: + {IP}.{listname}.list.torhosts.example.com + + Rule: + Iff this Tor server is configured with an IP:Port list named + {listname}, and {IP} is a Tor server that permits connections to + any member of {listname}, then there exists an A record. + + Example: + Suppose torhosts.example.com has a list of IP:Port called "foo". + There is an A record for 4.3.2.1.foo.list.torhosts.example.com + if and only if 1.2.3.4 is a Tor server that permits connections + to one of the addresses in list "foo". + + Example use: + Suppose torhosts.example.com has a list of hosts in "examplenet", + a popular IRC network. Rather than having them each set up to + query the appropriate "ip-port" list, they could instead all be + set to query a central examplenet.list.torhosts.example.com. + + Problems: + We'd be better off if each individual server queried about hosts + that allowed connections to itself. That way, if I wanted to + allow anonymous connections to foonet, but I wanted to be able to + connect to foonet from my own IP without being marked, I could add + just a few foonet addresses to my exit policy. + + + Query type 3: "My IP, with port" + + Format: + {IP}.{port}.me.torhosts.example.com + + Rule: + An A record exists iff there is a tor server at {IP} that permits + connections to {port} on the host that requested the lookup. + + Example: + "4.3.2.1.80.me.torhosts.example.com" should have an A record if + and only if there is a Tor server at 1.2.3.4 that allows + connections to port 80 of the querying host. + + Example use: + Somebody wants to set up a quick-and-dirty Tor detector for a + single webserver: just point them at 80.me.torhosts.example.com. + + Problem: + This would be easiest to use, but DNS gets in the way. If you + create DNS records that give different results depending on who is + asking, you mess up caching. There could be a fix here, but might + not. + + + RECOMMENDATION: Just build ip-port for now, and see what demand is + like. There's no point in building mechanisms nobody wants. + +Web interface: + + Should provide the same data as the dns interface. + +Other issues: + + After a Tor server op turns off their server, it stops publishing server + descriptors. We should consider that server's IP address to still + represent a Tor node until 48 hours after its last descriptor was + published. + + 30-60 minutes is not an unreasonable TTL. + + There could be some demand for address masks and port lists. Address + masks wider than /8 make me nervous here, as do port ranges. + + We need an answer for what to do about hosts which exit from different + IPs than their advertised IP. One approach would be for the DNSEL + to launch periodic requests to itself through all exit servers whose + policies allow it -- and then see where the requests actually come from. + +References: + + [DNSBL-EMAIL] Levine, J., "DNS Based Blacklists and Whitelists for + E-Mail", http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02, November + 2005. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. diff --git a/attic/v3-authority-howto.txt b/attic/v3-authority-howto.txt new file mode 100644 index 0000000..e4470e8 --- /dev/null +++ b/attic/v3-authority-howto.txt @@ -0,0 +1,84 @@ + + How to add a v3 directory authority. + +What we'll be doing: + + We'll be configuring your Tor server as a v3 directory authority, + generating a v3 identity key plus certificates, and adding your v3 + identity fingerprint to the list of default directory authorities. + +The steps: + +0) Make sure you're running ntp, and that your time is correct. + + Make sure you have Tor version at least r12724. In the short term, + running a working authority may mean running the latest version of + Tor from SVN trunk. Later on, we hope that it will become easier + and you can just run a recent development release (and later still, + a recent stable release). + +1) First, you'll need a certificate. Run ./src/tools/tor-gencert to + generate one. + + Run tor-gencert in a separate, very secure directory. Maybe even on + a more secure computer. The first time you run it, you will need to + run it with the --create-identity-key option to make a v3 authority + identity key. Subsequent times, you can just run it as-is. + + tor-gencert will make 3 files: + + authority_identity_key -- THIS IS VERY SECRET AND VERY SENSITIVE. + DO NOT LEAK IT. DO NOT LOSE IT. + + authority_signing_key -- A key for signing votes and v3 conensuses. + + authority_certificate -- A document authenticating your signing key + with your identity-key. + + You will need to rotate your signing key periodically. The current + default lifetime is 1 year. We'll probably take this down to a month or + two some time soon. To rotate your key, run tor-gencert as before, + but without the --create-identity-key option. + +2) Copy authority_signing_key and authority_certificate to your Tor keys + directory. + + For example if your data directory is /var/lib/tor/, you should run + cp authority_signing_key authority_certificate /var/lib/tor/keys/ + + You will need to repeat this every time you rotate your certificate. + +3) Tell your Tor to be a v3 authority by adding these lines to your torrc: + + AuthoritativeDirectory 1 + V3AuthoritativeDirectory 1 + +4) Now your authority is generating a networkstatus opinion (called a + "vote") every period, but none of the other authorities care yet. The + next step is to get a Tor developer (likely Roger or Nick) to add + your v3 identity fingerprint to the default list of dirservers. + + First, you need to learn your authority's v3 identity fingerprint. + It should be in your authority_certificate file in a line like: + + fingerprint 3041632465FA8847A98B2C5742108C72325532D9 + + One of the Tor developers then needs to add this fingerprint to + the add_default_trusted_dirservers() function in config.c, using + the syntax "v3ident=<fingerprint>". For example, if moria1's new v3 + identity fingerprint is FOO, the moria1 dirserver line should now be: + + DirServer moria1 v1 orport=9001 v3ident=FOO 128.31.0.34:9031 FFCB 46DB 1339 DA84 674C 70D7 CB58 6434 C437 0441 + + The v3ident item must appear after the nickname and before the IP. + +5) Once your fingerprint has been added to config.c, we will try to + get a majority of v3 authorities to upgrade, so they know about you + too. At that point your vote will automatically be included in the + networkstatus consensus, and you'll be a fully-functioning contributing + v3 authority. + + Note also that a majority of the configured v3 authorities need to + agree in order to generate a consensus: so this is also the point + where extended downtime on your server means missing votes. +