May 2012 - tor-commits - lists.torproject.org

[tor/master] Merge branch 'bug5380'
by nickm＠torproject.org 16 May '12

16 May '12

commit 2cdd631f5ca93e8bed5ad741881d4b332a81ebc3 Merge: 517b9c6 f89de0a Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 16 11:31:40 2012 -0400 Merge branch 'bug5380' changes/bug5380 | 5 +++++ src/or/circuitbuild.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletions(-)

1 0

[tor/master] Exits don't need to fetch certs for unknown authorities
by nickm＠torproject.org 16 May '12

16 May '12

commit 5193752ca88849878a0843cec1e81c6b4b05e550 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Mar 30 15:20:06 2012 -0400 Exits don't need to fetch certs for unknown authorities When we started RefuseUnknownExits back in 0.2.2.11-alpha, we started making exits act like they cache directory info (since they need an up-to-date idea of who is really a router). But this included fetching needless (unrecognized) authorities' certs, which doesn't make any sense for them. This is related to, but not necessarily the same as, the issue that Ian reported for bug #2297. (This patch is based on a patch from a user who I believe has asked not to be named. If I'm wrong about that, please add the appropriate name onto the changelog.) --- changes/bug2297-related | 6 ++++++ src/or/dirserv.c | 9 +++++++++ src/or/dirserv.h | 1 + src/or/routerlist.c | 4 ++-- 4 files changed, 18 insertions(+), 2 deletions(-) diff --git a/changes/bug2297-related b/changes/bug2297-related new file mode 100644 index 0000000..3d9af11 --- /dev/null +++ b/changes/bug2297-related @@ -0,0 +1,6 @@ + o Minor bugfixes: + - Exit nodes don't need to fetch certificates for authorities that + they don't recognize; only directory authorities, bridges, and + caches need to do that. Fix related to bug 2297; bugfix on + 0.2.2.11-alpha. + diff --git a/src/or/dirserv.c b/src/or/dirserv.c index 11f235c..898d9f4 100644 --- a/src/or/dirserv.c +++ b/src/or/dirserv.c @@ -1252,6 +1252,15 @@ directory_caches_v2_dir_info(const or_options_t *options) return options->DirPort != NULL; } +/** Return true iff we want to fetch and keep certificates for authorities + * that we don't acknowledge as aurthorities ourself. + */ +int +directory_caches_unknown_auth_certs(const or_options_t *options) +{ + return options->DirPort || options->BridgeRelay; +} + /** Return 1 if we want to keep descriptors, networkstatuses, etc around * and we're willing to serve them to others. Else return 0. */ diff --git a/src/or/dirserv.h b/src/or/dirserv.h index fc48e48..3ff0815 100644 --- a/src/or/dirserv.h +++ b/src/or/dirserv.h @@ -76,6 +76,7 @@ int directory_fetches_dir_info_early(const or_options_t *options); int directory_fetches_dir_info_later(const or_options_t *options); int directory_caches_v2_dir_info(const or_options_t *options); #define directory_caches_v1_dir_info(o) directory_caches_v2_dir_info(o) +int directory_caches_unknown_auth_certs(const or_options_t *options); int directory_caches_dir_info(const or_options_t *options); int directory_permits_begindir_requests(const or_options_t *options); int directory_permits_controller_requests(const or_options_t *options); diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 160f340..f549549 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -229,7 +229,7 @@ trusted_dirs_load_certs_from_string(const char *contents, int from_store, "signing key %s", from_store ? "cached" : "downloaded", ds->nickname, hex_str(cert->signing_key_digest,DIGEST_LEN)); } else { - int adding = directory_caches_dir_info(get_options()); + int adding = directory_caches_unknown_auth_certs(get_options()); log_info(LD_DIR, "%s %s certificate for unrecognized directory " "authority with signing key %s", adding ? "Adding" : "Not adding", @@ -480,7 +480,7 @@ authority_certs_fetch_missing(networkstatus_t *status, time_t now) smartlist_t *missing_digests; char *resource = NULL; cert_list_t *cl; - const int cache = directory_caches_dir_info(get_options()); + const int cache = directory_caches_unknown_auth_certs(get_options()); if (should_delay_dir_fetches(get_options())) return;

