4 of Conrad Rockenhaus trial servers are in the top ten exit relays for Canada
Hi, Just to let you know that following on with the one month trial with tor exit relays that Conrad kindly offered, at least four of his exit relays are now in the top 10 listing for Canada, out of 68 Canadian exit relays. https://metrics.torproject.org/rs.html#search/country:ca%20flag:exit Well done to Conrad - I say. The more, the merrier. If you want any help with setting up your own FreeBSD tor exit relay, feel free to contact me off list. Zim
On 27.08.18 19:11, zimmer linux wrote:
Well done to Conrad - I say. The more, the merrier.
I disagree. My personal experience with the trial, or more specifically with Conrad's behaviour, made it clear to me that he is not the kind of person I want to have a business relationship with. The honeymoon phase was quickly over after I said I would not rent VMs for the rest of this year, and what followed convinced me that I definitely can NOT recommend GreyPony IT. Your mileage may vary. -Ralph
Hi Ralph, Writing to you off-list. I'm sorry to hear you had a bad experience with GreyPony IT Services. Cordially, Nathaniel On Mon, Aug 27, 2018 at 1:59 PM Ralph Seichter <m16+tor@monksofcool.net> wrote:
On 27.08.18 19:11, zimmer linux wrote:
Well done to Conrad - I say. The more, the merrier.
I disagree. My personal experience with the trial, or more specifically with Conrad's behaviour, made it clear to me that he is not the kind of person I want to have a business relationship with. The honeymoon phase was quickly over after I said I would not rent VMs for the rest of this year, and what followed convinced me that I definitely can NOT recommend GreyPony IT. Your mileage may vary.
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
The trial period was for 30 days for one server. You were able to try out three servers at the same time. WHMCS calculated your trial period at 10 days and scheduled your instances for deletion. You didn’t even give me half of a day before you started acting paranoid that your instances were deleted because you didn’t want to pay for the service, which wasn’t the case at all, I didn’t even get the chance to look at the reason at what happened, or to even correct what happened, before you became hateful and became abusive. I decided the best course of action was to just disengage because I will not tolerate abuse of myself nor any employee of GreyPony. However, I won’t tolerate slander on the mailing list either. You received excellent service during your free trial. You had a custom Gentoo Image, just for you, deployed, which you were quite happy with, and now you have the audacity to slander Nathaniel’s and I’s work? Thank you, Have a good day.
On Aug 27, 2018, at 12:59 PM, Ralph Seichter <m16+tor@monksofcool.net> wrote:
On 27.08.18 19:11, zimmer linux wrote:
Well done to Conrad - I say. The more, the merrier.
I disagree. My personal experience with the trial, or more specifically with Conrad's behaviour, made it clear to me that he is not the kind of person I want to have a business relationship with. The honeymoon phase was quickly over after I said I would not rent VMs for the rest of this year, and what followed convinced me that I definitely can NOT recommend GreyPony IT. Your mileage may vary.
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 27.08.2018 23:00, Conrad Rockenhaus wrote:
You had a custom Gentoo Image, just for you, deployed, which you were quite happy with, and now you have the audacity to slander Nathaniel’s and I’s work?
Oh my, slander. Let's see: Slander: noun [ C or U ] UK /ˈslɑːn.dər/ US /ˈslæn.dɚ/ a false spoken statement about someone that damages their reputation, or the making of such a statement. Nope, no slander. No "fake news" either. If you take the time to search your memory, you'll find that I actually set up the Gentoo image myself and then agreed to let you make a copy of it for your own use. You know exactly what happened, and what with you using this forum to advertise, I thought it best to add my own opinion here as well, because not all is well and rosy. Oh, and I only take umbrage at your conduct, not Nathaniel's, with whom I did not have any direct dealings. Since you told me that you two are the whole staff of GreyPony IT, and since you're the owner, it is a weighty reason for me to avoid business with you. I know one should not attribute to malice what can be just as well be explained with incompetence, but either way, I don't feel comfortable with the situation. Your outburst only confirms that I made the right decision. I have been in this business for more than 35 years, and while it is good policy to give amateurs a chance, I usually choose to work with professionals. That's *my* choice, nobody else has to share it, but I can heartily recommend it if money is involved. -Ralph
Damn, none of this belongs on a public list. And for what it's worth, Ralph Seichter comes off worse than Conrad Rockenhaus does.
I'd be much more supportive of the typical "donate x to have a relay hosted for you" [1][2] rather than "host a relay with us" without maintaining them under the same family. If relays are running on his machines and he has access to relay keys, the person who installs Tor via pkg and starts it is hardly considered an operator. If 100% if your clients are hosting relays, you are the operator. Just my two cents. [1] https://emeraldonion.org/donate/ [2] https://www.torservers.net/donate.html On 8/27/2018 10:11 AM, zimmer linux wrote:
Hi,
Just to let you know that following on with the one month trial with tor exit relays that Conrad kindly offered, at least four of his exit relays are now in the top 10 listing for Canada, out of 68 Canadian exit relays.
https://metrics.torproject.org/rs.html#search/country:ca%20flag:exit
Well done to Conrad - I say. The more, the merrier.
If you want any help with setting up your own FreeBSD tor exit relay, feel free to contact me off list.
Zim
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Jordan https://yui.cat/
On 08/27/2018 04:42 PM, Jordan wrote:
I'd be much more supportive of the typical "donate x to have a relay hosted for you" [1][2] rather than "host a relay with us" without maintaining them under the same family.
That is an interesting question. Conrad's hosting operation is an extreme case, certainly. But consider two independently operated VPS relays in the same Digital Ocean data center, with arbitrarily similar IP addresses. And consider that both are vulnerable to compromise by Digital Ocean staff. Should they be part of the same family?
If relays are running on his machines and he has access to relay keys, the person who installs Tor via pkg and starts it is hardly considered an operator.
Well, any VPS provider has access to relay keys. FDE even is pointless on VPS, because the host can trivially bypass it.
If 100% if your clients are hosting relays, you are the operator.
Just my two cents.
[1] https://emeraldonion.org/donate/ [2] https://www.torservers.net/donate.html
On 8/27/2018 10:11 AM, zimmer linux wrote:
Hi,
Just to let you know that following on with the one month trial with tor exit relays that Conrad kindly offered, at least four of his exit relays are now in the top 10 listing for Canada, out of 68 Canadian exit relays.
https://metrics.torproject.org/rs.html#search/country:ca%20flag:exit
Well done to Conrad - I say. The more, the merrier.
If you want any help with setting up your own FreeBSD tor exit relay, feel free to contact me off list.
Zim
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
That is an interesting question. Conrad's hosting operation is an extreme case, certainly. But consider two independently operated VPS relays in the same Digital Ocean data center, with arbitrarily similar IP addresses. And consider that both are vulnerable to compromise by Digital Ocean staff. Should they be part of the same family?
No, because Digital Ocean doesn't market itself as a relay hoster-- the percentage of relay-hosting clients wouldn't even near 0.1%. On the other hand, if all (or the majority) of your operation contends on your customers hosting relays, I recommend they exist under the same family. -- Jordan https://yui.cat/
On 08/27/2018 05:17 PM, Jordan wrote:
That is an interesting question. Conrad's hosting operation is an extreme case, certainly. But consider two independently operated VPS relays in the same Digital Ocean data center, with arbitrarily similar IP addresses. And consider that both are vulnerable to compromise by Digital Ocean staff. Should they be part of the same family?
No, because Digital Ocean doesn't market itself as a relay hoster-- the percentage of relay-hosting clients wouldn't even near 0.1%.
What difference does that make? Digital Ocean certainly knows about all of the Tor relays that they host. Just from published IP addresses. What distinguishes them from Conrad's? I suppose that it could be the ease of compromise by third parties. But it's arguable that Digital Ocean is, if anything, more vulnerable than Conrad's operation.
On the other hand, if all (or the majority) of your operation contends on your customers hosting relays, I recommend they exist under the same family.
Please explain the reasoning behind that assertion.
No, because Digital Ocean doesn't market itself as a relay hoster-- the percentage of relay-hosting clients wouldn't even near 0.1%.
What difference does that make?
You quoted it, you can read it again if you'd like. There is little administrative overhead for Conrad to distribute a MyFamily directive for use with relays hosted on his systems. I care not for petty back-and-forth's when lives are at stake, sorry. -- Jordan https://yui.cat/
Jordan, Tor will already avoid making circuits where two IP Addresses in the same /24 are involved. The research in this paper ( https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays. Lives are involved and we've invested a lot of time in protecting our infrastructure. tCould Conrad and I go rouge and collect relay keys? Yes we have the technical capability to access data on any virtual machine hosted on our infrastructure, but so could DigitalOcean, Scaleway, BuyVM, and the several other big ISPs hosting exit relays on Virtual Machines. > There is little administrative overhead for Conrad to distribute a MyFamily directive for use with relays hosted on his systems. *Two things:* 1) Today, sure, I guess its easy, what if we have 100 or 1000 clients tomorrow all hosting exit relays. It suddenly gets much more complicated than it was at first. Why aren't people asking Digitalocean and Scaleway to do the same? After all Digitalocean and Scaleway have way more staff who could be dedicated Tor relay managers. See the logic here? 2) We can't force our clients to modify their MyFamily directive in their torrc files. There's the possibility they refuse to modify. In the end, it's about trusting your provider. Tor's threat model shouldn't rely on hosting providers playing nice. It should continue to rely on the continued split of trust. Although, better path selection could play in here :) Cordially, Nathaniel Suchy On Mon, Aug 27, 2018 at 8:37 PM Jordan <jordan@yui.cat> wrote: > >> No, because Digital Ocean doesn't market itself as a relay hoster-- the > >> percentage of relay-hosting clients wouldn't even near 0.1%. > > > > What difference does that make? > > You quoted it, you can read it again if you'd like. > > There is little administrative overhead for Conrad to distribute a > MyFamily directive for use with relays hosted on his systems. > > I care not for petty back-and-forth's when lives are at stake, sorry. > > -- > Jordan > https://yui.cat/ > _______________________________________________ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >
Tor will already avoid making circuits where two IP Addresses in the same /24 are involved. The research in this paper (https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
A valid point, thanks for linking the paper. I have the utmost belief your intentions are good, but the concentration of exits under a non-advertised central control warrants conversation, at least. If the end goal is turning $ into relays, not all paths are paved with equal mind to security and it might be worth considering donation-backed alternatives. Have a good one, -- Jordan https://yui.cat/
One might worry more what Mega and Gigacorps are doing, secret partner friendly endeavours with Govts against you, than what some tiny ISP or whoever is doing with a few boxes. And was posted here many times about creating additional trust models and layers for relays, audits metrics and choices for users beyond the CIDR/nn and Family game that might go towards satisfying some reasonable concerns in that space... but crickets. And when you can't trust your CPUs, ISPs, operators, Govts, or even your own anonymous overlay networks strength against them... it's probably time for strategic rethink.
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat> wrote:
Tor will already avoid making circuits where two IP Addresses in the same /24 are involved. The research in this paper (https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
A valid point, thanks for linking the paper. I have the utmost belief your intentions are good, but the concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved with equal mind to security and it might be worth considering donation-backed alternatives.
Have a good one,
-- Jordan https://yui.cat/
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance. They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth. Thank you, Conrad
Hi Conrad (and staff and operators),
On 28 Aug 2018, at 22:16, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat> wrote:
... The research in this paper (https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
... I have the utmost belief your intentions are good, but the concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved with equal mind to security and it might be worth considering donation-backed alternatives.
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance.
They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth.
This is the 5th list post in the last few weeks describing Greypony IT's services, operators, or relays. There have also been several critical posts. Please take a break from promoting or criticising Greypony on this list until at least October 2018. If you feel the need to respond, please use another platform. Thanks T
Just banish them from Tor already! They are ruining our network, they lie about their network speeds, and they lie about their capabilities. On Tue, Aug 28, 2018 at 11:37 PM teor <teor@riseup.net> wrote:
Hi Conrad (and staff and operators),
On 28 Aug 2018, at 22:16, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat> wrote:
... The research in this paper (
https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
... I have the utmost belief your intentions are good, but the
concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved with
equal mind to security and it might be worth considering donation-backed alternatives.
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance.
They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth.
This is the 5th list post in the last few weeks describing Greypony IT's services, operators, or relays.
There have also been several critical posts.
Please take a break from promoting or criticising Greypony on this list until at least October 2018.
If you feel the need to respond, please use another platform.
Thanks
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi teor, It seems the criticism originated from one guy (Ralph) and one troll who bravely refuses to identify himself. You want me to stop talking about even the cool things we’re accomplishing thing (like pumping lots of ultra fast bandwidth into the community) because of these two, perhaps one yahoos? Thanks, Conrad On Tue, Aug 28, 2018 at 11:37 PM teor <teor@riseup.net> wrote:
Hi Conrad (and staff and operators),
On 28 Aug 2018, at 22:16, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat> wrote:
... The research in this paper (
https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
... I have the utmost belief your intentions are good, but the
concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved with
equal mind to security and it might be worth considering donation-backed alternatives.
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance.
They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth.
This is the 5th list post in the last few weeks describing Greypony IT's services, operators, or relays.
There have also been several critical posts.
Please take a break from promoting or criticising Greypony on this list until at least October 2018.
If you feel the need to respond, please use another platform.
Thanks
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Conrad Rockenhaus https://www.rockenhaus.com ------ Get started with GreyPony Anonymization Today! https://www.greyponyit.com
Conrad, I have been following this thread and would be grateful if you could clear up some confusion for me. Firstly, I am not 1337 haxorz, I dont have a technical profession. However I do believe in tor and anything that can increase the number of relays is good. You are donating your time and resources freely to tor for the benefit of everyone. You have helped me, others on this list, as well as countless others contribute to the Tor Project. All these large relays that you are managing - surely this is bad in terms of AS diversity? One user / network provider shouldn't have a large control over the network. My question: Is there anyway that these relays can be added to the network in such a way that does not damage diversity? Dont get me wrong - I believe in what you do. If these relays are been added without damaging diversity then I apologise for my misunderstanding of the topic. Thanks, Gary On Sat, 1 Sep 2018 at 00:12, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
Hi teor,
It seems the criticism originated from one guy (Ralph) and one troll who bravely refuses to identify himself.
You want me to stop talking about even the cool things we’re accomplishing thing (like pumping lots of ultra fast bandwidth into the community) because of these two, perhaps one yahoos?
Thanks,
Conrad
On Tue, Aug 28, 2018 at 11:37 PM teor <teor@riseup.net> wrote:
Hi Conrad (and staff and operators),
On 28 Aug 2018, at 22:16, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat> wrote:
... The research in this paper (
https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
... I have the utmost belief your intentions are good, but the
concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved with
equal mind to security and it might be worth considering donation-backed alternatives.
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance.
They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth.
This is the 5th list post in the last few weeks describing Greypony IT's services, operators, or relays.
There have also been several critical posts.
Please take a break from promoting or criticising Greypony on this list until at least October 2018.
If you feel the need to respond, please use another platform.
Thanks
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Conrad Rockenhaus https://www.rockenhaus.com ------ Get started with GreyPony Anonymization Today! https://www.greyponyit.com _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Gary, It’s bad in the same way it’s bad as the other numerous other exit relays that run under the OVH umbrella. I am not my own independent upstream and run my servers at a colocation facility at OVH. I also plan on running my servers at a colocation facility at another location for AS-diversity purposes but donations aren’t enough to cover all of the bills to be honest, but I’m partnering up with a fellow Texan and we’ll make sure this nonprofit grows at the rate needed to support diversity. But if you ignore the emails sounding alarm about this or that, you should realize - Greypony is no different than Hetzner, OVH, or DigitialOcrean - which rank in the top 5 of the Tor relay providers by size and bandwidth, by node count, AS, and bandwidth. Someone should ask those providers the exact same thing, because they’re setup just like me - I don’t have root access to a customer’s server - they don’t have access. I’m actually a little drop in the big bucket But I’ve been trying to promote diversity through the use of other providers. Thanks, Conrad
On Sep 1, 2018, at 6:53 AM, Gary <jaffacakemonster53@gmail.com> wrote:
Conrad,
I have been following this thread and would be grateful if you could clear up some confusion for me.
Firstly, I am not 1337 haxorz, I dont have a technical profession. However I do believe in tor and anything that can increase the number of relays is good. You are donating your time and resources freely to tor for the benefit of everyone. You have helped me, others on this list, as well as countless others contribute to the Tor Project.
All these large relays that you are managing - surely this is bad in terms of AS diversity? One user / network provider shouldn't have a large control over the network.
My question:
Is there anyway that these relays can be added to the network in such a way that does not damage diversity?
Dont get me wrong - I believe in what you do. If these relays are been added without damaging diversity then I apologise for my misunderstanding of the topic.
Thanks,
Gary
On Sat, 1 Sep 2018 at 00:12, Conrad Rockenhaus <conrad@rockenhaus.com> wrote: Hi teor,
It seems the criticism originated from one guy (Ralph) and one troll who bravely refuses to identify himself.
You want me to stop talking about even the cool things we’re accomplishing thing (like pumping lots of ultra fast bandwidth into the community) because of these two, perhaps one yahoos?
Thanks,
Conrad
On Tue, Aug 28, 2018 at 11:37 PM teor <teor@riseup.net> wrote: Hi Conrad (and staff and operators),
On 28 Aug 2018, at 22:16, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat> wrote:
... The research in this paper (https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
... I have the utmost belief your intentions are good, but the concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved with equal mind to security and it might be worth considering donation-backed alternatives.
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance.
They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth.
This is the 5th list post in the last few weeks describing Greypony IT's services, operators, or relays.
There have also been several critical posts.
Please take a break from promoting or criticising Greypony on this list until at least October 2018.
If you feel the need to respond, please use another platform.
Thanks
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Conrad Rockenhaus https://www.rockenhaus.com ------ Get started with GreyPony Anonymization Today! https://www.greyponyit.com _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Conrad, Thank you for your reply. I can now see that 4 big + 1 small (or 5 big) providers is definitely better than only 4 big ones for diversity, but it leads to another diversity question which needs some background: For a while, earlier this year during the spectre / meltdown vulnerability commotion I ran a couple of relays in VM's using Amazon Web Services (AWS). I was confident in the knowledge that the AWS provided kernels / VM's switched to the spectre mitigation measures. Sure they slowed down a bit for a while, but they speeded up again when after AWS tweaked it a little. Because I know my VM's were using the mitigation I know other VM's can't spy on the tor traffic & what ever encryption keys happens to been in the VM's memory at that time (the really paranoid can supply their own kernel / boot image to run). My VM's were probably running in a rack containing hardware that also runs websites, web applications, corporate cloud email and backup systems the list could go on, but it importantly it is about diversity. If one person were to run a hardware rack full of VM's that ALL run tor - that is a prime target for, for example, some spying government or international hacker group. For an admittedly far fetched example, some government can fly in, flash a court warrant to an underpaid security guard and do whatever they want to the rack, and then ALL the tor relays that are hosted there are compromised. Yes thats unlikely to happen but its still a risk. I am interested to hear your opinion on the diversity question of - How does having many relays in one place not damage diversity, even if they are connected to different networks / AS's are are technically controlled by different people. Again I want to point out what you are doing is good - I apologise if I appear to be "trolling" you, I am genuinely interested in learning the technical pro's and con's relating to this topic. Thanks again, Gary. On Sun, 2 Sep 2018 at 02:26, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
Gary,
It’s bad in the same way it’s bad as the other numerous other exit relays that run under the OVH umbrella. I am not my own independent upstream and run my servers at a colocation facility at OVH. I also plan on running my servers at a colocation facility at another location for AS-diversity purposes but donations aren’t enough to cover all of the bills to be honest, but I’m partnering up with a fellow Texan and we’ll make sure this nonprofit grows at the rate needed to support diversity.
But if you ignore the emails sounding alarm about this or that, you should realize - Greypony is no different than Hetzner, OVH, or DigitialOcrean - which rank in the top 5 of the Tor relay providers by size and bandwidth, by node count, AS, and bandwidth. Someone should ask those providers the exact same thing, because they’re setup just like me - I don’t have root access to a customer’s server - they don’t have access.
I’m actually a little drop in the big bucket But I’ve been trying to promote diversity through the use of other providers.
Thanks,
Conrad
On Sep 1, 2018, at 6:53 AM, Gary <jaffacakemonster53@gmail.com> wrote:
Conrad,
I have been following this thread and would be grateful if you could clear up some confusion for me.
Firstly, I am not 1337 haxorz, I dont have a technical profession. However I do believe in tor and anything that can increase the number of relays is good. You are donating your time and resources freely to tor for the benefit of everyone. You have helped me, others on this list, as well as countless others contribute to the Tor Project.
All these large relays that you are managing - surely this is bad in terms of AS diversity? One user / network provider shouldn't have a large control over the network.
My question:
Is there anyway that these relays can be added to the network in such a way that does not damage diversity?
Dont get me wrong - I believe in what you do. If these relays are been added without damaging diversity then I apologise for my misunderstanding of the topic.
Thanks,
Gary
On Sat, 1 Sep 2018 at 00:12, Conrad Rockenhaus <conrad@rockenhaus.com> wrote: Hi teor,
It seems the criticism originated from one guy (Ralph) and one troll who bravely refuses to identify himself.
You want me to stop talking about even the cool things we’re accomplishing thing (like pumping lots of ultra fast bandwidth into the community) because of these two, perhaps one yahoos?
Thanks,
Conrad
On Tue, Aug 28, 2018 at 11:37 PM teor <teor@riseup.net> wrote: Hi Conrad (and staff and operators),
On 28 Aug 2018, at 22:16, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat> wrote:
... The research in this paper (
https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
... I have the utmost belief your intentions are good, but the
concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved
with equal mind to security and it might be worth considering donation-backed alternatives.
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance.
They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth.
This is the 5th list post in the last few weeks describing Greypony IT's services, operators, or relays.
There have also been several critical posts.
Please take a break from promoting or criticising Greypony on this list until at least October 2018.
If you feel the need to respond, please use another platform.
Thanks
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Conrad Rockenhaus https://www.rockenhaus.com ------ Get started with GreyPony Anonymization Today! https://www.greyponyit.com _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Meltdown and Spectre are interesting intellectually but real world breaches tend to be more prosaic. It's the boring stuff that gets us: social engineering, shitty passwords, out-of-date software. We see it over and over in the news and in overviews like the DBIR. I'm not saying we should ignore those vulns but we shouldn't dig a deeper moat while leaving the drawbridge down. Let's make sure we're doing a good job on the basics. --mkb
On Sep 2, 2018, at 6:21 AM, Gary <jaffacakemonster53@gmail.com <mailto:jaffacakemonster53@gmail.com>> wrote:
Conrad,
Thank you for your reply. I can now see that 4 big + 1 small (or 5 big) providers is definitely better than only 4 big ones for diversity, but it leads to another diversity question which needs some background:
For a while, earlier this year during the spectre / meltdown vulnerability commotion I ran a couple of relays in VM's using Amazon Web Services (AWS). I was confident in the knowledge that the AWS provided kernels / VM's switched to the spectre mitigation measures. Sure they slowed down a bit for a while, but they speeded up again when after AWS tweaked it a little. Because I know my VM's were using the mitigation I know other VM's can't spy on the tor traffic & what ever encryption keys happens to been in the VM's memory at that time (the really paranoid can supply their own kernel / boot image to run).
My VM's were probably running in a rack containing hardware that also runs websites, web applications, corporate cloud email and backup systems the list could go on, but it importantly it is about diversity.
If one person were to run a hardware rack full of VM's that ALL run tor - that is a prime target for, for example, some spying government or international hacker group. For an admittedly far fetched example, some government can fly in, flash a court warrant to an underpaid security guard and do whatever they want to the rack, and then ALL the tor relays that are hosted there are compromised. Yes thats unlikely to happen but its still a risk.
I am interested to hear your opinion on the diversity question of - How does having many relays in one place not damage diversity, even if they are connected to different networks / AS's are are technically controlled by different people.
Again I want to point out what you are doing is good - I apologise if I appear to be "trolling" you, I am genuinely interested in learning the technical pro's and con's relating to this topic.
Thanks again,
Gary.
On Sun, 2 Sep 2018 at 02:26, Conrad Rockenhaus <conrad@rockenhaus.com <mailto:conrad@rockenhaus.com>> wrote: Gary,
It’s bad in the same way it’s bad as the other numerous other exit relays that run under the OVH umbrella. I am not my own independent upstream and run my servers at a colocation facility at OVH. I also plan on running my servers at a colocation facility at another location for AS-diversity purposes but donations aren’t enough to cover all of the bills to be honest, but I’m partnering up with a fellow Texan and we’ll make sure this nonprofit grows at the rate needed to support diversity.
But if you ignore the emails sounding alarm about this or that, you should realize - Greypony is no different than Hetzner, OVH, or DigitialOcrean - which rank in the top 5 of the Tor relay providers by size and bandwidth, by node count, AS, and bandwidth. Someone should ask those providers the exact same thing, because they’re setup just like me - I don’t have root access to a customer’s server - they don’t have access.
I’m actually a little drop in the big bucket But I’ve been trying to promote diversity through the use of other providers.
Thanks,
Conrad
On Sep 1, 2018, at 6:53 AM, Gary <jaffacakemonster53@gmail.com <mailto:jaffacakemonster53@gmail.com>> wrote:
Conrad,
I have been following this thread and would be grateful if you could clear up some confusion for me.
Firstly, I am not 1337 haxorz, I dont have a technical profession. However I do believe in tor and anything that can increase the number of relays is good. You are donating your time and resources freely to tor for the benefit of everyone. You have helped me, others on this list, as well as countless others contribute to the Tor Project.
All these large relays that you are managing - surely this is bad in terms of AS diversity? One user / network provider shouldn't have a large control over the network.
My question:
Is there anyway that these relays can be added to the network in such a way that does not damage diversity?
Dont get me wrong - I believe in what you do. If these relays are been added without damaging diversity then I apologise for my misunderstanding of the topic.
Thanks,
Gary
On Sat, 1 Sep 2018 at 00:12, Conrad Rockenhaus <conrad@rockenhaus.com <mailto:conrad@rockenhaus.com>> wrote: Hi teor,
It seems the criticism originated from one guy (Ralph) and one troll who bravely refuses to identify himself.
You want me to stop talking about even the cool things we’re accomplishing thing (like pumping lots of ultra fast bandwidth into the community) because of these two, perhaps one yahoos?
Thanks,
Conrad
On Tue, Aug 28, 2018 at 11:37 PM teor <teor@riseup.net <mailto:teor@riseup.net>> wrote: Hi Conrad (and staff and operators),
On 28 Aug 2018, at 22:16, Conrad Rockenhaus <conrad@rockenhaus.com <mailto:conrad@rockenhaus.com>> wrote:
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat <mailto:jordan@yui.cat>> wrote:
... The research in this paper (https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf <https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf>) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
... I have the utmost belief your intentions are good, but the concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved with equal mind to security and it might be worth considering donation-backed alternatives.
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance.
They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth.
This is the 5th list post in the last few weeks describing Greypony IT's services, operators, or relays.
There have also been several critical posts.
Please take a break from promoting or criticising Greypony on this list until at least October 2018.
If you feel the need to respond, please use another platform.
Thanks
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> -- Conrad Rockenhaus https://www.rockenhaus.com <https://www.rockenhaus.com/> ------ Get started with GreyPony Anonymization Today! https://www.greyponyit.com <https://www.greyponyit.com/> _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thank you for your reply. I can now see that 4 big + 1 small (or 5 big) providers is definitely better than only 4 big ones for diversity, but it leads to another diversity question which needs some background:
For a while, earlier this year during the spectre / meltdown vulnerability commotion I ran a couple of relays in VM's using Amazon Web Services (AWS). I was confident in the knowledge that the AWS provided kernels / VM's switched to the spectre mitigation measures. Sure they slowed down a bit for a while, but they speeded up again when after AWS tweaked it a little. Because I know my VM's were using the mitigation I know other VM's can't spy on the tor traffic & what ever encryption keys happens to been in the VM's memory at that time (the really paranoid can supply their own kernel / boot image to run).
All major operating systems provided mitigation/and or patches to correct this vulnerability. Just because you were using Amazon Linux doesn’t mean that Amazon did anything special. All the major Linux distributions had mitigation measures and/or patches, as well as FreeBSD. If you had automatic updated turned on for your respective OS they were brought online automatically, but most people I know don’t have automatic updates turned on because they like being able to control when updates are installed. There’s nothing special about what AWS does that major OS distributions aren’t doing already. Plus, I’m sorry, but I don’t consider CPU meltdown attacks are great in theory and all, but your greatest threat is always going to be password compromise, social engineering, or something of that sort. It’s the small stuff that typically matters more than some major thing that looks like the end of the world on paper.
My VM's were probably running in a rack containing hardware that also runs websites, web applications, corporate cloud email and backup systems the list could go on, but it importantly it is about diversity.
So are mine. I don’t just provide Tor related services.w
If one person were to run a hardware rack full of VM's that ALL run tor - that is a prime target for, for example, some spying government or international hacker group. For an admittedly far fetched example, some government can fly in, flash a court warrant to an underpaid security guard and do whatever they want to the rack, and then ALL the tor relays that are hosted there are compromised. Yes thats unlikely to happen but its still a risk.
Who said they all run Tor? You’re just making an assumption here. There’s a variety of services that are ran, in fact, I host a high traffic website within the same rack; it was the excess capacity from that project that led to the donation driven project that is Greypony. The Government can do this anyway, and they’ve raided places before, even places that were running operations other than Tor at that location. It could be one server or 100 servers, if there’s governmental interest, the government will use their means to get into that server, It’s not exactly the best example.
I am interested to hear your opinion on the diversity question of - How does having many relays in one place not damage diversity, even if they are connected to different networks / AS's are are technically controlled by different people.
I’m interested in how that damages any sort of diversity, other than the fact that you have a concentrated number of relays in one location, which has been going on for a long time, prior to GreyPony putting up high bandwidth relays. People only started having concerns when Greypony came along with our high bandwidth relays, even though we have significant technical safeguards in place to prevent snooping of traffic (especially within our rack) or obtaining any discernible data off of the drives, which are encrypted. (Some of our users encrypt their data data on top of that as well, so, anyway.) You need to really look at the definition of diversity, because it seems according to you, I could setup a new datacenter that no existing tor services exist in and that would be damaging to Tor’s diversity for some reason…..which a significant amount of people would disagree.
Again I want to point out what you are doing is good - I apologise if I appear to be "trolling" you, I am genuinely interested in learning the technical pro's and con's relating to this topic.
I don’t consider this trolling, but this is the real world. There normally isn’t a huge grand conspiracy and someone’s not out there waiting to melt processors. It’s all fun to discuss in theory, but in the end, that’s not what’s happening in the real world. Conrad
Thanks again,
Gary.
On Sun, 2 Sep 2018 at 02:26, Conrad Rockenhaus <conrad@rockenhaus.com> wrote: Gary,
It’s bad in the same way it’s bad as the other numerous other exit relays that run under the OVH umbrella. I am not my own independent upstream and run my servers at a colocation facility at OVH. I also plan on running my servers at a colocation facility at another location for AS-diversity purposes but donations aren’t enough to cover all of the bills to be honest, but I’m partnering up with a fellow Texan and we’ll make sure this nonprofit grows at the rate needed to support diversity.
But if you ignore the emails sounding alarm about this or that, you should realize - Greypony is no different than Hetzner, OVH, or DigitialOcrean - which rank in the top 5 of the Tor relay providers by size and bandwidth, by node count, AS, and bandwidth. Someone should ask those providers the exact same thing, because they’re setup just like me - I don’t have root access to a customer’s server - they don’t have access.
I’m actually a little drop in the big bucket But I’ve been trying to promote diversity through the use of other providers.
Thanks,
Conrad
On Sep 1, 2018, at 6:53 AM, Gary <jaffacakemonster53@gmail.com> wrote:
Conrad,
I have been following this thread and would be grateful if you could clear up some confusion for me.
Firstly, I am not 1337 haxorz, I dont have a technical profession. However I do believe in tor and anything that can increase the number of relays is good. You are donating your time and resources freely to tor for the benefit of everyone. You have helped me, others on this list, as well as countless others contribute to the Tor Project.
All these large relays that you are managing - surely this is bad in terms of AS diversity? One user / network provider shouldn't have a large control over the network.
My question:
Is there anyway that these relays can be added to the network in such a way that does not damage diversity?
Dont get me wrong - I believe in what you do. If these relays are been added without damaging diversity then I apologise for my misunderstanding of the topic.
Thanks,
Gary
On Sat, 1 Sep 2018 at 00:12, Conrad Rockenhaus <conrad@rockenhaus.com> wrote: Hi teor,
It seems the criticism originated from one guy (Ralph) and one troll who bravely refuses to identify himself.
You want me to stop talking about even the cool things we’re accomplishing thing (like pumping lots of ultra fast bandwidth into the community) because of these two, perhaps one yahoos?
Thanks,
Conrad
On Tue, Aug 28, 2018 at 11:37 PM teor <teor@riseup.net> wrote: Hi Conrad (and staff and operators),
On 28 Aug 2018, at 22:16, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
On Aug 27, 2018, at 8:02 PM, Jordan <jordan@yui.cat> wrote:
... The research in this paper (https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf) is becoming more relevent and is worth discussing as more ISPs come out with the goal of hosting lots and lots of exit relays.
... I have the utmost belief your intentions are good, but the concentration of exits under a non-advertised central control warrants conversation, at least.
If the end goal is turning $ into relays, not all paths are paved with equal mind to security and it might be worth considering donation-backed alternatives.
Actually, Jordan, I appreciate your input, but Greypony is technically operating as a nonprofit organization right now. We’re completing the paperwork to be considered an official nonprofit. We allow people to operate their own relay, on their own HVM instance (which we don’t have access to) for a donation of $15/month for a basic model A instance.
They’re totally separately and independently operated relays. We don’t tell them how to operate their relays. We provide support, we provide suggestions, but we don’t operate it for them, we don’t install anything for them, and we’re completely hands off unless they need support with something. Our job is to provide the instance and the bandwidth.
This is the 5th list post in the last few weeks describing Greypony IT's services, operators, or relays.
There have also been several critical posts.
Please take a break from promoting or criticising Greypony on this list until at least October 2018.
If you feel the need to respond, please use another platform.
Thanks
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Conrad Rockenhaus https://www.rockenhaus.com ------ Get started with GreyPony Anonymization Today! https://www.greyponyit.com _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 01.09.18 01:11, Conrad Rockenhaus wrote:
You want me to stop talking about even the cool things we’re accomplishing thing [...] because of these two, perhaps one yahoos?
Ad hominem once again? Tut-tut Conrad, you keep disappointing me. Attempting to insult me because I decide not to do business with you, based on my personal experience, is such a Trumpish thing to do. Still, the person hiding behind a GMail address should man up, I'll give you that. The Tor mailing list is not a billboard, so if you feel the urge to repeatedly advertise and write about "accomplishing thing" [sic], I suggest you set up your own. -Ralph
On 28 Aug 2018, at 10:47, Nathaniel Suchy <me@lunorian.is> wrote:
Tor will already avoid making circuits where two IP Addresses in the same /24 are involved.
If you grow beyond a /24, it's worth knowing that Tor's current path selection avoids the same /16 for IPv4, and will soon avoid the same /32 for IPv6: https://trac.torproject.org/projects/tor/ticket/24393 T
Hi again,,
A valid point, thanks for linking the paper. I have the utmost belief your intentions are good, but the concentration of exits under a non-advertised central control warrants conversation, at least.
I discussing the best way to handle this is important. However I think it's unfair to expect one small provider to go through the hassle of correlating MyFamily across customers, while big providers like Digitalocean are fine.
If you grow beyond a /24, it's worth knowing that Tor's current path selection avoids the same /16 for IPv4, and will soon avoid the same /32 for IPv6: https://trac.torproject.org/projects/tor/ticket/24393
The avoiding /32 will be very positive as IPv6 relays become more wipe spread.
If the end goal is turning $ into relays, not all paths are paved with equal mind to security and it might be worth considering donation-backed alternatives.
Two things here: 1) We are hosting more than just Tor relays. While Tor relay operators are a target demographic, over time we expect to be a free speech friendly hosting provider, and also already offer remote desktops and a vpn service. In the future it's quite possible that we may have a donation option for managed Tor exits. There are a lot of options we could take. 2) While we can technically access a customer's data if we're motivated enough - we believe splitting control across different operators is important.
One might worry more what Mega and Gigacorps are doing, secret partner friendly endeavours with Govts against you, than what some tiny ISP or whoever is doing with a few boxes.
It's quite true hosting providers might collude with law enforcement. Tor isn't designed to fight against a global passive adversary, there isn't enough research on protecting against a such a powerful adversary.
And was posted here many times about creating additional trust models and layers for relays, audits metrics and choices for users beyond the CIDR/nn and Family game that might go towards satisfying some reasonable concerns in that space... but crickets.
And when you can't trust your CPUs, ISPs, operators, Govts, or even your own anonymous overlay networks strength against them... it's probably time for strategic rethink.
When it gets to the point you are worried all computers have a hardware backdoor, maybe computers and the internet are too dangerous for your thread model and you should consider alternate ways of communication not involving technology. Teor: I read your email regarding off-topic emails and I agree. I'm going to create a new thread regarding path selection and relays at the same hosting provider. I don't want to continue a thread regarding Conrad and I's services as that's been discussed enough. Let's discuss path selection among the same hosting provider in general. On Mon, Aug 27, 2018 at 10:09 PM teor <teor@riseup.net> wrote:
On 28 Aug 2018, at 10:47, Nathaniel Suchy <me@lunorian.is> wrote:
Tor will already avoid making circuits where two IP Addresses in the same /24 are involved.
If you grow beyond a /24, it's worth knowing that Tor's current path selection avoids the same /16 for IPv4, and will soon avoid the same /32 for IPv6: https://trac.torproject.org/projects/tor/ticket/24393
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Jordan:
I'd be much more supportive of the typical "donate x to have a relay hosted for you" [1][2] rather than "host a relay with us" without maintaining them under the same family.
If relays are running on his machines and he has access to relay keys,
Not necessarily, it depends on what keys. You can run a relay on infrastructure, without exposing the relay's ed25519 identity keys to that infrastructure (and therefore the hoster) https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKe... -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
Is there a way to switch my current relays to use offline keys and invalidate the old keys without losing current stats? On Tue, Aug 28, 2018 at 7:28 AM nusenu <nusenu-lists@riseup.net> wrote:
Jordan:
I'd be much more supportive of the typical "donate x to have a relay hosted for you" [1][2] rather than "host a relay with us" without maintaining them under the same family.
If relays are running on his machines and he has access to relay keys,
Not necessarily, it depends on what keys. You can run a relay on infrastructure, without exposing the relay's ed25519 identity keys to that infrastructure (and therefore the hoster)
https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKe...
-- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Sorry for late. Whats up...? here is my : alexflores866@yahoo.comtlak to here... Sent from my iPhone On Wednesday, August 29, 2018 1:07 AM, Nathaniel Suchy <me@lunorian.is> wrote: Is there a way to switch my current relays to use offline keys and invalidate the old keys without losing current stats? On Tue, Aug 28, 2018 at 7:28 AM nusenu <nusenu-lists@riseup.net> wrote: Jordan:
I'd be much more supportive of the typical "donate x to have a relay hosted for you" [1][2] rather than "host a relay with us" without maintaining them under the same family.
If relays are running on his machines and he has access to relay keys,
Not necessarily, it depends on what keys. You can run a relay on infrastructure, without exposing the relay's ed25519 identity keys to that infrastructure (and therefore the hoster) https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKe... -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays | | Virus-free. www.avast.com |
Nathaniel Suchy:
Is there a way to switch my current relays to use offline keys and invalidate the old keys without losing current stats?
you can switch between the modes (OfflineMasterKey 0|1) but to get the best out of it, it is best to start with fresh masterkeys that never touched an online system (that means, creating a new set of keys and loosing the "history"/reputation of the relay) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
On 29 Aug 2018, at 05:38, nusenu <nusenu-lists@riseup.net> wrote:
Signed PGP part
Nathaniel Suchy:
Is there a way to switch my current relays to use offline keys and invalidate the old keys without losing current stats?
you can switch between the modes (OfflineMasterKey 0|1) but to get the best out of it, it is best to start with fresh masterkeys that never touched an online system
(that means, creating a new set of keys and loosing the "history"/reputation of the relay)
To be clear: You must create a new ed25519 key *and* a new RSA key. If you only change one, the directory authorities will drop your relay from the consensus. (This "key-pinning" is a security feature.) T
Thanks for the heads up. On Tue, Aug 28, 2018 at 8:42 PM teor <teor@riseup.net> wrote:
On 29 Aug 2018, at 05:38, nusenu <nusenu-lists@riseup.net> wrote:
Signed PGP part
Nathaniel Suchy:
Is there a way to switch my current relays to use offline keys and invalidate the old keys without losing current stats?
you can switch between the modes (OfflineMasterKey 0|1) but to get the best out of it, it is best to start with fresh masterkeys that never touched an online system
(that means, creating a new set of keys and loosing the "history"/reputation of the relay)
To be clear:
You must create a new ed25519 key *and* a new RSA key.
If you only change one, the directory authorities will drop your relay from the consensus. (This "key-pinning" is a security feature.)
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (13)
-
Alex Flores -
Conrad Rockenhaus -
Gary -
grarpamp -
Jordan -
Michael Brodhead -
Mirimir -
Nathaniel Suchy -
nusenu -
Ralph Seichter -
teor -
Tor Professional -
zimmer linux