tor-commits November 2015

tor-commits@lists.torproject.org

20 participants
856 discussions

[torspec/master] prop224: avoid replicas with the same blinded key
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit 8df8c0584392240aa8fecbcd2164a4489be7ae1a Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Nov 20 12:02:51 2015 +1100 prop224: avoid replicas with the same blinded key Each replicas uses one of multiple blinded keys (and a different descriptor signing key) to avoid HSDirs being able to locate other replicas of the service. In combination with the changes to the salt and revision-counter, this also makes it difficult to link descriptors from the same service at all. If descriptors for different replicas cannot be linked, then it becomes much harder for a malicious HSDir to discover other replicas and attept to DoS them. --- proposals/224-rend-spec-ng.txt | 98 ++++++++++++++++++++++++++-------------- 1 file changed, 64 insertions(+), 34 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 612ca2c..8dd30b0 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -372,9 +372,10 @@ Status: Draft In order to download a descriptor, clients must know which blinded signing key was used to sign it. (See the next section for more info on key blinding.) This blinded signing key is derived from the - service's public key and, optionally, an additional secret that is - not part of the hidden service's onion address. The public key and - this secret together constitute the service's "credential". + service's public key, the descriptor replica number, and, optionally, + an additional secret that is not part of the hidden service's onion + address. The public key, replica number, and this secret together + constitute the service's "credential". When the secret is in use, the hidden service gains protections equivalent to the "stealth mode" in previous designs. @@ -414,19 +415,19 @@ Status: Draft positions based on the key that was used to sign them. Note that hidden service descriptors are not signed with the services' public keys directly. Instead, we use a key-blinding system [KEYBLIND] to - create a new key-of-the-day for each hidden service. Any client that - knows the hidden service's credential can derive these blinded - signing keys for a given period. It should be impossible to derive - the blinded signing key lacking that credential. + create new keys-of-the-day for the descriptor replicas for each + hidden service. Any client that knows the hidden service's credential + can derive these blinded signing keys for a given period. It should be + impossible to derive the blinded signing keys lacking that credential. The body of each descriptor is also encrypted with a key derived from the credential. To avoid a "thundering herd" problem where every service generates and uploads a new descriptor at the start of each period, each - descriptor comes online at a time during the period that depends on - its blinded signing key. The keys for the last period remain valid - until the new keys come online. + descriptor replica comes online at a time during the period that + depends on its blinded signing key. The keys for the last period remain + valid until the new keys come online. 1.5. In more detail: Scaling to multiple hosts @@ -483,9 +484,9 @@ Status: Draft in advance). [TODO: Define revocation mechanism?] - It's important to not send the private part of the blinded signing + It's important to not send the private part of a blinded signing key to the Hidden Service since an attacker can derive from it the - secret master identity key. The secret blinded signing key should + secret master identity key. A secret blinded signing key should only be used to create credentials for the descriptor signing keys. 1.8. In more detail: Encryption Keys And Replay Resistance @@ -518,14 +519,16 @@ Status: Draft service's public identity key and an optional secret can derive the public blinded identity key for a service. This key is used as an index in the DHT-like structure of the directory system - (see [SUBCRED]). + (see [SUBCRED]). Each descriptor replica may use a different + blinded signing key, based on its replicanum. Descriptor signing key -- A key used to sign hidden service descriptors. This is signed by blinded signing keys. Unlike blinded signing keys and master identity keys, the secret part of this key must be stored online by hidden service hosts. The public part of this key is included in the unencrypted section - of HS descriptors (see [DESC-OUTER]). + of HS descriptors (see [DESC-OUTER]). Each descriptor replica must + use a different descriptor signing key. Introduction point authentication key -- A short-term signing keypair used to identify a hidden service to a given @@ -546,7 +549,8 @@ Status: Draft Descriptor encryption keys -- A symmetric encryption key used to encrypt the body of hidden service descriptors. Derived from the - current period and the hidden service credential. + current period, the descriptor replica, the descriptor revision, + and the hidden service credential. Public/private keypairs defined elsewhere: @@ -577,6 +581,8 @@ Status: Draft periods), a hidden service host uses a different blinded private key to sign its directory information, and clients use a different blinded public key as the index for fetching that information. + Each descriptor replica for each service may use different blinded + keys. For a candidate for a key derivation method, see Appendix [KEYBLIND]. @@ -593,7 +599,13 @@ Status: Draft The subcredential for a period is derived as: H("subcredential" | credential | - blinded-public-key). + blinded-public-key(replica-keynum)). + + Where replica-keynum = replicanum % hsdir_num_replica_keys. + (This ensures that each replica has a blinded key, even if + hsdir_num_replicas is higher than hsdir_num_replica_keys. This ensures + hidden services can't predict future values of hsdir_num_replicas at + key blinding time.) 2.2. Locating, uploading, and downloading hidden service descriptors [HASHRING] @@ -601,7 +613,9 @@ Status: Draft To avoid attacks where a hidden service's descriptor is easily targeted for censorship, we store them at different directories over time, and use shared random values to prevent those directories from - being predictable far in advance. + being predictable far in advance. Each descriptor replica may use a + different blinded signing key, which prevents directories in one + replica locating directories in other replica(s). Which Tor servers hosts a hidden service depends on: @@ -662,7 +676,8 @@ Status: Draft The time at which a key from the next interval becomes valid is determined by taking the first two bytes of - OFFSET = H("interval-offset" | Key | INT_8(Next_Period_Num)) + OFFSET = H("interval-offset" | blinded-public-key(replica-keynum) | + INT_8(Next_Period_Num)) as a big-endian integer, dividing by 65536, and treating that as a fraction of the overlap interval. @@ -683,11 +698,21 @@ Status: Draft 2.2.3. Where to publish a service descriptor + The following constant controls how many blinded keys are created + per period for the different descriptor replicas: + + hsdir_num_replica_keys = an integer constant 2. + + (Since blinded keys can be generated ahead of time, a service can not + know the value of hsdir_n_replicas at the time the blinded keys will + be used. If hsdir_n_replicas is greater than hsdir_num_replica_keys, + some keys will be used for multiple replicas.) + The following consensus parameters control where a hidden service descriptor is stored; hsdir_n_replicas = an integer in range [1,16] - with default value 2. + with default value hsdir_num_replica_keys. hsdir_spread_fetch = an integer in range [1,128] with default value 3. @@ -699,12 +724,12 @@ Status: Draft with default value 12. To determine where a given hidden service descriptor will be stored - in a given period, after the blinded public key for that period is - derived, the uploading or downloading party calculate + in a given period, after the blinded public key for that period and + replica is derived, the uploading or downloading party calculates: for replicanum in 1...hsdir_n_replicas: hs_index(replicanum) = H("store-at-idx" | - blinded_public_key | + blinded_public_key(replica-keynum) | INT_8(replicanum) | INT_8(periodnum) ) @@ -712,7 +737,8 @@ Status: Draft periodnum is defined in section TIME-PERIODS. where n_replicas is determined by the consensus parameter - "hsdir_n_replicas". + "hsdir_n_replicas", and replica-keynum is replicanum % + hsdir_num_replica_keys. Then, for each node listed in the current consensus with the HSDir3 flag, we compute a directory index for that node as: @@ -761,7 +787,7 @@ Status: Draft /tor/rendezvous3/publish relative to the hidden service directory's root, and downloaded with an HTTP GET request for the URL /tor/rendezvous3/<z> where z is a base-64 encoding of the hidden - service's blinded public key. + service's blinded public key for the replica. [TODO: raw base64 is not super-nice for URLs, since it can have slashes. We already use it for microdescriptor URLs, though. Do we @@ -819,8 +845,9 @@ Status: Draft The 'certificate' field contains a certificate in the format from proposal 220, with the short-term ed25519 descriptor-signing key - signed by the blinded public key. It must contain a - ed25519-signing-key extension containing the blinded public key. + for the replica, signed by the blinded public key for the replica. + It must contain a ed25519-signing-key extension containing the + blinded public key for the replica. "time-period" SP YYYY-MM-DD HH:MM:SS NUM NL @@ -911,7 +938,7 @@ Status: Draft A signature of all previous fields, using the signing key in the hs-descriptor line. We use a separate key for signing, so that the hidden service host does not need to have its private blinded - key online. + keys online. 2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA] @@ -926,8 +953,8 @@ Status: Draft [ XX/teor - is the extra load on the HSDirs worth it? ] - secret_input = blinded_public_key | subcredential | - INT_4(revision_counter) + secret_input = blinded_public_key(replica-keynum) | + subcredential | INT_4(revision_counter) keys = KDF(secret_input, salt, "hsdir-encrypted-data", S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN) @@ -990,9 +1017,10 @@ Status: Draft Base-64 encoded introduction point authentication key that was used to establish introduction point circuit, cross-certifying - the blinded public key. This uses the certificate format of - proposal 220 with type [09]. The signing-key extension is - mandatory here to tell you what the public key is. + the blinded public key for the replica. This uses the + certificate format of proposal 220 with type [09]. The + signing-key extension is mandatory here to tell you what the + public key is. "enc-key" SP "ntor" SP key NL @@ -1784,8 +1812,10 @@ Appendix A. Signature scheme with key blinding [KEYBLIND] possible alternatives. Also, see [KEYBLIND-PROOF] for a security proof of this scheme. - (To use this with Tor, set N = "key-blind" | INT_8(period-number) | - INT_8(Start of period in seconds since epoch).) + (To use this with Tor, set N(replica-keynum) = "key-blind" | + INT_8(period-number) | INT_8(Start of period in seconds since epoch) | + INT_1(replica-keynum), where replica-keynum is from 1 to + hsdir_num_replica_keys.) Appendix B. Selecting nodes [PICKNODES]

1 0

[torspec/master] prop224: use a different salt for each replica and upload
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit 01e865d592ffcbb67a0e6631c56e5b8048ea6065 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Nov 20 11:57:09 2015 +1100 prop224: use a different salt for each replica and upload Use a different salt for each descriptor replica and upload, to avoid matching encrypted blobs, which could be used to link other replicas of the service. If descriptors for different replicas cannot be linked, then it becomes much harder for a malicious HSDir to discover other replicas and attept to DoS them. --- proposals/224-rend-spec-ng.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 2575136..612ca2c 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -919,7 +919,12 @@ Status: Draft The encrypted part of the hidden service descriptor is encrypted and authenticated with symmetric keys generated as follows: - salt = 16 random bytes + salt = 16 random bytes, different for each post to each replica, + even if the content of the descriptor hasn't changed. + (This avoids leaking service stability, and linking replicas + via encrypted data comparison.) + + [ XX/teor - is the extra load on the HSDirs worth it? ] secret_input = blinded_public_key | subcredential | INT_4(revision_counter)

1 0

[torspec/master] Merge branch 'rend-ng-descriptors_squashed'
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit a43c172b6b7cfbe0f94779bcbbf8c6e83087cf71 Merge: a3c4068 8df8c05 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Nov 20 10:38:35 2015 -0500 Merge branch 'rend-ng-descriptors_squashed' proposals/224-rend-spec-ng.txt | 199 +++++++++++++++++++++++++++++++--------- 1 file changed, 156 insertions(+), 43 deletions(-)

1 0

[torspec/master] prop224: note prop252 wants to add extend-info to the descriptor
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit 7df225c3891191442cd550ab52d0ac953fe30e22 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Nov 20 12:00:18 2015 +1100 prop224: note prop252 wants to add extend-info to the descriptor --- proposals/224-rend-spec-ng.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index ecdae13..530cd84 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -876,7 +876,8 @@ Status: Draft bytes with NUL bytes. The plaintext must not be longer than ??? bytes. [TODO: how much? Should this be a parameter? What values in practice is needed to hide how many intro points we have, and how - many might be legacy ones?] + many might be legacy ones? Note that Single Onion Services add extend + intro points as well. ] The plaintext format is:

