Hello,
If anyone is planning to spin up a new VM or dedi to run a Tor relay and want it to be put instantly into good use (without wasting couple of weeks to a month for the whole "unmeasured relay/measured/guard/stable" cycle to complete) or if you are having trouble with your current relay being measured properly, in a few days I'm considering to give away several fingerprints+keys from my relays that I will be shutting down.
If you install Tor on a new machine and unpack one of these into your /var/lib/tor, it starts up something like this (see below); i.e. in a couple of hours to a full 100% utilization.
eth0 16:59 ^ t | t t rt rt rt rt | rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt -+---------------------------------------------------------------------------> | 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) 17 0 0 01 0 0 09 34135840 34964598 18 0 0 02 0 0 10 37991652 38890814 19 0 0 03 0 0 11 38710878 39749495 20 0 0 04 0 0 12 39168357 40164982 21 0 0 05 50433 1472 13 42351426 43626118 22 0 0 06 10904079 10927593 14 42826283 43928095 23 0 0 07 15691530 15839439 15 41240931 42507372 00 0 0 08 27079433 27403035 16 41941981 43139517
Drop me an E-Mail if you want one of these (probably about 2-3 available for now).
On Sat, 25 Jul 2015 23:40:10 +0500 Roman Mamedov rm@romanrm.net wrote:
If anyone is planning to spin up a new VM or dedi to run a Tor relay and want it to be put instantly into good use (without wasting couple of weeks to a month for the whole "unmeasured relay/measured/guard/stable" cycle to complete) or if you are having trouble with your current relay being measured properly, in a few days I'm considering to give away several fingerprints+keys from my relays that I will be shutting down.
What are the fingerprints so they can be rejected by the DirAuths?
Regards,
Roman Mamedov transcribed 3.6K bytes:
Hello,
If anyone is planning to spin up a new VM or dedi to run a Tor relay and want it to be put instantly into good use (without wasting couple of weeks to a month for the whole "unmeasured relay/measured/guard/stable" cycle to complete) or if you are having trouble with your current relay being measured properly, in a few days I'm considering to give away several fingerprints+keys from my relays that I will be shutting down.
If you install Tor on a new machine and unpack one of these into your /var/lib/tor, it starts up something like this (see below); i.e. in a couple of hours to a full 100% utilization.
eth0 16:59 ^ t | t t rt rt rt rt | rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt -+---------------------------------------------------------------------------> | 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) 17 0 0 01 0 0 09 34135840 34964598 18 0 0 02 0 0 10 37991652 38890814 19 0 0 03 0 0 11 38710878 39749495 20 0 0 04 0 0 12 39168357 40164982 21 0 0 05 50433 1472 13 42351426 43626118 22 0 0 06 10904079 10927593 14 42826283 43928095 23 0 0 07 15691530 15839439 15 41240931 42507372 00 0 0 08 27079433 27403035 16 41941981 43139517
Drop me an E-Mail if you want one of these (probably about 2-3 available for now).
-- With respect, Roman
Hey Roman,
I could take those backdoored^W"pre-warmed" keys and put them to good use!
With mirth,
On Sat, 25 Jul 2015 19:47:23 +0000 isis isis@torproject.org wrote:
I could take those backdoored^W"pre-warmed" keys and put them to good use!
Hello,
Mkay, I'll get in touch in a few days.
As for other repliers, I would not mind explaining my reasoning in more detail, if you have any specific questions or more articulated objections that a knee-jerk "ban it" or "lolz" reactions.
Thanks
On Sun, 26 Jul 2015 05:32:17 +0500 Roman Mamedov rm@romanrm.net wrote:
On Sat, 25 Jul 2015 19:47:23 +0000 isis isis@torproject.org wrote:
I could take those backdoored^W"pre-warmed" keys and put them to good use!
Hello,
Mkay, I'll get in touch in a few days.
As for other repliers, I would not mind explaining my reasoning in more detail, if you have any specific questions or more articulated objections that a knee-jerk "ban it" or "lolz" reactions.
What was knee-jerk about my response?
The relay identity key is sensitive cryptographic material. Sharing it means the private key is compromised and is an attempt to subvert:
* The bandwidth scanning process. The consensus weight is the relay's capacity relative to other nodes in the network which will change and should be reset if the location of the relay changes.
Yes, in an ideal world the bwauths will scan new relays faster. But that's orthogonal to the need to reset/remeasure on IP address change.
* The flag assignment process. A random person should not get the Guard or Stable flag quickly.
The only thing a compromised relay should be used for is as a middle node and never a HSDir, so the correct behavior on the DirAuth side is to never assign the Valid flag to said relays.
A fun task for someone who likes messing with consensus documents and descriptors would be to write a script to measure IP address churn for relays while the relay identity remains constant (either legitimately eg: being on a dynamic IP, person had to move the rack the relay was on, or through key compromise/derp).
I'm of the opinion that it may be worth adding code to pin relay identities to IP addresses on the DirAuth side so that consensus weight and flag assignment gets totally reset if the ORPort IP changes, but if there's too much churn already it may cause more trouble than it's worth.
Regards,
On Sun, 26 Jul 2015 01:35:10 +0000 Yawning Angel yawning@schwanenlied.me wrote:
The relay identity key is sensitive cryptographic material. Sharing it means the private key is compromised and is an attempt to subvert:
- The bandwidth scanning process. The consensus weight is the relay's capacity relative to other nodes in the network which will change and should be reset if the location of the relay changes.
Yeah perhaps I should have mentioned that people should request one if they are absolutely certain that their server is capable of handling at least 50+50 Mbit of bandwidth.
- The flag assignment process. A random person should not get the Guard or Stable flag quickly.
...and that they expect it to have a certain degree of stability. :)
Sure this is a shortcut of sorts, and it's one that you should take if you believe you can "vouch" for things like stability and b/w capacity you can provide, and want to "skip the formalities" a bit so to say, and start contributing to the maximum extent possible immediately; surely nobody likes paying for idle servers.
Either way you won't do much damage even if any of this ends up being false, as the consensus weight and the stable status will drop more rapidly than they are gathered if your node can't maintain them.
Yes, in an ideal world the bwauths will scan new relays faster.
Meanwhile in reality the outcome is often [1].
A fun task for someone who likes messing with consensus documents and descriptors would be to write a script to measure IP address churn for relays while the relay identity remains constant (either legitimately eg: being on a dynamic IP, person had to move the rack the relay was on, or through key compromise/derp).
I do this extensively on my relays, as one VPS or dedicated server expires, gets terminated or canceled for various reasons, a different one takes its place, inheriting the same identity. If I had to always wait for new relays to spin up from scratch in each case, a lot of the time I probably wouldn't even bother.
Running 20 relays in a declared family at the moment, together comprising about 1.8% of aggregate Tor bandwidth, however due to financial reasons I will have to shut down most of these over the coming weeks and months; so I see little difference if the next machine inheriting a particular identity this time will be managed and paid for by someone else and not by me. Just throwing these away seemed like a waste.
[1] https://lists.torproject.org/pipermail/tor-relays/2015-June/007203.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/25/2015 7:13 PM, Roman Mamedov wrote:
On Sun, 26 Jul 2015 01:35:10 +0000 Yawning Angel yawning@schwanenlied.me wrote:
The relay identity key is sensitive cryptographic material. Sharing it means the private key is compromised and is an attempt to subvert:
- The bandwidth scanning process. The consensus weight is the
relay's capacity relative to other nodes in the network which will change and should be reset if the location of the relay changes.
Yeah perhaps I should have mentioned that people should request one if they are absolutely certain that their server is capable of handling at least 50+50 Mbit of bandwidth.
- The flag assignment process. A random person should not get
the Guard or Stable flag quickly.
...and that they expect it to have a certain degree of stability. :)
Sure this is a shortcut of sorts, and it's one that you should take if you believe you can "vouch" for things like stability and b/w capacity you can provide, and want to "skip the formalities" a bit so to say, and start contributing to the maximum extent possible immediately; surely nobody likes paying for idle servers.
Either way you won't do much damage even if any of this ends up being false, as the consensus weight and the stable status will drop more rapidly than they are gathered if your node can't maintain them.
Yes, in an ideal world the bwauths will scan new relays faster.
Meanwhile in reality the outcome is often [1].
A fun task for someone who likes messing with consensus documents and descriptors would be to write a script to measure IP address churn for relays while the relay identity remains constant (either legitimately eg: being on a dynamic IP, person had to move the rack the relay was on, or through key compromise/derp).
I do this extensively on my relays, as one VPS or dedicated server expires, gets terminated or canceled for various reasons, a different one takes its place, inheriting the same identity. If I had to always wait for new relays to spin up from scratch in each case, a lot of the time I probably wouldn't even bother.
Running 20 relays in a declared family at the moment, together comprising about 1.8% of aggregate Tor bandwidth, however due to financial reasons I will have to shut down most of these over the coming weeks and months; so I see little difference if the next machine inheriting a particular identity this time will be managed and paid for by someone else and not by me. Just throwing these away seemed like a waste.
[1] https://lists.torproject.org/pipermail/tor-relays/2015-June/007203.htm
l
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Have a great life....bye.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Sun, 26 Jul 2015 07:13:44 +0500 Roman Mamedov rm@romanrm.net wrote:
Either way you won't do much damage even if any of this ends up being false, as the consensus weight and the stable status will drop more rapidly than they are gathered if your node can't maintain them.
Giving away the identity keys for high capacity relays that actual users are using as Guards seems irresponsible at best, and downright malicious assuming a realistic threat model for the Tor Network as a whole.
Yes, in an ideal world the bwauths will scan new relays faster.
Meanwhile in reality the outcome is often [1].
Orthogonal problem, and it's being worked on under an OTF Fellowship.
A fun task for someone who likes messing with consensus documents and descriptors would be to write a script to measure IP address churn for relays while the relay identity remains constant (either legitimately eg: being on a dynamic IP, person had to move the rack the relay was on, or through key compromise/derp).
I do this extensively on my relays, as one VPS or dedicated server expires, gets terminated or canceled for various reasons, a different one takes its place, inheriting the same identity. If I had to always wait for new relays to spin up from scratch in each case, a lot of the time I probably wouldn't even bother.
While the bwauth delay is unfortunate (which is why it's being worked on), the delay in assigning Stable/Guard and HSDir are for user safety.
I'm somewhat torn on the whole key pinning thing, because I think an individual operator moving their relay around is sort of ok (though in an ideal world the consensus weight should get reset and rapidly re-measured), but giving away the private component of a relay's identity key is putting users at risk, and is behavior that should be discouraged if not outright prohibited if possible (and key pinning would be a heavy handed way to rule out this sort of stupidity).
I personally care less about the absolute size of the Tor network, and if it's a choice between user's Guards changing ownership, and a smaller Tor network I will pick the latter every single time.
Running 20 relays in a declared family at the moment, together comprising about 1.8% of aggregate Tor bandwidth, however due to financial reasons I will have to shut down most of these over the coming weeks and months; so I see little difference if the next machine inheriting a particular identity this time will be managed and paid for by someone else and not by me. Just throwing these away seemed like a waste.
If I have to write a script to figure out the fingerprints of your relays just to keep users safe I will. I have 3 million other things I rather be doing, but keeping the user safe from the bad guys (no matter how good their intentions) is the most important thing I could be doing.
Regards,
On Sun, Jul 26, 2015 at 08:41:13AM +0000, Yawning Angel wrote:
On Sun, 26 Jul 2015 07:13:44 +0500 Roman Mamedov rm@romanrm.net wrote:
Either way you won't do much damage even if any of this ends up being false, as the consensus weight and the stable status will drop more rapidly than they are gathered if your node can't maintain them.
Giving away the identity keys for high capacity relays that actual users are using as Guards seems irresponsible at best, and downright malicious assuming a realistic threat model for the Tor Network as a whole.
I've been following this thread but haven't had time (and won't for several days at least) to formulate a thorough thoughtful response, but your statements are too absolute and without qualification.
I'm not saying that specifically the intended actions (whatever they may be) in this case are reasonable. I am saying that your responses are too broad.
Let's assume purely for simplicity that the transfer can be done in a secure fashion. Then if, for example, someone transferred keys to long-known trusted persons w/in the Tor community (say some of the dir-auths and others at similar levels of trust) in a way that (a) actually diminished the network concentration of trust among people by spreading his family to others where the result is more flat, and (b) paid attention to AS, country (by Geo-IP), etc. so that neither AS nor country changed. This should probably be fine.
(I actually don't think (b) is needed if this is a relatively rare occurrence. Given other aspects of network churn and the very limited way that Tor currently manages location awareness, that is not the low-hanging fruit.)
There are probably other scenarios where this would be an OK action. And it's not just a security/performance trade-off. Having those relays just disappear reduces the diversity and capacity of the network, which has security implications too. Here is another example wrt another factor. (If I'm going on too long here and losing you, skip the rest of this paragraph.) Someone could be maintaining several relays reasonably well but realize that their ability to securely maintain them is going to diminish slightly for some reason, still probably keeping them among the upper half of relays wrt security practice and circumstance. However, they realize that they can securely transfer authority over those relays to people who are both more trusted/reputed w/in the Tor community and in a better position to maintain their security going forward. In that case, they would be improving the security of the network by (securely) handing over the private keys than by continuing to maintain the relays themselves.
It is fine to note that this is something that could only make sense if done carefully. But claiming that the transfer of authority over private keys from on person to another must always be irresponsible diminishes the value of your primary point by overstating the argument.
aloha, Paul
On Mon, 27 Jul 2015 11:14:00 -0400 Paul Syverson paul.syverson@nrl.navy.mil wrote:
I've been following this thread but haven't had time (and won't for several days at least) to formulate a thorough thoughtful response, but your statements are too absolute and without qualification.
I used strong wording because there's a lot of thought/vetting that should go into doing something like this safely, though in hindsight, it probably was overly strong. That said....
[snip]
Let's assume purely for simplicity that the transfer can be done in a secure fashion. Then if, for example, someone transferred keys to long-known trusted persons w/in the Tor community (say some of the dir-auths and others at similar levels of trust) in a way that (a) actually diminished the network concentration of trust among people by spreading his family to others where the result is more flat, and (b) paid attention to AS, country (by Geo-IP), etc. so that neither AS nor country changed. This should probably be fine.
I think the trust component here is the biggest thing to worry about.
[snip]
There are probably other scenarios where this would be an OK action. And it's not just a security/performance trade-off. Having those relays just disappear reduces the diversity and capacity of the network, which has security implications too.
But by design:
a) The relays will move network location (unless the new operator picks the same data centers) therefore, the consensus weight should be re-measured.
(To the peanut gallery, yes know the bwauths are held together by ducttape, string, chewing gum, and occult animal sacrifices. We're currently migrating from chicken based rituals to goat based ones, and "assuming the bwauths work" is probably about as reasonable as "assume enough vetting" or "assume secure key transfer".)
If "b" from your list is done, then this can be skipped.
b) The operator has changed (the network/code itself doesn't and can't realistically know how much vetting the new operator has had), therefore, it flags should be treated as if the relay was brand new.
If there was a way to objectively quantify trust, then I can see short-circuiting the various flag assignment delays, but, that appears to be an open research problem.
Essentially, if the person running them changes, and the network location changes (possibly for the better, diversity is good after all), what's the difference between someone just spinning up new replacement high capacity relays that isn't ("if the person is 'trusted enough *waves hand*', it's sort of ok to bypass delays in letting the relays do certain things that are added for security reasons").
Here is another example wrt another factor. (If I'm going on too long here and losing you, skip the rest of this paragraph.) Someone could be maintaining several relays reasonably well but realize that their ability to securely maintain them is going to diminish slightly for some reason, still probably keeping them among the upper half of relays wrt security practice and circumstance. However, they realize that they can securely transfer authority over those relays to people who are both more trusted/reputed w/in the Tor community and in a better position to maintain their security going forward. In that case, they would be improving the security of the network by (securely) handing over the private keys than by continuing to maintain the relays themselves.
Sure. I can see this as well, though I think the same counterargument applies.
It is fine to note that this is something that could only make sense if done carefully. But claiming that the transfer of authority over private keys from on person to another must always be irresponsible diminishes the value of your primary point by overstating the argument.
I'm not totally convinced, but I don't run a DirAuth, and it's up to each DirAuth operator on what to do.
Apart from a short term decrease in network capacity/diversity, I see spinning up new relays as an equally good alternative here (with enough prior notice to teardown, even the current bwauths will get around to measuring things, assuming the chicken entrails are spread correctly), without all the tricky issues of secure data transfer and "trust".
Paranoid regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
What was knee-jerk about my response?
I found it also unnecessarily sharp, maybe because I assumed no malicious intent and I don't believe malicious actors depend on such 'pre-warmed' key offers anyway.
The relay identity key is sensitive cryptographic material. Sharing it means the private key is compromised
There are certainly different levels of sharing keys. Handing over operations of a relay to a 'trusted' third party might not be equally bad as publishing private keys on the internet or handing them over to the first 'random person' who is asking for them.
On Sun, 26 Jul 2015 05:32:17 +0500 Roman Mamedov rm@romanrm.net wrote:
On Sat, 25 Jul 2015 19:47:23 +0000 isis isis@torproject.org wrote:
I could take those backdoored^W"pre-warmed" keys and put them to good use!
Mkay, I'll get in touch in a few days.
Hello,
I have decided to spin up some more servers, and this should postpone the need to turn off any of the relays by at least 3 weeks (at the cost of an increased burn-rate, i.e. now they all will expire sooner and "all at once").
Also the reaction on the mailing list was not overly positive, so I might reconsider the idea of letting others reuse these identities altogether.
Thanks
On Wed, 29 Jul 2015 18:03:31 +0500 Roman Mamedov rm@romanrm.net wrote:
I have decided to spin up some more servers, and this should postpone the need to turn off any of the relays by at least 3 weeks (at the cost of an increased burn-rate, i.e. now they all will expire sooner and "all at once").
Ok. Have you thought about contacting other people that organize hosting (at the expense of further reducing relay operator diversity, I would suggest the Tor Servers people). If additional relay bandwidth is added now, the hope is that they will get through the measurement delay by the time you do need to decommission your servers.
Also the reaction on the mailing list was not overly positive, so I might reconsider the idea of letting others reuse these identities altogether.
So, first of all, I'd like to apologize for being overly harsh, since I'm fairly sure you had good intentions in mind when offering your relay ID keys.
Like I noted in my reply to Paul S. if there was a way to measure/quantify trust, or deal with the "people's Guards just potentially switched location, and definitely switched operator" side of this equation I would be a lot more open to this sort of thing.
But like the oft complained about bwauth stuff, these are unsolved problems. Each user/HS's Guard node is in a unique position to do extra nasty things to anonymity, so the threshold of trust for handing over control of Guard nodes for a large number of users is going to be rather high (Near insurmountable for the amount of bandwidth you are contributing).
The one upshot of all this is that people are now thinking about the implication of a Guard moving, which hopefully will lead to a safer Tor for the userbase in the future.
Regards,
On Wed, Jul 29, 2015 at 9:32 AM, Yawning Angel yawning@schwanenlied.me wrote:
Like I noted in my reply to Paul S. if there was a way to measure/quantify trust, or deal with the "people's Guards just
I'd agree that randomly handing off nodes is bad. And that there may be cases where structured handoff among operators or to new operators could be useful once such structure was developed. And that certainly people have handed off nodes amongst themselves privately many times before, be it amongst friends or some entity/sponsor running nodes where the original humans or entity has moved on, etc.
More on the notion of trust and metrics in the mesh...
"Node Operators Web Of Trust" https://lists.torproject.org/pipermail/tor-relays/2014-November/005710.html
potentially switched location
That would be picked up in geoip, and should be something Tor checks for on each startup (I don't know if Tor blindly uses fingerprints already in state file or revalidates them against all other metrics of the user before use.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 07/25/2015 08:40 PM, Roman Mamedov wrote:
Hello,
If anyone is planning to spin up a new VM or dedi to run a Tor relay and want it to be put instantly into good use (without wasting couple of weeks to a month for the whole "unmeasured relay/measured/guard/stable" cycle to complete) or if you are having trouble with your current relay being measured properly, in a few days I'm considering to give away several fingerprints+keys from my relays that I will be shutting down.
lol, you made my day.
- -- Toralf, pgp key: 872AE508 0076E94E
tor-relays@lists.torproject.org
-
grarpamp -
isis -
Kurt Besig -
nusenu -
Paul Syverson -
Roman Mamedov -
Toralf Förster -
Yawning Angel