1 0

[tor/master] Merge remote-tracking branch 'public/bug2297'
by nickm＠torproject.org 16 May '12

16 May '12

commit 517b9c602a9e5e8c60849892a426526e803ef412 Merge: a925fc9 5193752 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 16 11:14:00 2012 -0400 Merge remote-tracking branch 'public/bug2297' changes/bug2297-related | 6 ++++++ src/or/dirserv.c | 9 +++++++++ src/or/dirserv.h | 1 + src/or/routerlist.c | 4 ++-- 4 files changed, 18 insertions(+), 2 deletions(-)

1 0

[tor/master] Rate-limit the warnings as a client when asked to connect a private addr
by nickm＠torproject.org 16 May '12

16 May '12

commit 70c17134c79d9de05408748329c0918158d7deb0 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 28 03:06:25 2012 -0400 Rate-limit the warnings as a client when asked to connect a private addr Partial fix for ticket 2822. --- changes/bug2822.1 | 5 +++++ src/or/connection_edge.c | 28 +++++++++++++++++++++------- 2 files changed, 26 insertions(+), 7 deletions(-) diff --git a/changes/bug2822.1 b/changes/bug2822.1 new file mode 100644 index 0000000..9c4016d --- /dev/null +++ b/changes/bug2822.1 @@ -0,0 +1,5 @@ + o Minor features: + + - Rate-limit log messages when asked to connect anonymously to a private + address. When these hit, they tended to hit fast and often. Partial + fix for bug 2822. diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index dd772b2..e19d7f0 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -2006,14 +2006,28 @@ connection_ap_handshake_rewrite_and_attach(entry_connection_t *conn, * then we really don't want to try to connect to it. That's * probably an error. */ if (conn->is_transparent_ap) { - log_warn(LD_NET, - "Rejecting request for anonymous connection to private " - "address %s on a TransPort or NATDPort. Possible loop " - "in your NAT rules?", safe_str_client(socks->address)); +#define WARN_INTERVAL_LOOP 300 + static ratelim_t loop_warn_limit = RATELIM_INIT(WARN_INTERVAL_LOOP); + char *m; + if ((m = rate_limit_log(&loop_warn_limit, approx_time()))) { + log_warn(LD_NET, + "Rejecting request for anonymous connection to private " + "address %s on a TransPort or NATDPort. Possible loop " + "in your NAT rules?%s", safe_str_client(socks->address), + m); + tor_free(m); + } } else { - log_warn(LD_NET, - "Rejecting SOCKS request for anonymous connection to " - "private address %s", safe_str_client(socks->address)); +#define WARN_INTERVAL_PRIV 300 + static ratelim_t priv_warn_limit = RATELIM_INIT(WARN_INTERVAL_PRIV); + char *m; + if ((m = rate_limit_log(&priv_warn_limit, approx_time()))) { + log_warn(LD_NET, + "Rejecting SOCKS request for anonymous connection to " + "private address %s.%s", + safe_str_client(socks->address),m); + tor_free(m); + } } connection_mark_unattached_ap(conn, END_STREAM_REASON_PRIVATE_ADDR); return -1;

1 0

[tor/master] Reject SOCKS requests for "localhost" or ".local"
by nickm＠torproject.org 16 May '12

16 May '12

commit 433d7578465e04484d537810096512b5cc61246f Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 28 03:19:00 2012 -0400 Reject SOCKS requests for "localhost" or ".local" Sending them on is futile, since we will be told "127.0.0.1" and then think we've been lied to. Partial fix for 2822. --- changes/bug2822.2 | 6 ++++++ src/common/address.c | 9 +++++++++ src/common/address.h | 2 ++ src/or/connection_edge.c | 5 +++-- 4 files changed, 20 insertions(+), 2 deletions(-) diff --git a/changes/bug2822.2 b/changes/bug2822.2 new file mode 100644 index 0000000..373741c --- /dev/null +++ b/changes/bug2822.2 @@ -0,0 +1,6 @@ + o Minor features: + + - Don't bother trying to connect to addresses that we are sure will + resolve to 127.0.0.1: Getting 127.0.0.1 in a reply makes us think + we have been lied to, even when the address the client tried to + connect to was "localhost." Partial fix for bug 2822. diff --git a/src/common/address.c b/src/common/address.c index 676c485..e379464 100644 --- a/src/common/address.c +++ b/src/common/address.c @@ -1682,3 +1682,12 @@ get_interface_address(int severity, uint32_t *addr) return r; } +/** Return true if we can tell that <b>name</b> is a canonical name for the + * loopback address. */ +int +tor_addr_hostname_is_local(const char *name) +{ + return !strcasecmp(name, "localhost") || + !strcasecmp(name, "local") || + !strcasecmpend(name, ".local"); +} diff --git a/src/common/address.h b/src/common/address.h index 4568c32..125fd38 100644 --- a/src/common/address.h +++ b/src/common/address.h @@ -191,6 +191,8 @@ int tor_addr_is_loopback(const tor_addr_t *addr); int tor_addr_port_split(int severity, const char *addrport, char **address_out, uint16_t *port_out); +int tor_addr_hostname_is_local(const char *name); + /* IPv4 helpers */ int is_internal_IP(uint32_t ip, int for_listening); int addr_port_lookup(int severity, const char *addrport, char **address, diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index e19d7f0..fb09281 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -2000,8 +2000,9 @@ connection_ap_handshake_rewrite_and_attach(entry_connection_t *conn, if (options->ClientRejectInternalAddresses && !conn->use_begindir && !conn->chosen_exit_name && !circ) { tor_addr_t addr; - if (tor_addr_parse(&addr, socks->address) >= 0 && - tor_addr_is_internal(&addr, 0)) { + if (tor_addr_hostname_is_local(socks->address) || + (tor_addr_parse(&addr, socks->address) >= 0 && + tor_addr_is_internal(&addr, 0))) { /* If this is an explicit private address with no chosen exit node, * then we really don't want to try to connect to it. That's * probably an error. */

1 0

[tor/master] Correct the bulletproofing of routerlist_insert()
by nickm＠torproject.org 16 May '12

16 May '12

commit 3ed4c5dc05a1954a8c68d0f7e9fb802f3155d308 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 16 10:51:02 2012 -0400 Correct the bulletproofing of routerlist_insert() The original code updated some variables, but forgot to remove a replaced old-routerdesc from rl->old_routers. Related to bug 1776. --- changes/routerlist_ins_replace | 5 +++++ src/or/routerlist.c | 7 +++++++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/changes/routerlist_ins_replace b/changes/routerlist_ins_replace new file mode 100644 index 0000000..7b442a2 --- /dev/null +++ b/changes/routerlist_ins_replace @@ -0,0 +1,5 @@ + o Minor bugfixes: + - If we hit the error case where routerlist_insert() replaces an + existing (old) server descriptor, make sure to remove that + server descriptor from the old_routers list. Fix related to bug + 1776. Bugfix on 0.2.2.18-alpha. diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 86cdb83..d21b40c 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -2815,6 +2815,13 @@ routerlist_insert(routerlist_t *rl, routerinfo_t *ri) ri->cache_info.signed_descriptor_digest, &(ri->cache_info)); if (sd_old) { + int idx = sd_old->routerlist_index; + sd_old->routerlist_index = -1; + smartlist_del(rl->old_routers, idx); + if (idx < smartlist_len(rl->old_routers)) { + signed_descriptor_t *d = smartlist_get(rl->old_routers, idx); + d->routerlist_index = idx; + } rl->desc_store.bytes_dropped += sd_old->signed_descriptor_len; sdmap_remove(rl->desc_by_eid_map, sd_old->extra_info_digest); signed_descriptor_free(sd_old);

1 0

[tor/master] Merge remote-tracking branch 'public/bug2822'
by nickm＠torproject.org 16 May '12

16 May '12

commit a925fc918975fd62581d438eec0dc8a1d53ce127 Merge: a3046fd 433d757 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 16 11:10:09 2012 -0400 Merge remote-tracking branch 'public/bug2822' changes/bug2822.1 | 5 +++++ changes/bug2822.2 | 6 ++++++ src/common/address.c | 9 +++++++++ src/common/address.h | 2 ++ src/or/connection_edge.c | 33 ++++++++++++++++++++++++--------- 5 files changed, 46 insertions(+), 9 deletions(-)

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 16 May '12

16 May '12

commit a3046fd5e576bc7294374a8bbab1a80cd3fb3524 Merge: ee246bb 3ed4c5d Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 16 10:57:08 2012 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' changes/routerlist_ins_replace | 5 +++++ src/or/routerlist.c | 7 +++++++ 2 files changed, 12 insertions(+), 0 deletions(-)

1 0

[torspec/master] Start merging proposals 158 and 162 into dir-spec.txt.
by nickm＠torproject.org 16 May '12

16 May '12

commit 282f7f5a138fe1c1c130ee210ac1180aff4bd2b2 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Mar 1 10:45:09 2012 +0100 Start merging proposals 158 and 162 into dir-spec.txt. --- dir-spec.txt | 356 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 337 insertions(+), 19 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index f680458..be140a5 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1057,7 +1057,66 @@ Authorities MUST generate a new signing key and corresponding certificate before the key expires. -3.2. Vote and consensus status documents +3.2. Microdescriptors + + Microdescriptors are a stripped-down version of router descriptors + generated by the directory authorities which may additionally contain + authority-generated information. Microdescriptors contain only the + most relevant parts that clients care about. Microdescriptors are + expected to be relatively static and only change about once per week. + Microdescriptors do not contain any information that clients need to + use to decide which servers to fetch information about, or which + servers to fetch information from. + + Microdescriptors are a straight transform from the router descriptor + and the consensus method. Microdescriptors have no header or footer. + Microdescriptors are identified by the hash of its concatenated + elements without a signature by the router. Microdescriptors do not + contain any version information, because their version is determined + by the consensus method. + +3.2.1. Microdescriptors in consensus method 8 or later + + Starting with consensus method 8, microdescriptors contain the + following elements taken from or based on the router descriptor. Order + matters here, because different directory authorities must be able to + transform a given router descriptor and consensus method into the exact + same microdescriptor. + + "onion-key" NL a public key in PEM format + + [Exactly once, at start] + + The "onion-key" element as specified in 2.1. + + [Should we mention that clients don't learn identity keys anymore + with this approach? Clients only need identity keys for their + entry guards, and in that case they learn the identity key from + the TLS handshake. But clients couldn't check identity keys of + non-entry nodes with the microdescriptor approach anymore, even if + they wanted. -KL] + + "family" names NL + + [At most once] + + The "family" element as specified in 2.1. + + "p" SP ("accept" / "reject") SP PortList NL + + [At most once] + + The exit-policy summary as specified in 3.3 and 3.5.2. A missing + "p" line is equivalent to "p reject 1-65535". + + [Should we note the downside of this approach that clients never + learn exact exit policies now? Clients can only guess whether a + relay accepts their request, try the BEGIN request, and might get + end-reason-exit-policy if they guessed wrong, in which case + they'll have to try elsewhere. Or is this too much design + discussion for a spec? -KL] + +3.3. Vote and consensus status documents Votes and consensuses are more strictly formatted then other documents in this specification, since different authorities must be able to @@ -1097,14 +1156,14 @@ [At most once for votes; does not occur in consensuses.] A space-separated list of supported methods for generating - consensuses from votes. See section 3.4.1 for details. Method "1" + consensuses from votes. See section 3.5.1 for details. Method "1" MUST be included. "consensus-method" SP Integer NL [At most once for consensuses; does not occur in votes.] - See section 3.4.1 for details. + See section 3.5.1 for details. (Only included when the vote is generated with consensus-method 2 or later.) @@ -1387,6 +1446,19 @@ or does not support (if 'reject') for exit to "most addresses". + "m" SP methods 1*(SP algorithm "=" digest) NL + + [Any number, only in votes.] + + Microdescriptor hashes for all consensus methods that an authority + supports and that use the same microdescriptor format. "methods" + is a comma-separated list of the consensus methods that the + authority believes will produce "digest". "algorithm" is the name + of the hash algorithm producing "digest", which can be "sha256" or + something else, depending on the consensus "methods" supporting + this algorithm. "digest" is the base64 encoding of the hash of + the router's microdescriptor with trailing =s omitted. + The footer section is delineated in all votes and consensuses supporting consensus method 9 and above with the following: @@ -1434,7 +1506,7 @@ Wbe - Weight for Exit-flagged nodes for BEGIN_DIR requests Wbd - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests - These values are calculated as specified in Section 3.4.3. + These values are calculated as specified in Section 3.5.3. The signature contains the following item, which appears Exactly Once for a vote, and At Least Once for a consensus. @@ -1450,7 +1522,7 @@ the signing authority, and "signing-key-digest" is the hex-encoded digest of the current authority signing key of the signing authority. -3.3. Assigning flags in a vote +3.4. Assigning flags in a vote (This section describes how directory authorities choose which status flags to apply to routers, as of Tor 0.2.0.0-alpha-dev. Later directory @@ -1574,9 +1646,9 @@ accept not for all addresses, ignoring all rejects for private netblocks. "Most" addresses are permitted if no more than 2^25 IPv4 addresses (two /8 networks) were blocked. The list is encoded - as described in 3.4.2. + as described in 3.5.2. -3.4. Computing a consensus from a set of votes +3.5. Computing a consensus from a set of votes Given a set of votes, authorities compute the contents of the consensus document as follows: @@ -1659,7 +1731,7 @@ for the descriptor we are listing. (They should all be the same. If they are not, we pick the most commonly listed one, breaking ties in favor of the lexicographically larger - vote.) The port list is encoded as specified in 3.4.2. + vote.) The port list is encoded as specified in 3.5.2. * If consensus-method 6 or later is in use and if 3 or more authorities provide a Measured= keyword in their votes for @@ -1684,7 +1756,7 @@ All ties in computing medians are broken in favor of the smaller or earlier item. -3.4.1. Forward compatibility +3.5.1. Forward compatibility Future versions of Tor will need to include new information in the consensus documents, but it is important that all authorities (or at least @@ -1718,7 +1790,7 @@ making changes in the contents of consensus; not for making backward-incompatible changes in their format.) -3.4.2. Encoding port lists +3.5.2. Encoding port lists Whether the summary shows the list of accepted ports or the list of rejected ports depends on which list is shorter (has a shorter string @@ -1738,7 +1810,7 @@ use an accept-style summary and list as much of the port list as is possible within these 1000 bytes. [XXXX be more specific.] -3.4.3. Computing Bandwidth Weights +3.5.3. Computing Bandwidth Weights Let weight_scale = 10000 @@ -1900,13 +1972,110 @@ Handle bridges and strange exit policies: Wgm=Wgg, Wem=Wee, Weg=Wed -3.5. Detached signatures +3.6. Consensus flavors + + Consensus flavors are variants of the consensus that clients can choose + to download and use instead of the unflavored consensus. The purpose + of a consensus flavor is to remove or replace information in the + unflavored consensus without forcing clients to download information + they would not use anyway. + + Directory authorities can produce and serve an arbitrary number of + flavors of the same consensus. A downside of creating too many new + flavors is that clients will be distinguishable based on which flavor + they download. A new flavor should not be created when adding a field + instead wouldn't be too onerous. + + Examples for consensus flavors include: + - Publishing hashes of microdescriptors instead of hashes of + full descriptors (see 3.6.2). + - Including different digests of descriptors, instead of the + perhaps-soon-to-be-totally-broken SHA1. + + Consensus flavors are derived from the unflavored consensus once the + voting process is complete. This is to avoid consensus synchronization + problems. + + Every consensus flavor has a name consisting of a sequence of one + or more alphanumeric characters and dashes. For compatibility, + current descriptor flavor is called "ns". + + The supported consensus flavors are defined as part of the + authorities' consensus method. + + All consensus flavors have in common that their first line is + "network-status-version" where version is 3 or higher, and the flavor + is a string consisting of alphanumeric characters and dashes: + + "network-status-version" SP version SP flavor NL + +3.6.1. ns consensus + + The ns consensus flavor is equivalent to the unflavored consensus + except for its first line which states its consensus flavor name: + + "network-status-version" SP version SP "ns" NL + + [At start, exactly once.] + +3.6.2. Microdescriptor consensus + + The microdescriptor consensus is a consensus flavor that contains + microdescriptor hashes instead of descriptor hashes and that omits + exit-policy summaries which are contained in microdescriptors. The + microdescriptor consensus was designed to contain elements that are + small and frequently changing. Clients use the information in the + microdescriptor consensus to decide which servers to fetch information + about and which servers to fetch information from. + + The microdescriptor consensus is based on the unflavored consensus with + the exceptions as follows: + + "network-status-version" SP version SP "microdesc" NL + + [At start, exactly once.] + + The flavor name of a microdescriptor consensus is "microdesc". + + Changes to router status entries are as follows: + + "r" SP nickname SP identity SP publication SP IP SP ORPort + SP DirPort NL + + [At start, exactly once.] + + Similar to "r" lines in 3.3, but without the digest element. + + "p" ... NL + + [Zero times.] + + Exit policy summaries are contained in microdescriptors and + therefore omitted in the microdescriptor consensus. + + "m" SP digest NL + + [Exactly once.] + + "digest" is the base64 of the SHA256 hash of the router's + microdescriptor with trailing =s omitted. For a given router + descriptor digest and consensus method there should only be a + single microdescriptor digest in the "m" lines of all votes. + If different votes have different microdescriptor digests for + the same descriptor digest and consensus method, at least one + of the authorities is broken. If this happens, the microdesc + consensus should contain whichever microdescriptor digest is + most common. If there is no winner, we break ties in the favor + of the lexically earliest. + +3.7. Detached signatures Assuming full connectivity, every authority should compute and sign the - same consensus directory in each period. Therefore, it isn't necessary to - download the consensus computed by each authority; instead, the - authorities only push/fetch each others' signatures. A "detached - signature" document contains items as follows: + same consensus including any flavors in each period. Therefore, it + isn't necessary to download the consensus or any flavors of it computed + by each authority; instead, the authorities only push/fetch each + others' signatures. A "detached signature" document contains items as + follows: "consensus-digest" SP Digest NL @@ -1920,11 +2089,82 @@ [As in the consensus] + "additional-digest" SP flavor SP algname SP digest NL + + [Any number.] + + For each supported consensus flavor, every directory authority + adds one or more "additional-digest" lines. "flavor" is the name + of the consensus flavor, "algname" is the name of the hash + algorithm that is used to generate the digest, and "digest" is the + hex-encoded digest. + + The hash algorithm for the microdescriptor consensus flavor is + defined as SHA256 with algname "sha256". + + "additional-signature" SP flavor SP algname SP identity SP + signing-key-digest NL signature. + + [Any number.] + + For each supported consensus flavor and defined digest algorithm, + every directory authority adds an "additional-signature" line. + "flavor" is the name of the consensus flavor. "algname" is the + name of the algorithm that was used to hash the identity and + signing keys, and to compute the signature. "identity" is the + hex-encoded digest of the authority identity key of the signing + authority, and "signing-key-digest" is the hex-encoded digest of + the current authority signing key of the signing authority. + + The "sha256" signature format is defined as the RSA signature of + the OAEP+-padded SHA256 digest of the item to be signed. When + checking signatures, the signature MUST be treated as valid if the + signature material begins with SHA256(document), so that other + data can get added later. + [To be honest, I didn't fully understand the previous paragraph + and only copied it from the proposals. Review carefully. -KL] + "directory-signature" [As in the consensus; the signature object is the same as in the consensus document.] +3.8. Consensus index + + Authorities additionally may generate and serve a consensus-index + document. Its format is: + + "consensus-index" SP version NL + + [At start, exactly once.] + + "valid-after" SP YYYY-MM-DD SP HH:MM:SS NL + "valid-until" SP YYYY-MM-DD SP HH:MM:SS NL + + [As in the consensus] + + "document" SP flavor SP length 1*(SP algname "=" digest) NL + + [Any number.] + + There must be one "document" line for each generated consensus + flavor. "length" describes the length of the signed portion of + a consensus (the signatures themselves are not included), along + with one or more "digests" of that signed portion. Digests are + given in hex. The algorithm "sha256" MUST be included; others + are allowed. + [What's the reason for using a different format than in the + "additional-digest" lines of detached signatures? -KL] + + "directory-signature" SP algname SP identity SP signing-key-digest + NL signature + + [Any number.] + + [As "additional-signature" lines in detached signatures, but + without the "flavor" part.] + + [Actually, is it a bug that the "flavor" part is missing? -KL] 4. Directory server operation @@ -2035,6 +2275,15 @@ [XXX possible future features include support for downloading old consensuses.] + An authority further makes the consensus index available at + /tor/status-vote/(current|next)/consensus-index[.z] . + [The URL above is not implemented as of February 21, 2012. -KL] + + The authorities serve another consensus of each flavor "F" from the + locations + /tor/status-vote/(current|next)/consensus-F.z. and + /tor/status-vote/(current|next)/consensus-F/<FP1>+....z. + 4.3. Downloading consensus status documents (caches only) All directory servers (authorities and caches) try to keep a recent @@ -2053,6 +2302,12 @@ and is fresh until 2:00, that cache will fetch a new consensus at a random time between 2:00 and 2:30.] + Directory caches also fetch the consensus index and the referenced + consensus flavors from the authorities. Caches check the correctness + of consensus flavors, but do not check anything about an unrecognized + consensus document beyond its digest and length. Caches serve all + consensus flavors from the same locations as the directory authorities. + 4.4. Downloading and storing router descriptors (authorities and caches) Periodically (currently, every 10 seconds), directory servers check @@ -2087,7 +2342,41 @@ Authorities SHOULD NOT download descriptors for routers that they would immediately reject for reasons listed in 3.1. -4.5. Downloading and storing extra-info documents +4.5. Downloading and storing microdescriptors (caches only) + + Directory mirrors should fetch, cache, and serve each microdescriptor + from the authorities. + + The microdescriptors with base64 hashes <D1>,<D2>,<D3> are available + at: + http://<hostname>/tor/micro/d/<D1>-<D2>-<D3>[.z] + + <Dn> are base-64 encoded with trailing =s omitted for size and for + consistency with the microdescriptor consensus format. -s are used + instead of +s to separate items, since the + character is used in + base64 encoding. + + All the microdescriptors from the current consensus should also be + available at: + http://<hostname>/tor/micro/all[.z] + so a client that's bootstrapping doesn't need to send a 70KB URL just + to name every microdescriptor it's looking for. + [Note that /tor/micro/all[.z] is not implemented as of February 21, + 2012. -KL] + + Directory mirrors should check to make sure that the microdescriptors + they're about to serve match the right hashes (either the hashes from + the fetch URL or the hashes from the consensus, respectively). + + [So, with the consensus index, caches can mirror consensus flavors they + don't understand. But there's no such mechanism to mirror unrecognized + descriptor types which might be referenced from those unrecognized + consensus flavors, right? Would it make sense to produce a descriptor + index to tell caches which descriptors to mirror, even if they don't + understand them? Without that, deploying a new consensus flavor might + take the same time as it takes now. -KL] + +4.6. Downloading and storing extra-info documents All authorities, and any cache that chooses to cache extra-info documents, and any client that uses extra-info documents, should implement this @@ -2103,7 +2392,7 @@ to download from caches. We follow the same splitting and back-off rules as in 4.4 (if a cache) or 5.3 (if a client). -4.6. General-use HTTP URLs +4.7. General-use HTTP URLs "Fingerprints" in these URLs are base-16-encoded SHA1 hashes. @@ -2210,6 +2499,9 @@ fingerprints. Servers MUST accept both upper and lower case fingerprints in requests. + [XXX Add new URLs for microdescriptors, consensus flavors, + microdescriptor consensus, and consensus indexes. -KL] + 5. Client operation: downloading information Every Tor that is not a directory server (that is, those that do @@ -2250,7 +2542,12 @@ of the one-hour interval is 45 minutes, and 7/8 of the remaining 75 minutes is 65 minutes.] -5.2. Downloading and storing router descriptors + Clients may choose to download the microdescriptor consensus instead + of the general network status consensus. In that case they should use + the same update strategy as for the normal consensus. They should not + download more than one consensus flavor. + +5.2. Downloading and storing router descriptors or microdescriptors Clients try to have the best descriptor for each router. A descriptor is "best" if: @@ -2287,6 +2584,19 @@ being published too far in the past.] [The code seems to discard descriptors in all cases after they're 5 days old. True? -RD] + Clients which chose to download the microdescriptor consensus instead + of the general consensus must download the referenced microdescriptors + instead of router descriptors. Clients fetch and cache + microdescriptors preemptively from dir mirrors when starting up, like + they currently fetch descriptors. After bootstrapping, clients only + need to fetch the microdescriptors that have changed. + + Clients maintain a cache of microdescriptors along with metadata like + when it was last referenced by a consensus, and which identity key + it corresponds to. They keep a microdescriptor until it hasn't been + mentioned in any consensus for a week. Future clients might cache them + for longer or shorter times. + 5.3. Managing downloads When a client has no consensus network-status document, it downloads it @@ -2307,6 +2617,14 @@ After receiving any response client MUST discard any network-status documents and descriptors that it did not request. + When a client gets a new microdescriptor consensus, it looks to see if + there are any microdescriptors it needs to learn. If it needs to learn + more than half of the microdescriptors, it requests 'all', else it + requests only the missing ones. Clients MAY try to determine whether + the upload bandwidth for listing the microdescriptors they want is more + or less than the download bandwidth for the microdescriptors they do + not want. + 6. Using directory information Everyone besides directory authorities uses the approaches in this section

1 0

[torspec/master] Merge branch 'task-3038-squashed'
by nickm＠torproject.org 16 May '12

16 May '12

commit 93d89226e73cb535088d4cb4104afefdbdfe83c0 Merge: b1be41c 4d6c1a8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed May 16 11:07:32 2012 -0400 Merge branch 'task-3038-squashed' dir-spec.txt | 305 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 285 insertions(+), 20 deletions(-)

1 0