1 0

[torspec/master] prop224: add distinguishing values to every hash
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit 34e529c65576fbb24406545dad2b222b0aac06f6 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Nov 20 11:36:44 2015 +1100 prop224: add distinguishing values to every hash Some hashes were missing distinguishing values, even though other hashes had them, and the "Cryptographic building blocks" section appears to require them: "all signatures are generated not over strings themselves, but over those strings prefixed with a distinguishing value" --- proposals/224-rend-spec-ng.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 530cd84..ad0947c 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -662,7 +662,7 @@ Status: Draft The time at which a key from the next interval becomes valid is determined by taking the first two bytes of - OFFSET = H(Key | INT_8(Next_Period_Num)) + OFFSET = H("interval-offset" | Key | INT_8(Next_Period_Num)) as a big-endian integer, dividing by 65536, and treating that as a fraction of the overlap interval. @@ -717,7 +717,7 @@ Status: Draft Then, for each node listed in the current consensus with the HSDir3 flag, we compute a directory index for that node as: - hsdir_index(node) = H(node_identity_digest | + hsdir_index(node) = H("node-idx" | node_identity_digest | shared_random | INT_8(period_num) ) @@ -1702,8 +1702,8 @@ Appendix A. Signature scheme with key blinding [KEYBLIND] possible alternatives. Also, see [KEYBLIND-PROOF] for a security proof of this scheme. - (To use this with Tor, set N = INT_8(period-number) | INT_8(Start of - period in seconds since epoch).) + (To use this with Tor, set N = "key-blind" | INT_8(period-number) | + INT_8(Start of period in seconds since epoch).) Appendix B. Selecting nodes [PICKNODES]

1 0

[torspec/master] prop224: hash raw random bytes before use
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit 93f47f4f4e7614d4b3debfe9b5f3a22bfe5d64b1 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Nov 20 11:43:51 2015 +1100 prop224: hash raw random bytes before use Exposing raw random bytes from a PRNG has broken Dual EC: http://projectbullrun.org/dual-ec/ext-rand.html Based on ioerror's feedback on prop250, make similar changes: https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html --- proposals/224-rend-spec-ng.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index ad0947c..2aeb05b 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -865,10 +865,13 @@ Status: Draft The encrypted data has the format: - SALT (random bytes from above) [16 bytes] + H(SALT) H(random bytes from above) [16 bytes] ENCRYPTED The plaintext encrypted with S [variable] MAC MAC of both above fields [32 bytes] + (We hash salt so that we don't leak the raw bytes returned by a PRNG + to the network. See [RANDOM-REFS].) + The encryption format is ENCRYPTED = STREAM(SECRET_IV,SECRET_KEY) xor Plaintext @@ -1479,7 +1482,9 @@ Status: Draft Pubkey [32 bytes] Signature [64 bytes] - Nonce is a random value. Pubkey is the public key that will be used + Nonce is a random value. (Noncen should be derived from hashed PRNG + output, so that we don't leak the raw bytes returned by a PRNG to the + network. See [RANDOM-REFS].) Pubkey is the public key that will be used to authenticate. [TODO: should this be an identifier for the public key instead?] Signature is the signature, using Ed25519, of: @@ -1522,7 +1527,9 @@ Status: Draft by the client. The client SHOULD choose a new rendezvous cookie for each new connection attempt. If the rendezvous cookie is already in use on an existing circuit, the rendezvous point should reject it and - destroy the circuit. + destroy the circuit. RENDEZVOUS_COOKIE should be derived using hashed + PRNG output, so that we don't leak the raw bytes returned by a PRNG + to the network. See [RANDOM-REFS]. Upon receiving a ESTABLISH_RENDEZVOUS cell, the rendezvous point associates the cookie with the circuit on which it was sent. It @@ -1639,6 +1646,9 @@ References: J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. http://cr.yp.to/papers.html#ed25519 +[RANDOM-REFS]: + http://projectbullrun.org/dual-ec/ext-rand.html + https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html Appendix A. Signature scheme with key blinding [KEYBLIND]

1 0

[torspec/master] prop224: deal with replica hashring collisions
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit 3b604e12a8d798b03d3214d76985263fd6ffeb1b Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Nov 20 11:47:40 2015 +1100 prop224: deal with replica hashring collisions If multiple replicas want to use the same HSDir, give it to the lower-numbered replica, and have the higher-numbered replica(s) ignore it when counting nodes. This avoids services choosing the same HSDir for multiple replicas / spreads, and therefore losing redundancy. --- proposals/224-rend-spec-ng.txt | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 2aeb05b..00586fd 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -696,7 +696,7 @@ Status: Draft with default value 3. hsdir_spread_accept = an integer in range [1,128] - with default value 8. + with default value 12. To determine where a given hidden service descriptor will be stored in a given period, after the blinded public key for that period is @@ -727,15 +727,28 @@ Status: Draft Finally, for replicanum in 1...hsdir_n_replicas, the hidden service host uploads descriptors to the first hsdir_spread_store nodes whose - indices immediately follow hs_index(replicanum). + indices immediately follow hs_index(replicanum). If any of those + nodes have already been selected for a lower-numbered replica of the + service, any nodes already chosen are disregarded when choosing a + replica's hsdir_spread_store nodes. + + [ XX/teor - because the positions don't match the key, this might leak + the fact that nodes from other replicas are nearby to a HSDir. + But this is preferable to having fewer HSDirs for a service. + I think the probability of a collision is approximately: + 1 / (n_hsidrs / (hsdir_n_replicas * hsdir_spread_store)) = 6 / n_hsidrs ] When choosing an HSDir to download from, clients choose randomly from among the first hsdir_spread_fetch nodes after the indices. (Note that, in order to make the system better tolerate disappearing HSDirs, hsdir_spread_fetch may be less than hsdir_spread_store.) + Again, nodes from lower-numbered replicas are disregarded when + choosing the spread for a replica. An HSDir should reject a descriptor if that HSDir is not one of the - first hsdir_spread_accept HSDirs for that node. + first hsdir_spread_accept HSDirs for that node. Since HSDirs can't + derive other replicas of a service, hsdir_spread_accept must be at + least hsdir_n_replicas * hsdir_spread_store. [TODO: Incorporate the findings from proposal 143 here. But watch out: proposal 143 did not analyze how much the set of nodes changes

