- tor-dev - lists.torproject.org

tor weather warning tor ops about expiring signing keys?
by nusenu 28 Nov '15

28 Nov '15

Hi, I'm wondering if a service like a future tor weather could have an additional check to warn relay ops about key expiry: (something like "Email me when the router's signing key is about to expire") Do relays disclose the fact that they are run via OfflineMasterKey 1? Do dir auths/tor clients see when a currently used signing key is about to expire? thanks

1 0

documentation for new offline master key functionality (--keygen is undocumented)
by nusenu 28 Nov '15

28 Nov '15

Hi, since tor 0.2.7.5 is apparently not very far [1] from being released I was wondering whether there is any documentation about the new offline master key functionality? (or is this undocumented because it is not considered for general use yet?) tor v0.2.7.4-rc's manual has the following: " SigningKeyLifetime N days|weeks|months For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept offline, and periodically generates new "signing" keys that it uses online. This option configures their lifetime. (Default: 30 days) OfflineMasterKey 0|1 If non-zero, the Tor relay will never generate or load its master secret key. Instead, you’ll have to use "tor --keygen" to manage the master secret key. (Default: 0) " but doesn't say anything about --keygen itself [2]. The 0.2.7.x mentions also a '--newpass' option that I wasn't able to find in the manpage: " - Add a new OfflineMasterKey option to tell Tor never to try loading or generating a secret Ed25519 identity key. You can use this in combination with tor --keygen to manage offline and/or encrypted Ed25519 keys. Implements ticket 16944. - Add a --newpass option to allow changing or removing the passphrase of an encrypted key with tor --keygen. Implements part of ticket 16769. - On receiving a HUP signal, check to see whether the Ed25519 signing key has changed, and reload it if so. Closes ticket 16790. " Can a tor operator use one offline master key for several relays (that are running at the same time) or is one master key required for every relay? (I assume the latter) How does the process of renewing the signing keys look like? According to the logs I assume simple run tor --keygen again and copy ed25519_signing_cert + ed25519_signing_secret_key to the relay's /keys folder the logs say: "It looks like I need to generate and sign a new medium-term signing key, because you asked me to make one with --keygen. To do that, I need to load the permanent master identity key." Does a tor operator has to SIGHUP a running tor instance after copying the new signing keys to the appropriate folder or will tor attempt to reload that file as soon as this signing key expires? How can a tor relay op display a given signing key's expiry date? Does using the offline master key functionality imply that the relay will only have an ed25519 and no RSA key? Is the offline master key limited to ed25519 keys and useless while using ed25519 + RSA keys at the same time? (because the RSA key is not offline?) thanks! [1] https://lists.torproject.org/pipermail/tor-consensus-health/2015-November/0… [2] https://trac.torproject.org/projects/tor/ticket/17583

5 13

tor ignores --SigningKeyLifetime when keys exist
by nusenu 28 Nov '15

28 Nov '15

(thread split from [1]) s7r wrote: > - - when you run tor --orport [...] just to generate the keys in a > non-interactive way, include a PublishServerDescriptor 0 in the > command as well, send the log to /dev/null and terminate the process > immediately. The descriptor will have to be published by the Tor > process actually running the relay. If the master id private key is > not encrypted, --keygen should be able to renew the medium term > signing key in a non-interactive way. But it's not a big deal if you > decide to do it with tor --orport [...] if it's easier for you this way. Turns out my workaround to generate keys without a passphrase non-interactively is not working entirely in every case since tor apparently ignores --SigningKeyLifetime (when used without --keygen) when keys exist: Signing keys are not (re)generated according to the (new) SigningKeyLifetime parameter (signing key/cert remains unchanged). reproducer: mkdir tdata tor --PublishServerDescriptor 0 --orport 1234 --datadirectory tdata --list-fingerprint --quiet (new signing key with default expiry created) attempt to change (reduce) expiry: tor --PublishServerDescriptor 0 --orport 1234 --datadirectory tdata --SigningKeyLifetime "1 week" --list-fingerprint --quiet expected result: key lifetime is reduced to 7 days actual result: key lifetime is not changed (remains at 1 month) (invoking tor with --keygen causes the expected lifetime but can not be run non-interactively if keys do not exist) So I reopened [2]. [1] https://lists.torproject.org/pipermail/tor-dev/2015-November/009959.html [2] https://trac.torproject.org/projects/tor/ticket/17127

2 4

Special handling of .onion domains in Chrome/Firefox (post-IETF-standarization)
by George Kadianakis 27 Nov '15

27 Nov '15

Hello, as you might know, the IETF recently decided to formally recognize .onion names as special-use domain names [0]. This means that normal browsers like Chrome and Firefox can now handle onion domains in a special manner since they know that they only correspond to Tor. How would we like those browsers to treat onions? For starters, those browsers should refuse to connect to onion domains entirely. Onions don't work on normal browsers anyway, and also this will reduce the onion leakage through the DNS system [1]. An extra measure would be to persuade those browser vendors to display some sort of message to poor people who click onions using their normal browser. For example they could display: Oops, seems like you visited an onion link. You need a special anonymous browser for this: www.torproject.org What else could we do here? And is there anyone who can lobby for the right behavior? :) Of course, we all know that that inevitably those browsers will need to bundle Tor, if they want to visit the actually secure onion Internet. But let's give them a bit more time till they realize this :) Cheers! [0]: https://blog.torproject.org/blog/landmark-hidden-services-onion-names-reser… https://www.rfc-editor.org/rfc/rfc7686.txt https://www.iana.org/assignments/special-use-domain-names/special-use-domai… [1]: https://www.petsymposium.org/2014/papers/Thomas.pdf

4 3

help
by Juan Berner 20 Nov '15

20 Nov '15