1 0

[torspec/master] prop224: randomise revision-counter to avoid information leaks
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit 01119bf1291a40aa309dfb7d76edf790133f05b9 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Nov 20 11:51:58 2015 +1100 prop224: randomise revision-counter to avoid information leaks Randomise revision-counter start value and increment to avoid leaking: * the descriptor validity start time, * the age of new hidden services, * the stability of a hidden service, * a value that could be used to link other replicas of the service. If descriptors for different replicas cannot be linked, then it becomes much harder for a malicious HSDir to discover other replicas and attept to DoS them. --- proposals/224-rend-spec-ng.txt | 54 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 00586fd..2575136 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -842,6 +842,60 @@ Status: Draft prevents an attacker from replacing a newer descriptor signed by a given key with a copy of an older version.) + The revision-counter should be updated with each upload, regardless + of whether the descriptor has changed. This avoids leaking whether + the descriptor has changed. + + [ XX/teor - is the extra load on the HSDirs worth it? ] + + Services should randomise the start and increment values of + revision-counter for each replica, to avoid leaking service + stability, and avoid linking descriptor replicas via + revision-counter values. + + Say that our goal is for services to start the period at a + random value near zero, and end it at a random value that does + not exceed 2 ^ 32 (while the length of revision-counter isn't + specified, it's included in hashes as INT_4(revision-counter)). We'd + like the revision-counters of all services to increment at + approximately the same randomised rate, regardless of RendPostPeriod. + + revision-counter could be initialised and incremented using: + two-periods-time = (2 * 24 * 60 * 60) + elapsed-ratio = elapsed-since-last-post / two-periods-time + max-increment = 2^32 * elapsed-ratio + where elapsed-since-last-post is the time elapsed since descriptors + were last uploaded for the current blinded key. + + The first upload for a blinded key for the next period sets + elapsed-since-last-post equal to the time since the current period + started. Assuming the keys have just become valid, this is: + elapsed-since-period-start = key-validity-start - period-start + where key-validity-start is when the keys became valid, and + period-start is when the current period started. + + Then, each initialisation and increment is: + revision-counter += random(1, max-increment) + + (The random() function should be careful not to leak the raw bytes + returned by the PRNG to the network. See [RANDOM-REFS].) + + This scheme increments revision-counter at a maximum rate of: + 2 ^ 32 / (2 * 24 * 60 * 60) = 24855 per second + with an expected average value of 12428 per second. This appears + sufficient to blur the exact number of revisions. + + This scheme could leak the approximate time at which the descriptor + was uploaded, and the approximate RendPostPeriod. These are easily + guessed from the current time, and by checking when descriptors + arrive at the HSDirs. Tracking unique revision-counter values would + also reveal how many times a descriptor has been uploaded (without + decrypting "encrypted"). + + Regardless of the method used to generate the revision counter, + all that HSDirs need to do is verify that new descriptors for a key + have a higher counter than the current descriptor. + "encrypted" NL encrypted-string [Exactly once.]

1 0

[webwml/staging] Fix donate page footer
by sebastian＠torproject.org 20 Nov '15

20 Nov '15

commit 9f02c8d3b905948e7489d4a21a996b81bb478a78 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Fri Nov 20 16:34:12 2015 +0100 Fix donate page footer --- donate/en/donate.wml | 55 +----------------------------------------------- include/donatefoot.wmi | 2 +- 2 files changed, 2 insertions(+), 55 deletions(-) diff --git a/donate/en/donate.wml b/donate/en/donate.wml index 1062f42..2b8a0b9 100644 --- a/donate/en/donate.wml +++ b/donate/en/donate.wml @@ -103,57 +103,4 @@ jQuery(function(){ displayVals(); }); </script> - -  - -# include <donatefoot.wmi> +#include <donatefoot.wmi> diff --git a/include/donatefoot.wmi b/include/donatefoot.wmi index 3d42bef..8955182 100644 --- a/include/donatefoot.wmi +++ b/include/donatefoot.wmi @@ -2,7 +2,7 @@ <footer class="container footer"> <div class="col-md-12"> <p class="text-center">The Tor Project is a 501(c)(3) US non-profit organization dedicated to research, development, and education about online anonymity and privacy.<br /> - <a href="donor-privacy-policy.html">Privacy Policy</a> & <a href="donor-faq.html">Donor FAQ</a></p> + <a href="<page donate/donor-privacy-policy>">Privacy Policy</a> & <a href="<page donate/donor-faq>">Donor FAQ</a></p> </div> </footer>