2015-11-20 17:24 GMT+01:00 <tor-dev-request(a)lists.torproject.org>: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Shared random value calculation edge cases (proposal 250) > (George Kadianakis) > 2. Re: Shared random value calculation edge cases (proposal 250) > (David Goulet) > 3. Re: Shared random value calculation edge cases (proposal 250) > (David Goulet) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Nov 2015 16:06:59 +0200 > From: George Kadianakis <desnacked(a)riseup.net> > To: s7r <s7r(a)sky-ip.org> > Cc: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Shared random value calculation edge cases > (proposal 250) > Message-ID: <87fv0069z0.fsf(a)riseup.net> > Content-Type: text/plain > > s7r <s7r(a)sky-ip.org> writes: > > > Hello, > > > > <snip> > > > > The idea of adding flags in the votes so each dirauth can advertise if > > it is participating (has an opinion for the <current> SR or not) is > > great and helps us build more defenses, probably make it easier in the > > future too if we decide to change anything. > > > > What if the consensus for SR calculation would define majority based > > on dirauths actually participating (and advertising so with a flag in > > the vote). Also, the participating or not participating flag should be > > used per vote/consensus and split into: > > > > a) we know current SR value for today so we vote it > > or > > we know previous SR value and we know for sure if we should follow the > > disaster protocol or not (in case we are about to vote at 01:00 UTC). > > so > > We participate in the vote for <current SR>. > > > > b) we are able to participate in this protocol run which will > > calculate the SR value for next day (after 00:00 UTC) so we send our > > commits/reveals. > > > > This is useful in case we are a dirauth that joined at 00:30 UTC and > > we couldn't get the _latest_ consensus (to find out if the 00:00 UTC > > consensus was created, and if not, previous SR value so we can follow > > the disaster procedure) we will not have an opinion for the <current> > > SR value at 01:00 UTC, but we can start participating in the protocol > > run for the next day - send our commit values. Once we decided on a > > <current> SR value for that day we save it and vote normally next time. > > > > So, if we have 5 dirauths running/signing consensus in total, out of > > which only 4 participate in the shared randomness protocol, the 4 > > participating ones should be able to create a valid consensus > > themselves with the insurance that the 5th one won't break consensus. > > > > One way to do this is: the dirauth which is not participating will > > take the SR value voted by the majority of the participating dirauths > > and include that in its consensus and sign. We need at least 3 > > dirauths agreeing on a SR value in order to accept it. > > > > Is this crazy? It shouldn't open the door new attacks, since this > > doesn't allow a single actor to game it, only the majority could game it. > > > > Thanks for the suggestions. > > Let me try to suggest a procedure here based on your ideas and some other > ideas. > > [Notation: SRV = shared random value] > > The goal here is to minimize the edge cases during SRV calculation and > disaster > SRV calculation. The edge cases here appear because there is no clear view > on > whether other dirauths know the current or previous SRVs, or whether the > SRV for > this period was ever created. The disaster recovery scenario is especially > annoying here. > > Here are some edge cases for example: > > * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain > any > SR information (maybe because not enough SR-enabled dirauths > participated at > that time). > > Should the dirauth do the disaster recovery procedure, or just play it > cool > and put no SR information on the consensus? If it has to do disaster > recovery, > then what previous SRV does it use (the 01:00UTC consensus did not > contain > such info)? > > This type of edge case is my main concern, since with dirauths upgrading > and > going offline at random times, it's likely that we will eventually > create a > consensus without SR info in the middle of the protocol run. > > * Dirauth boots up at 23:55UTC without having a previous consensus. It is > supposed to vote and form a 00:00UTC consensus without knowing any > previous > SRVs. How does it figure out whether all the other dirauths are also > bootstrapping, or whether the other dirauths actually know the previous > SRVs? > > Here are some prerequisites for the logic I'm going to suggest. The two > first > suggestions are useful in any case, I think: > > - First of all, we treat consensuses as trusted, so dirauths MUST learn > previous/current SRVs they didn't know about from any consensus they > fetch. > > - We are also going to assume that we have some sort of "SR flag" on votes > to > denote whether the dirauth participates in the protocol. > > - We are introducing another 'status' for shared random values (see > [SRVOTE]). > > Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be > created, or it did not contain any SRV information, then it sets the > status of > "shared-rand-current-value" in its votes to "none". > > Now we are going to use the SRV lines in the votes as an indicator on how > the > consensus creation should play out. > > > ================================================================================ > > Here is some logic for the consensus at 00:00UTC: > > if majority of votes have disabled the SR flag: > then don't write anything SR-related to consensus > exit > > If the majority of votes contain the previous SRV value: > then calculate SRV as detailed in section [SRCALC] > else: > then calculate SRV as in [SRCALC] but with previous_SRV set > to 0 > > And here is some logic for all the other consensuses (to figure out when > dirauths should perform the disaster procedure): > > if majority of votes have disabled the SR flag: > then don't write anything SR-related to consensus > exit > > if we know the current SRV: > then write it on the consensus > exit > > if the majority of votes have the current SRV status as "none" _AND_ > those votes also contain the previous SRV value: > then do the disaster SRV procedure > else: > then don't write anything SR-related to consensus > > > ================================================================================ > > This _might_ work for fixing a good bunch of edge cases. But is it far too > complex? > > Should we just assume that these things will never happen on the real > network > and avoid baking additional complexity? What do you think? :/ > > > > > ------------------------------ > > Message: 2 > Date: Fri, 20 Nov 2015 10:19:07 -0500 > From: David Goulet <dgoulet(a)ev0ke.net> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Shared random value calculation edge cases > (proposal 250) > Message-ID: <20151120151907.GD10269@raoul> > Content-Type: text/plain; charset="us-ascii" > > On 20 Nov (16:06:59), George Kadianakis wrote: > > s7r <s7r(a)sky-ip.org> writes: > > > > > Hello, > > > > > > <snip> > > > > > > The idea of adding flags in the votes so each dirauth can advertise if > > > it is participating (has an opinion for the <current> SR or not) is > > > great and helps us build more defenses, probably make it easier in the > > > future too if we decide to change anything. > > > > > > What if the consensus for SR calculation would define majority based > > > on dirauths actually participating (and advertising so with a flag in > > > the vote). Also, the participating or not participating flag should be > > > used per vote/consensus and split into: > > > > > > a) we know current SR value for today so we vote it > > > or > > > we know previous SR value and we know for sure if we should follow the > > > disaster protocol or not (in case we are about to vote at 01:00 UTC). > > > so > > > We participate in the vote for <current SR>. > > > > > > b) we are able to participate in this protocol run which will > > > calculate the SR value for next day (after 00:00 UTC) so we send our > > > commits/reveals. > > > > > > This is useful in case we are a dirauth that joined at 00:30 UTC and > > > we couldn't get the _latest_ consensus (to find out if the 00:00 UTC > > > consensus was created, and if not, previous SR value so we can follow > > > the disaster procedure) we will not have an opinion for the <current> > > > SR value at 01:00 UTC, but we can start participating in the protocol > > > run for the next day - send our commit values. Once we decided on a > > > <current> SR value for that day we save it and vote normally next time. > > > > > > So, if we have 5 dirauths running/signing consensus in total, out of > > > which only 4 participate in the shared randomness protocol, the 4 > > > participating ones should be able to create a valid consensus > > > themselves with the insurance that the 5th one won't break consensus. > > > > > > One way to do this is: the dirauth which is not participating will > > > take the SR value voted by the majority of the participating dirauths > > > and include that in its consensus and sign. We need at least 3 > > > dirauths agreeing on a SR value in order to accept it. > > > > > > Is this crazy? It shouldn't open the door new attacks, since this > > > doesn't allow a single actor to game it, only the majority could game > it. > > > > > > > Thanks for the suggestions. > > > > Let me try to suggest a procedure here based on your ideas and some > other ideas. > > > > [Notation: SRV = shared random value] > > > > The goal here is to minimize the edge cases during SRV calculation and > disaster > > SRV calculation. The edge cases here appear because there is no clear > view on > > whether other dirauths know the current or previous SRVs, or whether the > SRV for > > this period was ever created. The disaster recovery scenario is > especially > > annoying here. > > > > Here are some edge cases for example: > > > > * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not > contain any > > SR information (maybe because not enough SR-enabled dirauths > participated at > > that time). > > > > Should the dirauth do the disaster recovery procedure, or just play it > cool > > and put no SR information on the consensus? If it has to do disaster > recovery, > > then what previous SRV does it use (the 01:00UTC consensus did not > contain > > such info)? > > > > This type of edge case is my main concern, since with dirauths > upgrading and > > going offline at random times, it's likely that we will eventually > create a > > consensus without SR info in the middle of the protocol run. > > > > * Dirauth boots up at 23:55UTC without having a previous consensus. It is > > supposed to vote and form a 00:00UTC consensus without knowing any > previous > > SRVs. How does it figure out whether all the other dirauths are also > > bootstrapping, or whether the other dirauths actually know the > previous SRVs? > > > > Here are some prerequisites for the logic I'm going to suggest. The two > first > > suggestions are useful in any case, I think: > > > > - First of all, we treat consensuses as trusted, so dirauths MUST learn > > previous/current SRVs they didn't know about from any consensus they > fetch. > > Yes ++. > > A dirauth booting up should always try to learn the current and previous > SRV from the latest consensus (< 24h) and update the disk state > accordingly _even_ if the disk state has SRV values in there. We should > trust the consensus voted by majority before our disk state imo. > > > > > - We are also going to assume that we have some sort of "SR flag" on > votes to > > denote whether the dirauth participates in the protocol. > > The requirements for having that flag "on" or "off" eludes me a bit. I > assume that this SR flag is "on" when a dirauth thinks its able to > compute a valid SRV that is I have enough commits. We can't make "having > the previous SRV" a requirement else we will never bootstrap properly > ever since in the first runs, previous SRV is alway 0. > > > > > - We are introducing another 'status' for shared random values (see > [SRVOTE]). > > > > Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be > > created, or it did not contain any SRV information, then it sets the > status of > > "shared-rand-current-value" in its votes to "none". > > Hrm... I'm wondering here if "none" status is instead the same of having > the dirauth putting the disaster value in the vote? > > I would argue that a dirauth should _always_ try to compute a SR value > at any time (even when booting). Between having no line because we > couldn't compute due to lack of commits or a line that is the disaster, > I think the former simplifies things that is "We always have a SRV value > at 00:00 from a dirauth". > > Here is what I propose: > > 1) Like you said, we always try to learn SRV values from previous > consensus. If we can't get one from a consensus or our state, compute > disaster at 00:00. > > 2) We do _not_ use a SR flag for vote, a dirauth always tries to compute > a current SRV value at 00:00. If it's 13:00, it simply doesn't put > anything in the vote since no SRV data. > > The big issue I see here is when a dirauth does _not_ have the previous > SRV. Without it, both disaster and current SRV computation will end up > not matching the majority. So let's explore this binary state: > > - I have the previous SRV (either I can get it from my state or > consensus). > > This seems a non issue, dirauth will use it, carry it in the vote and > compute the current SRV if enough commits have been seen. At 00:00, if > majority wasn't reached for the current SRV value, we have a consensus > without it which is a valid use case but we at least have the previous > one in the consensus flagged as non-fresh so it can be used for > disaster or SRV computation at the next protocol run. > > - I don't have a previous SRV (couldn't get it in the latest consensus > and I have _no_ disk state). > > For instance, if this happens at 23:30, a dirauth won't have the > chance to participate in the SR protocol because it didn't see any > commits to compute SRV value thus disaster mode engage. > > If that dirauth was the 5th one out of 9 (meaning the majority > breaker), we end up with no SRV values at all at 00:00 (not even the > previous SRV since only 4/9 had it). So a new protocol run starts, > we'll end up with a valid current SRV in 24 hours and both values in > 48 hours. Essentially, we end up back in bootstrap mode. > > IMPORTANT note here: I think a dirauth MUST NOT keep any SRV values > that aren't in the 00:00 consensus. > > Question is, how big of a deal it is to have this issue where if we > don't reach majority because a dirauth rebooted and for some magical > reason didn't get the latest consensus to at least get the previous > SRV, we return in bootstrap? > > Cheers! > David > > > > > Now we are going to use the SRV lines in the votes as an indicator on > how the > > consensus creation should play out. > > > > > ================================================================================ > > > > Here is some logic for the consensus at 00:00UTC: > > > > if majority of votes have disabled the SR flag: > > then don't write anything SR-related to consensus > > exit > > > > If the majority of votes contain the previous SRV value: > > then calculate SRV as detailed in section [SRCALC] > > else: > > then calculate SRV as in [SRCALC] but with previous_SRV > set to 0 > > > > And here is some logic for all the other consensuses (to figure out when > > dirauths should perform the disaster procedure): > > > > if majority of votes have disabled the SR flag: > > then don't write anything SR-related to consensus > > exit > > > > if we know the current SRV: > > then write it on the consensus > > exit > > > > if the majority of votes have the current SRV status as "none" _AND_ > > those votes also contain the previous SRV value: > > then do the disaster SRV procedure > > else: > > then don't write anything SR-related to consensus > > > > > ================================================================================ > > > > This _might_ work for fixing a good bunch of edge cases. But is it far > too complex? > > > > Should we just assume that these things will never happen on the real > network > > and avoid baking additional complexity? What do you think? :/ > > > > > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >

1 0

DoS resistance for Next-Generation Onion Services
by teor 20 Nov '15

20 Nov '15

Hi all, I think we can make next-generation onion (hidden) services (proposal #224) more resilient against certain kinds of DoS / client discovery attacks, by using a different blinded public key for each HSDir. Attack Summary: Once a malicious HSDir receives a descriptor, it can locate other HSDirs with that descriptor's blinded public key. It doesn't need to know the onion service address or decrypt the descriptor. Each descriptor contains the blinded public key: > 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. (All quotes are from https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… <https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t…> ) This allows an attacker to target onion services for DoS, as long as they don't care which onion service they're targeting. The effects of this attack could be: * if the malicious HSDir also stops serving the descriptor, it denies service to some onion service, * if the malicious HSDir continues to serve the descriptor, it becomes the only source of descriptors for some onion service. I think this enables traffic confirmation attacks on some onion service or its clients (by bringing the sole descriptor source up and down). Client descriptor downloads could also be subject to traffic fingerprinting or slow (byte-at-a-time) delivery. Attack Details: Let's assume an attacker who: * doesn't know any onion service addresses * runs a malicious HSDir that collects blinded public keys * can check other HSDirs for descriptors based on blinded public keys * wants to DoS some onion services, but doesn't care which ones This attacker then: 1. chooses an arbitrary blinded public key from their HSDir's collection 2. calculates possible HSDirs for the blinded public key 3. checks each of the possible HSDirs to see if they actually have a descriptor with that blinded public key 4. runs a DoS on each HSDir with that blinded public key (this is the resource-intensive step) A refinement of the attack is to: A. find the HSDirs for each blinded public key uploaded to the malicious HSDir (steps 1-3) B. find the blinded public keys with the most vulnerable HSDirs (perhaps using the maximum consensus weight among all 5) C. DoS the blinded public keys with the most vulnerable HSDirs (step 4) I think this is a plausible attack that could be run repeatedly until the attacker happens to hit a high-value onion service, or a high enough number of onion services. The targeted onion services would change blinded keys and HSDirs with the next shared random period, but they'd be down for up to 24 hours. Mitigation Summary: If each onion service uploads a descriptor with a different blinded public key to each HSDir, a malicious HSDir is unable to locate other HSDirs serving the same onion service. Even with this change, an attacker who knows an onion service's address can still find all its HSDirs. They can set up a malicious HSDir and wait unit it happens to get chosen as the HSDir for that service. But this targeted attack requires more resources and time than the unknown target attack I describe above. The unknown target attack can also consider hundreds of blinded public keys, and target the ones with the weakest HSDirs. The targeted attack is unlikely to host a particular descriptor on a malicious HSDir, and also simultaneously find that all the other HSDirs for that descriptor are vulnerable to a DoS. Alternative Mitigations: The current keyblinding nonce is based on the period number and start time. This allows the blinded keys to be generated in advance. But the drawback is that the blinded key is the same for each HSDir. > There is a master keypair (sk, pk). Given the keypair and a nonce n, there is a derivation function that gives a new blinded keypair (sk_n, pk_n). This keypair can be used for signing. Given only the public key and the nonce, there is a function that gives pk_n. > … > > We propose the following scheme for key blinding, based on Ed25519. > > (This is an ECC group, so remember that scalar multiplication is the > trapdoor function, and it's defined in terms of iterated point > addition. See the Ed25519 paper [Reference ED25519-REFS] for a fairly > clear writeup.) > > Let the basepoint be written as B. Assume B has prime order l, so > lB=0. Let a master keypair be written as (a,A), where a is the private > key and A is the public key (A=aB). > > To derive the key for a nonce N and an optional secret s, compute the > blinding factor h as H(A | s, B, N), and let: > > private key for the period: a' = h a > public key for the period: A' = h A = (ha)B > > Generating a signature of M: given a deterministic random-looking r (see EdDSA paper), take R=rB, S=r+hash(R,A',M)ah mod l. Send signature (R,S) and public key A'. > > Verifying the signature: Check whether SB = R+hash(R,A',M)A'. > > (If the signature is valid, > SB = (r + hash(R,A',M)ah)B > = rB + (hash(R,A',M)ah)B > = R + hash(R,A',M)A' ) > … > (To use this with Tor, set N = INT_8(period-number) | INT_8(Start of period in seconds since epoch).) Mitigation #1: Mitigation #1 generates a blinded key for every replica. (This means the attacker can only target a single replica of the descriptor, which they can likely do anyway, because the "spread_store" HSDirs are in order on the hash ring.) But it looks like this can't be done in advance, because the number of replicas is a consensus parameter. > 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. > hsdir_spread_fetch = an integer in range [1,128] with default value 3. > hsdir_spread_store = an integer in range [1,128] with default value 3. > hsdir_spread_accept = an integer in range [1,128] with default value 8 But we can instead generate a blinded key for every replica mod default_hsdir_n_replicas. Then, if the number of replicas in the consensus increases, the attack can only target 1/default_hsdir_n_replicas of the replicas. It simply doesn't know where the other replicas are, because they have different blinded keys. The spec change for Mitigation #1 would look like: > (To use this with Tor, create a key, blinded_public_key(advance_replicanum) for each N = INT_8(period-number) | INT_8(Start of period in seconds since epoch) | INT_8(advance_replicanum), where advance_replicanum takes every value from 1 to default_hsdir_n_replicas. Each key is used for the replicas where replicanum mod default_hsdir_n_replicas is equal to advance_replicanum.) The blinded key is then used by both the service and clients to determine the descriptor's hashring index: > 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 > for replicanum in 1...hsdir_n_replicas: > hs_index(replicanum) = H("store-at-idx" | > blinded_public_key(replicanum mod default_hsdir_n_replicas) | > INT_8(replicanum) | > INT_8(periodnum) ) For Mitigation #1, including advance_replicanum in the keyblinding does NOT remove the need for replicanum in the hs_index(replicanum) hash. (advance_replicanum could be lower than replicanum if the hsdir_n_replicas consensus parameter is increased from the default.) There's also a slight clarification to the spread upload wording: > Finally, for replicanum in 1...hsdir_n_replicas, the hidden service host uploads descriptors for the corresponding replica's blinded signing key to the first hsdir_spread_store nodes whose indices immediately follow hs_index(replicanum). In summary, by creating a blinded public key for each replica, Mitigation #1 restricts the attack described to a single descriptor replica per malicious HSDir. This significantly increases the resources or knowledge required for the attack. Mitigation #2: Mitigation #2 generates a blinded key for every spread. (This means the attacker can only target a single spread for the descriptor.) Spread is specified like this in the existing proposal: > 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). A similar process applies for advance generation of blinded public keys: > (To use this with Tor, create a key blinded_public_key(advance_spreadnum) for each N = INT_8(period-number) | INT_8(Start of period in seconds since epoch) | INT_8(advance_spreadnum), where advance_spreadnum takes every value from 1 to default_hsdir_spread_store. Each key is used for the spreads where spreadnum mod default_hsdir_spread_store is equal to advance_spreadnum.) Mitigation #2 changes the way the spread indexes are positioned on the hashring. Because the blinded key for each advance_spreadnum is different, the spreads are distributed around the hashring, rather than appearing on it sequentially. To maintain this distribution if the consensus value of hsdir_spread_store is increased, we have two options: * spreadnum can be included in the descriptor index hash (Mitigation #2A), or * the spread position need only be incremented once for each advance_spreadnum spreads (Mitigation #2B). Mitigation #2A: spreadnum can be included in the descriptor index hash: > 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 > for replicanum in 1...hsdir_n_replicas: > for spreadnum in 1...hsdir_spread_store: > hs_index(replicanum, spreadnum) = H("store-at-idx" | > blinded_public_key(spreadnum mod default_hsdir_spread_store) | > INT_8(replicanum) | > INT_8(spreadnum) | > INT_8(periodnum) ) There's also a slight clarification to the spread upload wording: > Finally, for replicanum in 1...hsdir_n_replicas, the hidden service host uploads descriptors for the corresponding spread's blinded signing key to the first node whose index immediately follows hs_index(replicanum, spreadnum). This uploads to hsdir_spread_store nodes per replica. Mitigation #2B: The spread position need only be incremented once for each advance_spreadnum spreads: > Finally, for replicanum in 1...hsdir_n_replicas, the hidden service host uploads descriptors to hsdir_spread_store nodes per replica as follows: > the descriptor for the corresponding spreadnum's blinded signing key is uploaded to the first node whose index immediately follows hs_index(replicanum, spreadnum). If any spreads would upload to the same node, they instead upload to the second and subsequent nodes whose indices immediately follows the hs_index. But spreadnum is NOT included in the descriptor index hash: > 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 > for replicanum in 1...hsdir_n_replicas: > hs_index(replicanum, spreadnum) = H("store-at-idx" | > blinded_public_key(spreadnum mod default_hsdir_spread_store) | > INT_8(replicanum) | > INT_8(periodnum) ) In summary, by creating a blinded public key for each replica, Mitigation #2 (both variants) restricts the attack described to a single descriptor spread per malicious HSDir. This significantly increases the resources or knowledge required for the attack. Mitigation #3: Alternately, we could double blind each public key: once when it is generated from the master key in advance, and again just before it is uploaded to the HSDir. This double-blinding should use two nonces, P and Q: * P is the advance-blinding nonce based on the period * Q is the post-blinding nonce based on the replica and/or spread (I considered and rejected a design where Q is based on the fingerprint of the HSDir. This would lead to blinding with an externally-supplied fingerprint, potentially chosen by an attacker to reveal information on blinding.) The blinding would look something like this, where H(Q, H(P, …)) replaces H(N, …): > There is a master keypair (sk, pk). Given the keypair and a nonce n, there is a derivation function that gives a new blinded keypair (sk_n, pk_n). This keypair can be used for signing. Given only the public key and the nonce, there is a function that gives pk_n. > … > > We propose the following scheme for key blinding, based on Ed25519. > > (This is an ECC group, so remember that scalar multiplication is the trapdoor function, and it's defined in terms of iterated point addition. See the Ed25519 paper [Reference ED25519-REFS] for a fairly clear writeup.) > > Let the basepoint be written as B. Assume B has prime order l, so lB=0. Let a master keypair be written as (a,A), where a is the private key and A is the public key (A=aB). To derive the key for a advance-blinding nonce P, an optional secret s, and a post-blinding nonce Q: > compute the advance-blinding factor h as H(A | s, B, P), and let: > > advance-blinded private key for the period: a' = h a > advance-blinded public key for the period: A' = h A = (ha)B > > compute the post-blinding factor j as H(A' | 0, B, Q), and let: > > post-blinded private key for the period: a'' = j a' = j (ha) > post-blinded public key for the period: A'' = j A' = j ((ha)B) > > Generating a signature of M: given a deterministic random-looking r (see EdDSA paper), take R=rB, S=r+hash(R,A'',M)ahj mod l. Send signature (R,S) and public key A''. > > Verifying the signature: Check whether SB = R+hash(R,A'',M)A''. > > (If the signature is valid, > SB = (r + hash(R,A'',M)ahj)B > = rB + (hash(R,A'',M)ahj)B > = R + hash(R,A'',M)A'' ) > ... > (To use this with Tor, set P = INT_8(period-number) | INT_8(Start of period in seconds since epoch) and Q = INT_8(replicanum) and/or INT_8(spreadnum). Other Considerations: Combining Mitigations: Mitigations #1 and #2 (either variant) can be combined, but this means generating 6 blinded keys per period, rather than 1. I don't think the extra benefit gained from implementing both outweighs the complexity involved. Issue with Per-Spread Keys: One drawback of Mitigations #2 and #3 (different blinding keys for each spread) is that the client may need to request multiple blinded keys from each HSDir due to relays dropping out of the hash ring. For example: 1. An onion service uploads descriptors with keys A, B, C to spread servers a, b, c respectively 2. Spread server a goes down 3. the client wants the descriptor for the onion service, and tries spread servers b, c, d The client doesn't know how many servers have gone down. Therefore, it will need to ask for A, B, C from the first server (actually b, which has B); B, C from the second server (actually c, which has C); and C from the third server (actually d, which has nothing). I don't like the extra load involved in this, and I wonder about the potential for information leaks to either the HSDir, or an observer of the client's connection. (For example, each of the traffic patterns above is distinct, so an observer of the client could tell which spread number it used for the descriptor.) Security Proofs: The modified security proof in Mitigation #3 would need to check out for me to be comfortable with this option. Conclusion: Can we consider Mitigation #1: creating a different blinded public key for each replica? This would double the number of keys we generate in advance, one for each replica. Alternately, we could use Mitigation #3: double-blinding each key with the period in advance, then the replica number just before upload. But we'd need to check the modified security proof carefully. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

3 4

possible to run --keygen non-interactively?
by nusenu 19 Nov '15

19 Nov '15

Hi, is there a way to use tor --keygen non-interactively? background: I might want to integrate offline master key functionality into ansible-relayor [1]. The basic idea is to generate the master keys on the ansible client and push only the required signing keys to the relays (master keys never touch the relay). Since every step should be automated, master keys will not be passphrase protected. I consider unprotected (no passphrase) offline master keys still a lot better than online master keys, but currently I don't know how to generate master keys without passphrase in an non-interactive way (--keygen asks for the passphrase when generating a new key). If that is not possible (out of the box) yet, would you consider a feature request, lets call it '--nopass' that can be used with --keygen to generate new keys without passphrase? (a more general approach would probably be to have --passphrase <passprase> but doing so would potentially write your passphrase to your shell history file). thanks! [1] https://github.com/nusenu/ansible-relayor

4 13

Just releasted : haskell-tor
by Erik de Castro Lopo 19 Nov '15

19 Nov '15

Hi all, Galois Inc has just released an implementation of the Tor protocol implemented in the Haskell programming langauge: https://github.com/GaloisInc/haskell-tor The Readme states: This is an early implementation of Tor that has not been peer-reviewed. Those with a true, deep need for anonymity should strongly consider using the mainline Tor client until and unless this version receives appropriate extensions, testing, and review. I'm not (yet) associated with this project but thought it should be mentioned here. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

8 9

prop224: "revision-counter" field leaks service/intro point stability
by Tim Wilson-Brown - teor 18 Nov '15

18 Nov '15

Hi all, The hidden service descriptor's "revision-counter" field is incremented every time the descriptor is updated. I wonder what the distribution of these versions will be: * a hidden service with a value of 0 (or 1) has just started up (or just rolled over to a new period) * an unstable hidden service might have an unusually high count * if enough introduction points go down or are DoSed, the hidden service will find new ones, and increment the count Should we randomise the start value and increment? How can we do this in a way that doesn't lead to exhaustion of the revision-counter? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

1 0

Alternate Single Onion Service Designs
by teor 17 Nov '15

17 Nov '15

Hi all, Do we need both single onion services (Proposal 252) and rendezvous single onion services? We want to enable secure usage by default, and avoid splitting anonymity sets. But we also want to support real-world use cases, because anonymous protocols are safer if more people use them. There are currently two different proposed single onion service designs: * Single Onion Services (SOS - Proposal 252): require an ORPort, no introduction/rendezvous, one-hop extend * Rendezvous Single Onion Services (RSOS - No Proposal Number): introduction/rendezvous with one-hop paths I see at least the following scenarios for using these alternate single onion service designs: 0. an onion service operator who wants to minimise latency and maximise bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous protocol) 1. an onion service operator runs a SOS for new clients, and an RSOS for old clients (a RSOS is compatible with current clients, a SOS Is not) 2. an onion service operator who can’t expose an ORPort runs a RSOS for all clients (there are enclave and NAT configurations where external ports are an issue) 3. an onion service operator who wants to use Proposal 255 for load-balancing runs a RSOS, and splits their introduction and rendezvous instances by passing the introduction over the control port (proposal 255 relies on the rendezvous protocol to handoff the rendezvous point connection to another Tor instance) 4. an onion service wants low latency and better bandwidth, and doesn't want to wait until the SOS feature is developed and deployed (SOS is a larger feature, and it needs client changes). They'll switch to SOS when it's well supported by installed versions of Tor Browser. Given these use cases, I think we could implement both flavours of single onion service. But this splits the onion service anonymity set at least 3 ways (and maybe also by some other onion service features). I'm not sure how much of an impact this will have - it does depend on our threat model for each flavour of onion service. If we wanted to generate more onion service cover traffic, we could move various automated Tor Browser actions (such as update checks and update downloads) to appropriate flavours of onion service. This would shift load away from exits, and also have address authentication benefits. (Tor Browser wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.) The other mitigations I'm aware of are cover traffic and lookalike protocol interactions, but these require significant research and design work. We're working on implementing rendezvous single onion services in #17178. I think they're pretty close: we need to do some more testing, and handle some edge cases. RSOS servers work with existing clients, including current Tor Browser releases. Single onion services (Proposal 252) is a larger feature, so it's a bit further away. SOS are incompatible with current clients, so supporting code will need to be deployed in Tor clients (such as Tor Browser) as well as on the onion service itself. After the feature is ready, there will be some lead time before SOS are usable with the majority of deployed Tor clients. What do you think? Are onion services big enough to safely have multiple flavours? Could they get that big if we support enough functionality? Or are we better to implement secure, one-size-fits-all defaults, and ask users and operators to sacrifice some performance? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

5 4

Re: [tor-dev] Patched versions of the FreeBSD ports "security/tor" and "security/tor-devel"
by Vinícius Zavam 17 Nov '15

17 Nov '15

2015-11-05 12:08 GMT-03:00, Vinícius Zavam <egypcio(a)googlemail.com>: > Ahoj! > > If you are using FreeBSD to run a Tor Relay, it would be sweet to get more > feedbacks about the patches I reported to the FreeBSD Bugzilla, so they can > be commited/improved. > > Please check https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203014 > > Thanks. > > > -- > Vinícius Zavam I just changed a bit the patches; please check if everything still works for you and ping me back if needed. Previous tests went well for i386 and amd64. Because there are no TOR_LDFLAGS_tcmalloc or TOR_TCMALLOC_LIBS available, I ran into changes to the main LDFLAGS (that's why tor-dev@ is reading this answer in CC now). K.R., -- Vinícius Zavam keybase.io/egypcio/key.asc

1 0

Weird interactions between TBB and Hidden Services upon HS kill/restart
by Alec Muffett 17 Nov '15

17 Nov '15

For the sake of documentation I thought I would share this here: I have a (test) Hidden Service, running vanilla tor 0.2.6.10 The HS torrc is: ControlPort 9051 DataDirectory /home/alecm/tor-dev/data SafeLogging 0 Log info stdout HiddenServiceDir /home/alecm/tor-dev/hs HiddenServicePort 80 localhost:80 SocksPort 0 RendPostPeriod 0 seconds I also have an OSX version of Tor Browser Bundle - version 5.5a4 (tor 0.2.7.4-rc) I amended /Applications/TorBrowser.app/TorBrowser/Data/Tor/torrc-defaults to include: SafeLogging 0 Log info file /tmp/tor-log.txt ...so that I can see what is going on. I launched the Hidden Service (HS) I accessed the HS from TBB - Successful Page Load! The TBB logfile contains the following sequence, pertinent to the first connection attempt, with manual edits: ---- start ---- >Nov 12 17:41:13.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_1', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_1 >Nov 12 17:45:02.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'MY_ONION' >Nov 12 17:45:02.000 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor MY_ONION. Fetching. >Nov 12 17:45:02.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_1', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_2 >Nov 12 17:45:03.000 [info] circuit_get_open_circ_or_launch(): Chose INTROPOINT_1 as intro point for 'MY_ONION'. >Nov 12 17:45:03.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. >Nov 12 17:45:03.000 [info] link_apconn_to_circ(): Looks like completed circuit to hidden service does allow optimistic data for connection to MY_ONION ---- end ---- This looks good. I killed the HS - the means of killing appears immaterial, SIGINT, SIGTERM, same thing always happens. I waited about 60 seconds. I re-launched the HS. I accessed the HS from (still running, not restarted) TBB using Shift-Reload to force a page-refresh - Failure! The TBB logfile contains the following sequence, pertinent to the second connection attempt: ---- start ---- >Nov 12 17:46:27.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'MY_ONION' >Nov 12 17:46:27.000 [info] circuit_get_open_circ_or_launch(): Chose INTROPOINT_3 as intro point for 'MY_ONION'. >Nov 12 17:46:27.000 [info] rend_client_introduction_acked(): Got nack for MY_ONION from INTROPOINT_3... >Nov 12 17:46:27.000 [info] rend_client_report_intro_point_failure(): 2 options left for "MY_ONION". >Nov 12 17:46:28.000 [info] rend_client_introduction_acked(): Got nack for MY_ONION from INTROPOINT_2... >Nov 12 17:46:28.000 [info] rend_client_report_intro_point_failure(): 1 options left for "MY_ONION". >Nov 12 17:46:28.000 [info] rend_client_introduction_acked(): Got nack for MY_ONION from INTROPOINT_1... >Nov 12 17:46:28.000 [info] rend_client_report_intro_point_failure(): No more intro points remain for "MY_ONION". Re-fetching descriptor. Okay, this makes sense, all the IPs are invalid because I killed the daemon, none of them are reachable... >Nov 12 17:46:28.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_2', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_3 Wait, is it relevant that it has picked descriptor ID 'MY_DESC_2' here, not the prior 'MY_DESC_1'? The latter crops-up further down. Perhaps this is a DHT thing? This is the only reference to MY_DESC_2... >Nov 12 17:46:29.000 [info] rend_cache_store_v2_desc_as_client(): Service descriptor with service ID MY_ONION, every intro points are unusable. Discarding it. That sounds okay, garbage collection of dead data is good... >Nov 12 17:46:29.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_1', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_4 Wait, now we are re-fetching MY_DESC_1 again?... >Nov 12 17:46:30.000 [info] rend_cache_store_v2_desc_as_client(): We already have this service descriptor MY_ONION. And it thinks we already have it? But didn't we just discard it?... >Nov 12 17:46:30.000 [notice] Closing stream for 'MY_ONION.onion': hidden service is unavailable (try again later). And there is the connection failure, and it looks like it didn't find a new descriptor, or rejected a new one if it found it - assuming it found it at all... >Nov 12 17:46:30.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. >Nov 12 17:46:30.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. Try "reload" again, just for good luck: >Nov 12 17:46:40.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'MY_ONION' >Nov 12 17:46:40.000 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor MY_ONION. Fetching. >Nov 12 17:46:40.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_1', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_2 >Nov 12 17:46:41.000 [info] rend_cache_store_v2_desc_as_client(): We already have this service descriptor MY_ONION. >Nov 12 17:46:41.000 [notice] Closing stream for 'MY_ONION.onion': hidden service is unavailable (try again later). >Nov 12 17:46:41.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. >Nov 12 17:46:41.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. ---- end ---- So, it looks like one of three things: - perhaps TBB is not actually discarding the dead descriptor - or perhaps TBB is re-fetching the old descriptor and failing connections again - or perhaps TBB is fetching the new descriptor and rejecting it in favour of the old one, which it hasn't really discarded. In any case: killing TBB and restarting it seems to fix this situation, so it's something on the client side at fault? - alec

3 2

Percentage of Windows users
by Rob van der Hoeven 17 Nov '15

17 Nov '15

Hi folks, I am currently working on an isolating Tor proxy for Linux users. This proxy could be ported to Windows but this would be a lot of work. So I wonder if it's worth the trouble. What percentage of users are downloading the Windows version of Tor? Regards, Rob. https://hoevenstein.nl

1 0

Proposal: Link Cryptographic Agility
by Yawning Angel 16 Nov '15

16 Nov '15

Hello, There's been talk of moving to a wide block construct for cell crypto (#5460), and for adding PQ Forward Secrecy to traffic (#17272). To facilitate this, there needs to be a method for negotiating which primitives a given relay supports. To that end, here's the begining of a proposal (tentatively #260) that adds a `CIPHERSUITES` cell to the version negotiation process which allows relays to advertise the link cryptography primitives that they are willing to accept. TODOs/TBD: * Should the new cell be variable length? Our development cycle and how often we switch handshakes/link crypto tells me "No", the existing "VERSIONS" cell format tells me "Yes". * We need to revise prop. 249 to add a cell crypto method specifier to CREATE2V/EXTEND. * Proposal 249 does not cover changing RELAY_EARLY behavior, which will potentially cause problems (Eg: Ring-LWE + ntor will require between 5 to 9 fragments depending on the exact primitives). * The actual hybrid construct is deliberately left unspecified. * With runtime negotiation of primitives on a per-circuit basis, we introduce the possibility of downgrade attacks. We do calculate the SHA256 digest of VERSIONS/CERTS/AUTH_CHALLENGE cells (which will become VERSIONS/CIPHERSUITES/CERTS/AUTH_CHALLENGE), so we could do something like: auth_input = verify | ID | B | Y | X | SLOG | PROTOID | "Server" Where SLOG is the digest without too much difficulty... The alternative to all of this would be something like including handshake methods/supported link crypto in the descriptors, but that seems silly. Regards, -- Yawning Angel

2 2

W3C Payment Groups
by Jeff Burdges 16 Nov '15

16 Nov '15

I've been talked into formally participating in the W3C Payment Interest/Working Group as part of working on GNU Taler, well my employer INRIA is a member. Drop me a line if there is anything I can do/say/watch to help keep that potential standard tor friendly. Best, Jeff p.s. There are related groups on privacy and credentials that might be of more interest to Tor Browser which I'm not involved in, btw. p.s.2 Just fyi, Taler is a transaction system based on RSA blind singing. We haven't finished the demo for Taler yet, probably by 32c3 though. Feel free to look at these if you want to know more : http://taler.net http://grothoff.org/christian/taler-draft.pdf

1 0

Upcoming Onionoo version 3.0 will support searches by space-separated fingerprint
by Karsten Loesing 15 Nov '15

15 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Onionoo client developers, the upcoming Onionoo version 3.0 will support searches by space-separated fingerprint. To give you an example, the following two searches will both return moria1 as result, using the new version 3.0: "9695DFC35FFEB861329B9F1AB04C46397020CE31" "9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31" (In the current version 2.6 that second search wouldn't return anything, because it would look for a fingerprint starting with 9695 *and* starting with DFC3 *and* starting with...) You can try out the new behavior by using the Onionoo/Atlas/Globe mirrors run on thecthulhu.com: https://atlas.thecthulhu.com/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.thecthulhu.com/#search/9695%20DFC3%205FFE%20B861%20329B%209F1… The corresponding service instances run on torproject.org have not been updated yet, so that only the first search will return a result: https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.torproject.org/#search/9695%20DFC3%205FFE%20B861%20329B%209F1… (not expected to return anything until November 15, 2015!) The torproject.org instances will be updated in a month from now to give you the chance to update your clients. After all, your client might rely on the current behavior of the search parameter. (That's why this is a major protocol change, not because it's a major step towards world domination.) Please tell me if the new behavior doesn't work for you and you need me to make any changes/extensions. More details on the ticket: https://trac.torproject.org/projects/tor/ticket/17115 All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWHjKCAAoJEJD5dJfVqbCr+o0H/3Q37+YVS1d2enBa+Z/aEZkx b21/vvIUHMjBWCh41MAEJrQNzczfrjhusjkSpY1amypE6R81mST8mizFvtKK5zVh P4QlB9L40tKRrASwK1Tz+qSRmx7A6fm4YSieAALuvcD8LeNfwzNlKRqNSoipwDWl 7NjITYhOeRmExbUjfqDbfs5woodsabHaXIrAOUeQvtljc36bj1OGtq15UroaqLdv MKjn7GgP3qR5NrPAZKYlAVW7Qxg6KIsPC9DXam7xh4CIyWja01WsKrUab80fUT0K N7wvq4oV7PZ84BomVG/Fte2Vk5hz2e53deshsxwjVB2BonHKpq+hzHsLX+pkCSU= =0cnD -----END PGP SIGNATURE-----

2 4

Re: [tor-dev] . tor-roster's geo diversity badge and self-ref relays
by Sean Saito 15 Nov '15

15 Nov '15

Hi nusenu, >Do you consider in-family diversity so important - even though all of >them are run by a single entity anyway? > How about having a badge for tor network wide diversity? > I'd consider the tor network's overall diversity far more important than > in-family diversity because clients won't use more than one relay of a > given family anyway. Entire-network diversity is obviously more important than within-operator diversity---no doubt about that. We are doing within-operator diversity simply because the it's easier to measure/understand. I agree that measuring a family's relay diversity with respect to the entire Tor network is would be supplementary, maybe even strictly better. I am already logging relevant data, namely the number of relays per country and total CW per country (as you suggested previously). The former stastic could be used for badges like "First relay in country X." >More than 4/5 of the family's CW is located in countries with a cw lower >than 2%* (currently means non-top 7 country) and ASes lower than 1.5%* >(currently means non-top 8 AS)? > >That implies some degree of in-family diversity since a big family would >have to spread across multiple countries/ASes Although there have been some interesting discussions about which ASes to prioritize in putting new relays, an actual concrete numerical measure is thus far an unsolved problem. Virgil and I have talked about using a new tool (http://labs.apnic.net/vizas/) to observe which ASes have more interconnections and award bonus points to new relays on them. When these measures become better established definitely in favor of making badges for them (perhaps even replacing the within-operator diversity badges?). >"No Self-Referencing Relays" >I'm not sure what exactly you mean by that but I assume it is a MyFamily >config where a relay includes his own fingerprint. Why does that hurt? >The unnecessary descriptor space/bw? This is something Virgil wanted because he thought self-connections were ugly. If the penalizing of self-connections is found to be uglier than the self-connections themselves, we're both fine with removing it. Hope this answers your questions. Thanks for the feedback! Best, Sean

7 6

Starting on an Easy Bug #16846
by Abhiram Chintangal 15 Nov '15

15 Nov '15

Hello, I have been planning on learning more about tors code base for sometime now. Luckily, I might have some freetime for the next two weeks and I am hoping to put it to good use. After digging through tickets labelled as "easy" on trac, #16846 seemed like a decent cadidate for to me. There was some discussion on trac about the security impact of adding the feature, but that was three months ago. I was wondering if anyone could shed more light on it. Thanks! -- Abhiram Chintangal

2 1

NO 1-1-1 task exhange meeting on Thursday, Nov 12
by Karsten Loesing 11 Nov '15

11 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, I decided to stop the experiment of organizing 1-1-1 task exchange meetings for everyone in Tor, because there was too little interest in having these meetings. If you have no idea what I'm talking about, here's the wiki page: https://trac.torproject.org/projects/tor/wiki/doc/1-1-1-task-exchange We may resume having these meetings as part of the metrics team or do another experiment that involves everyone in Tor at a later time. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWQ0aFAAoJEJD5dJfVqbCrIToIAKYXdZ/ytZHHsaVUSkraE7TX g0AOwLEo1IfyS1ANixXXsmTedevoweCfzxYyEdTrfDjfca17Ur4WmcAp4ROPxmAk jD4GqAq2ACFPai9fvmcFdPDoJsC3yP8kj1Zq05DT94EwlxBwctNzWF5TPCr1tteJ H2esPObS1rA2Cu00Ta4N/2qqc5HD4BrOJVOu2FvW2ZrGGJO5WDf/jSxxoJiLHmqu lqBqbSbUEEWsFe9iTjxM+Tke/73dbInUrJqZt6MbmjpOS8W4Ibyma51i6v2C9OmN 42ixTg/31Q9MX5w8Z6+Ma8BlD9K1hJ8hF3xBdt5mYWtT2araNIqy5dAv2L19tNQ= =QzaF -----END PGP SIGNATURE-----

1 0

Changing Rendezvous Single Onion Service at Runtime
by teor 10 Nov '15

10 Nov '15

Hi all, Is there any reason an onion service would want to temporarily switch from 1-hop to 3-hop paths? Is it ok if we force operators to restart the tor instance when onion service path lengths change? The original proposal for rendezvous single onion services (RSOS) was silent on whether path lengths could change at runtime. (I honestly didn't think anyone would do that!) The existing proposal doesn't allow operators to run hidden services (HS) and RSOS on the same Tor instance at the same time. I'd like to strengthen this security feature, and ensure operators can't run HS and RSOS on the same instance sequentially. This would also mean that operators can't switch an onion service's flavour from HS to RSOS or vice versa at runtime. In detail, this means that after an onion service is launched, a Tor instance can only run all RSOS, or all HS, until Tor is restarted. This design change protects operators from inadvertent network address disclosure from running onion services with 1 and 3 hop paths on the same Tor instance. But it also supports an ephemeral RSOS use-case, where the operator launches Tor, sets (or unsets) RendezvousSingleOnionServiceNonAnonymousServer, then launches an onion service. To implement this change, Tor needs to check: if RendezvousSingleOnionServiceNonAnonymousServer is changed, and there are any onion services active (excluding deleted/inactive services, if this is a feature of (ephemeral) services), then reject the change and warn the user. (Tell them to restart if they really want to change it.) For what it's worth, the implementation is also much simpler if we force a restart when this parameter changes. If we start enforcing the recommended options, like disabling entry guards and pathbias, a restart will be even more important. I've been talking with asn about this on Trac ticket #17178. Please feel free to comment by email or on the ticket. I'll modify the proposal after I'm sure this covers all use cases. In summary: Is there any rendezvous single onion service use case that wouldn't be possible with this new restriction? I want to check we aren't breaking any neat onion service uses, if we force Tor to restart when changing path lengths. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

3 2

Proposal: Adding x-namespace to relay descriptor for key:value pairs
by Virgil Griffith 09 Nov '15

09 Nov '15

Filename: ExtraRelayDescriptorFields.txt Title: Adding x-namespace to relay descriptor for key:value pairs Author: Virgil Griffith Created: 2015-09-30 Status: Open 1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace to the router descriptor [1]. The canonical applications for this are adding a bitcoin donation address and networking of tor2web nodes. 2. Proposal Allow optional key-value lines in the relay's torrc file. These lines will be mirrored in the relay's descriptor which is then published in the directory consensus. The following would be added to section 2.1.2 of the dir-spec (Extra-info document format): ======================================================== "X-" CustomKey SP CustomValue NL CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_" CustomKey = 1*32 CustomKeyChar CustomValueChar = atext / specials CustomValue = 1*1024 CustomValueChar Custom fields can appear multiple times, for example... X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar If the same CustomKey appearing more than once is disallowed. Possible values for CustomValueChar as specified per RFC 2822. The sum size accounting for all such custom fields is truncated to 5 kilobytes. ======================================================== To mitigate the chance of a malformed torrc file, I additionally propose that the relay descriptor be scanned and if it does not match the specification, that it exit with error telling her torrc file is a likely culprit. -V

3 5

Update of prop#250: Random Number Generation During Tor Voting
by David Goulet 09 Nov '15

09 Nov '15

Hello Tor-Dev! We've almost completed the implementation [1] for prop#250 so we've reviewed part of the proposal to correct part of it to reflect reality (because you know a proposal is just wishful thinking until you implement it :). Attached is the new version that we've been working on. We would like feedback from the community before at least calling it "ACCEPTED" and updated in tor-spec.git [2]. Here is a small summary of the big changes and also we need feedback on something that we are not fully in agreement. First, period have been changed from 12:00 -> 12:00 (24 hour) to 00:00 -> 24:00 so the protocol run is not over two days. Seemed more logical and less confusing :). Second, we've removed the need of having majority for a commit to be considered for the shared random computation. Yes this sounds intense!! so it needs your attention. We think that majority concept was only protecting us against was a partition attack during commit phase but it turns out that having a conflict detection mechanism (see COMMITCONFLICT section) already protect us of most of them during the commit phase except maybe one that is described in Section 5.3.1. With this proposal change, an authority only keeps commits that are authoritative that is a commit coming directly from an authority. We've added section 5.3 on Partition Attack. Choosing commit by majority was protecting us against a partition attack in the commit phase but not all so with or without it, we still need an external monitoring party that makes sure attack are not ongoing (or bugs). DocTor is the obvious candidate so we'll work on a partition attacks detection since all of them are noisy and detectable. A sub-section (4.1.7) has also been added which address the need of a shared random key that signs the commit values so they can be verified by other authorities [3]. Finally, we would like your opinion also on if we should keep the conflict mechanism or not?. Since those partition attacks are basically dumb, do not achive much result for an attacker and it's at a high cost of comprimising a directory authority, should we keep them? Keep in mind that it adds a layer of complexity in the code especially with shared random keys which rotates every 30 days and are only available in the vote of an authority. It gets difficult to validate a conflict of an authority if we haven't seen yet a vote from that authority. There are ways to fix that code wise but is this worth it considering that every partition attack will be detected anyway by DocTor? One argument to keep it is resilience of the protocol. With conflict line, if one dirauth does stupid things, it will get ignored for the rest of the protocol run so we can still compute a fresh random value in the end. Again, does it worth it? Don't hesitate to ask about sections that are not clear or could be incorrect or you do not understand fully. Also, a ACK is a valid reply :). Thanks to all! David [1] https://trac.torproject.org/projects/tor/ticket/16943 [2] https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-… [3] https://trac.torproject.org/projects/tor/ticket/17349

5 9

Hidden service patch workshop on #tor-dev IRC channel
by George Kadianakis 09 Nov '15

09 Nov '15

Dear tor-dev, Everyone who is working on any kind of improvement to hidden services or related applications and would like to give or receive assistance (code reviews, advice, etc.) is welcome on: Thursday November 12, 16:00 UTC @ #tor-dev OFTC channel This might become a regular biweekly thing, if it proves to be successful. Cheers!

2 1

Re: [tor-dev] [tor-commits] [tor-messenger-build/master] Bug 17492: Include default bridges configuration
by Roger Dingledine 08 Nov '15

08 Nov '15

On Sat, Nov 07, 2015 at 12:13:45AM +0000, boklm(a)torproject.org wrote: > commit 7a1c6fd121dd001eb999ef03ebbbed264da37026 > Author: Nicolas Vigier <boklm(a)torproject.org> > Date: Sat Nov 7 00:45:48 2015 +0100 > > Bug 17492: Include default bridges configuration > > However, we exclude meek from the bridges configuration, as it currently > doesn't work in Tor Messenger because it requires firefox. This could be a great opportunity for Yawning's recent meek variant that doesn't use an actual browser. (It won't work as well as the real meek, but maybe no actual adversaries care about the difference quite yet?) --Roger

4 3

Ideas for TorBrowser
by Michał Dziczkowski 06 Nov '15

06 Nov '15

Hello. I would like to propose following for the TorBrowser: * request folder structure change because the actual one is a big mess and it's hard to find anything without browsing each folder * add the patches with fix the bugs of not working functions (like by example: options, addons, etc.) of current version of browser (till the next version of TorBrowser get ready to download) Mcgiwer

1 0