1 0

[torspec/master] Prop Rendezvous Single Onion
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit b38f1e8b6c47653639dd903103a8a245285ada2c Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Oct 23 01:08:41 2015 +1100 Prop Rendezvous Single Onion An updated and expanded version of "Direct Onion Services: Fast-but-not-hidden services”. Also borrows heavily from "Single Onion Services" (Proposal #252). --- proposals/ideas/xxx-rend-single-onion.txt | 449 +++++++++++++++++++++++++++++ 1 file changed, 449 insertions(+) diff --git a/proposals/ideas/xxx-rend-single-onion.txt b/proposals/ideas/xxx-rend-single-onion.txt new file mode 100644 index 0000000..5cfbe1a --- /dev/null +++ b/proposals/ideas/xxx-rend-single-onion.txt @@ -0,0 +1,449 @@ +Filename: xxx-rend-single-onion.txt +Title: Rendezvous Single Onion Services +Author: Tim Wilson-Brown, John Brooks, Aaron Johnson, Rob Jansen, George Kadianakis, Paul Syverson, Roger Dingledine +Created: 2015-10-17 +Status: Draft + +1. Overview + + Rendezvous single onion services are an alternative design for single onion + services, which trade service-side location privacy for improved + performance, reliability, and scalability. + + Rendezvous single onion services have a .onion address identical to any + other onion service. The descriptor contains the same information as the + existing double onion (hidden) service descriptors. The introduction point + and rendezvous protocols occur as in double onion services, with one + modification: one-hop connections are made from the onion server to the + introduction and rendezvous points. + + This proposal is a revision of the unnumbered proposal Direct Onion + Services: Fast-but-not-hidden services by Roger Dingledine, and George + Kadianakis at + https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html + + It incorporates much of the discussion around hidden services since April + 2015, including content from Single Onion Services (Proposal #252) by John + Brooks, Paul Syverson, and Roger Dingledine. + +2. Motivation + + Rendezvous single onion services are best used by sites which: + * Don’t require location anonymity + * Would appreciate lower latency or self-authenticated addresses + * Would like to work with existing tor clients and relays + * Can’t accept connections to an open ORPort + + Rendezvous single onion services have a few benefits over double onion + services: + + * Connection latency is lower, as one-hop circuits are built to the + introduction and rendezvous points, rather than three-hop circuits + * Stream latency is reduced on a four-hop circuit + * Less Tor network capacity is consumed by the service, as there are + fewer hops (4 rather than 6) between the client and server via the + rendezvous point + + Rendezvous single onion services have a few benefits over single onion + services: + + * A rendezvous single onion service can load-balance over multiple + rendezvous backends (see proposal #255) + * A rendezvous single onion service doesn't need an accessible ORPort + (it works behind a NAT, and in server enclaves that only allow + outward connections) + * A rendezvous single onion service is compatible with existing tor + clients, hidden service directories, introduction points, and + rendezvous points + + Rendezvous single onion services have a few drawbacks over single onion + services: + + * Connection latency is higher, as one-hop circuits are built to the + introduction and rendezvous points. Single onion services perform one + extend to the single onion service’s ORPort only + + It should also be noted that, while single onion services receive many + incoming connections from different relays, rendezvous single onion + services make many outgoing connections to different relays. This should + be taken into account when planning the connection capacity of the + infrastructure supporting the onion service. + + Rendezvous single onion services are not location hidden on the service + side, but clients retain all of the benefits and privacy of onion + services. (The rationale for the 'single' and 'double' nomenclature is + described in section 7.4 of proposal #252.) + + We believe that it is important for the Tor community to be aware of the + alternative single onion service designs, so that we can reach consensus + on the features and tradeoffs of each design. However, we recognise that + each additional flavour of onion service splits the anonymity set of onion + service users. Therefore, it may be best for user anonymity that not all + designs are adopted, or that mitigations are implemented along with each + additional flavour. (See sections 8 & 9 for a further discussion.) + +3. Onion descriptors + + The rendezvous single onion descriptor format is identical to the double + onion descriptor format. + +4. Reaching a rendezvous single onion service as a client + + Clients reach rendezvous single onion services in an identical fashion + to double onion services. The rendezvous design means that clients do not + know whether they are talking to a double or rendezvous single onion + service, unless that service tells them. (This may be a security issue.) + + However, the use of a four-hop path between client and rendezvous single + onion service may be statistically distinguishable. (See section 8 for + further discussion of security issues.) + + (Please note that this proposal follows the hop counting conventions in the + tor source code. A circuit with a single connections between the client and + the endpoint is one-hop, a circuit with 4 connections (and 3 nodes) between + the client and endpoint is four-hop.) + +5. Publishing a rendezvous single onion service + + To act as a rendezvous single onion service, a tor instance (or cooperating + group of tor instances) must: + + * Publish onion descriptors in the same manner as any onion service, + using three-hop circuits. This avoids service blocking by IP address, + proposal #224 (next-generation hidden services) avoids blocking by + onion address. + * Perform the rendezvous protocol in the same manner as a double + onion service, but make the intro and rendezvous connections one-hop. + (This may allow intro and rendezvous points to block the service.) + +5.1. Configuration options + +5.1.1 RendezvousSingleOnionServiceNonAnonymousServer + + The tor instance operating a rendezvous single onion service must make + one-hop circuits to the introduction and rendezvous points: + + RendezvousSingleOnionServiceNonAnonymousServer 0|1 + If set, make one-hop circuits between the Rendezvous Single Onion + Service server, and the introduction and rendezvous points. This + option makes every onion service instance hosted by this tor instance + a Rendezvous Single Onion Service. (Default: 0) + + Because of the grave consequences of misconfiguration here, we have added + ‘NonAnonymous’ to the name of the torrc option. Furthermore, Tor MUST issue + a startup warning message to operators of the onion service if this feature + is enabled. + [Should the name start with ‘NonAnonymous’ instead?] + + As RendezvousSingleOnionServiceNonAnonymousServer modifies the behaviour + of every onion service on a tor instance, it is impossible to run hidden + (double onion) services and rendezvous single onion services on the same + tor instance. This is considered a feature, as it prevents hidden services + from being discovered via rendezvous single onion services on the same tor + instance. + +5.1.2 Recommended Additional Options: Correctness + + Based on the experiences of Tor2Web with one-hop paths, operators should + consider using the following options with every rendezvous single onion + service, and every single onion service: + + UseEntryGuards 0 + One-hop paths do not use entry guards. This also deactivates the entry + guard pathbias code, which is not compatible with one-hop paths. Entry + guards are a security measure against Sybil attacks. Unfortunately, + they also act as the bottleneck of busy onion services and overload + those Tor relays. + + LearnCircuitBuildTimeout 0 + Learning circuit build timeouts is incompatible with one-hop paths. + It also creates additional, unnecessary connections. + + Perhaps these options should be set automatically on (rendezvous) single + onion services. Tor2Web sets these options automatically: + UseEntryGuards 0 + LearnCircuitBuildTimeout 0 + +5.1.3 Recommended Additional Options: Performance + + LongLivedPorts + The default LongLivedPorts setting creates additional, unnecessary + connections. This specifies no long-lived ports (the empty list). + + PredictedPortsRelevanceTime 0 seconds + The default PredictedPortsRelevanceTime setting creates additional, + unnecessary connections. + + RendPostPeriod 0 seconds + This option typically hides the startup time of a hidden service by + randomly posting over a 2 hour period. Since single onion services + value speed over anonymity, they can post descriptors straight away. + (Actually, 30 seconds after they bootstrap, for descriptor stability.) + + However, we do not recommend setting the following option to 1, unless bug + #17359 is resolved so tor onion services can bootstrap without predicted + circuits. + + __DisablePredictedCircuits 0 + This option disables all predicted circuits. It is equivalent to: + LearnCircuitBuildTimeout 0 + LongLivedPorts + PredictedPortsRelevanceTime 0 seconds + And turning off hidden service server preemptive circuits, which is + currently unimplemented (#17360) + +5.1.3 Recommended Additional Options: Security + + We recommend that no other services are run on a rendezvous single onion + service tor instance. Since tor runs as a client (and not a relay) by + default, rendezvous single onion service operators should set: + + SocksPort 0 + Disallow connections from client applications to the tor network + via this tor instance. + + ClientOnly 1 + Even if the defaults file configures this instance to be a relay, + never relay any traffic or serve any descriptors. + +5.2. Publishing descriptors + + A single onion service must publish descriptors in the same manner as any + onion service, as defined by rend-spec. + +5.3. Authorization + + Client authorization for a rendezvous single onion service is possible via + the same methods used for double onion services. + +6. Related Proposals, Tools, and Features + +6.1. Load balancing + + High capacity services can distribute load and implement failover by: + * running multiple instances that publish to the same onion service + directories, + * publishing descriptors containing multiple introduction points + (OnionBalance), + * publishing different introduction points to different onion service + directories (OnionBalance upcoming(?) feature), + * handing off rendezvous to a different tor instance via control port + messages (proposal #255), + or by a combination of these methods. + +6.2. Ephemeral single onion services (ADD_ONION) + + The ADD_ONION control port command could be extended to support ephemerally + configured rendezvous single onion services. Given that + RendezvousSingleOnionServiceNonAnonymousServer modifies the behaviour of + all onion services on a tor instance, if it is set, any ephemerally + configured onion service should become a rendezvous single onion service. + +6.3. Proposal 224 ("Next-Generation Hidden Services") + + This proposal is compatible with proposal 224, with onion services + acting just like a next-generation hidden service, but making one-hop + paths to the introduction and rendezvous points. + +6.4. Proposal 246 ("Merging Hidden Service Directories and Intro Points") + + This proposal is compatible with proposal 246. The onion service will + publish its descriptor to the introduction points in the same manner as any + other onion service. Clients will use the merged hidden service directory + and introduction point just as they do for other onion services. + +6.5. Proposal 252 ("Single Onion Services") + + This proposal is compatible with proposal 252. The onion service will + publish its descriptor to the introduction points in the same manner as any + other onion service. Clients can then choose to extend to the single onion + service, or continue with the rendezvous protocol. + + Running a rendezvous single onion service and single onion service allows + older clients to connect via rendezvous, and newer clients to connenct via + extend. This is useful for the transition period where not all clients + support single onion services. + +6.5. Proposal 255 ("Hidden Service Load Balancing") + + This proposal is compatible with proposal 255. The onion service will + perform the rendezvous protocol in the same manner as any other onion + service. Controllers can then choose to handoff the rendezvous point + connection to another tor instance, which should also be configured + as a rendezvous single onion service. + +7. Considerations + +7.1 Modifying RendezvousSingleOnionServiceNonAnonymousServer at runtime + + Implementations should not reuse introduction points or introduction point + circuits if the value of RendezvousSingleOnionServiceNonAnonymousServer is + different than it was when the introduction point was selected. This is + because these circuits will have an undesirable length. + + There is specific code in tor that preserves introduction points on a HUP, + if RendezvousSingleOnionServiceNonAnonymousServer has changed, all circuits + should be closed, and all introduction points must be discarded. + +7.2 Delaying connection expiry + + Tor clients typically expire connections much faster than tor relays + [citation needed]. + + (Rendezvous) single onion service operators may find that keeping + connections open saves on connection latency. However, it may also place an + additional load on the service. (This could be implemented by increasing the + configured connection expiry time.) + +7.3. (No) Benefit to also running a Tor relay + + In tor Trac ticket #8742, running a relay and hidden onion service on the + same tor instance was disabled for security reasons. While there may be + benefits to running a relay on the same instance as a rendezvous single + onion service (existing connections mean lower latency, it helps the tor + network overall), a security analysis of this configuration has not yet + been performed. In addition, a potential drawback is overloading a busy + single onion service. + +6.4 Predicted circuits + + We should look whether we can optimize further the predicted circuits that + Tor makes as a onion service for this mode. + +8. Security Implications + +8.1 Splitting the Anonymity Set + + Each additional flavour of onion service, and each additional externally + visible onion service feature, provides oportunities for fingerprinting. + + Also, each additional type of onion service shrinks the anonymity set for + users of double onion (hidden) services who require server location + anonymity. These users benefit from the cover provided by current users of + onion services, who use them for client anonymity, self-authentication, + NAT-punching, or other benefits. + + For this reason, features that shrink the double onion service anonymity + set should be carefully considered. The benefits and drawbacks of + additional features also often depend on a particular threat model. + + It may be that a significant number of users and sites adopt (rendezvous) + single onion services due to their benefits. This could increase the + traffic on the tor network, therefore increasing anonymity overall. + However, the unique behaviour of each type of onion service may still be + distinguishable from both the client and server ends of the connection. + +8.2 Hidden Service Designs can potentially be more secure + + As a side-effect, by optimizing for performance in this feature, it + allows us to lean more heavily towards security decisions for + regular onion services. + +8.3 One-hop onion service paths may encourage more attacks + + There's a possible second-order effect here since both encrypted + services and hidden services will have foo.onion addresses and it's + not clear based on the address whether the service will be hidden -- + if *some* .onion addresses are easy to track down, are we encouraging + adversaries to attack all rendezvous points just in case? + +9. Further Work + +Further proposals or research could attempt to mitigate the anonymity-set +splitting described in section 8. Here are some initial ideas. + +9.1 Making Client Exit connections look like Client Onion Service Connections + + A mitigation to this fingerprinting is to make each (or some) exit + connections look like onion service connections. This provides cover for + particular types of onion service connections. Unfortunately, it is not + possible to make onion service connections look like exit connections, + as there are no suitable dummy servers to exit to on the Internet. + +9.1.1 Making Client Exit connections perform Descriptor Downloads + + (Some) exit connections could perform a dummy descriptor download. + (However, descriptors for recently accessed onion services are cached, so + dummy downloads should only be performed occasionally.) + + Exit connections already involve a four-hop "circuit" to the server + (including the connection between the exit and the server on the Internet). + The server on the Internet is not included in the consensus. Therefore, + this mitigation would effectively cover single onion services which are not + relays. + +9.1.2 Making Client Exit connections perform the Rendezvous Protocol + + (Some) exit connections could perform a dummy rendezvous protocol. + + Exit connections already involve a four-hop "circuit" to the server + (including the connection between the exit and the server on the Internet). + Therefore, this mitigation would effectively cover rendezvous single onion + services, as long as a dummy descriptor download was also performed + occasionally. + +9.1.3 Making Single Onion Service rendezvous points perform name resolution + + Currently, Exits perform DNS name resolution, and changing this behaviour + would cause unacceptable connection latency. Therefore, we could make + onion service connections look like exit connections by making the + rendezvous point do name resolution (that is, descriptor fetching), and, if + needed, the introduction part of the protocol. This could potentially + *reduce* the latency of single onion service connections, depending on the + length of the paths used by the rendezvous point. + + However, this change makes rendezvous points almost as powerful as Exits, + a careful security analysis will need to be performed before this is + implemented. + + There is also a design issue with rendezvous name resolution: a client + wants to leave resolution (descriptor download) to the RP, but it doesn't + know whether it can use the exit-like protocol with an RP until it has + downloaded the descriptor. This might mean that single onion services of + both flavours need a different address style or address namespace. We could + use .single.onion or something. (This would require an update to the HSDir + code.) + +9.2 Performing automated and common queries over onion services + + Tor could create cover traffic for a flavour of onion service by performing + automated or common queries via an onion service of that type. In addition, + onion service-based checks have security benefits over DNS-based checks. + See Genuine Onion, Syverson and Boyce, 2015, at + http://www.nrl.navy.mil/itd/chacs/syverson-genuine-onion-simple-fast-flexib… + + Here are some examples of automated queries that could be performed over + an onion service: + +9.2.1 torcheck over onion service + + torcheck ("Congratulations! This browser is configured to use Tor.") could + be retrieved from an onion service. + + Incidentally, this would resolve the exitmap issues in #17297, but it + would also fail to check that exit connections work, which is important for + many Tor Browser users. + +9.2.2 Tor Browser version checks over onion service + + Running tor browser version checks over an onion service seems to be an + excellent use-case for onion services. It would also have the Tor Project + "eating its own dogfood", that is, using onion services for its essential + services. + +9.2.3 Tor Browser downloads over onion service + + Running tor browser downloads over an onion service might require some work + on the onion service codebase to support high loads, load-balancing, and + failover. It is a good use case for a (rendezvous) single onion service, + as the traffic over the tor network is only slightly higher than for + Tor Browser downloads over tor. (4 hops for [R]SOS, 3 hops for Exit.) + +9.2.4 SSL Observatory submissions over onion service + + HTTPS certificates could be submitted to HTTPS Everywhere's SSL Observatory + over an onion service. + + This option is disabled in Tor Browser by default. Perhaps some users would + be more comfortable enabling submission over an onion service, due to the + additional security benefits.

1 0

← Newer
1
...
20
21
22
23
24
25
26
...
86
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits November 2015