Hello All, If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1. If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth). Regards, Conrad Rockenhaus
i am iterrested :-) have you a ovm or harddiskimage ? regards Steffen TorGate torgate(at)linux-hus.dk OpenGPG 7FD5 65EF A4EF EEF3 7A13 4372 8409 49D6 01A2 0890
Am 25.02.2018 um 21:50 schrieb Conrad Rockenhaus <conrad@rockenhaus.com>:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Regards,
Conrad Rockenhaus_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sunday, February 25, 2018 2:59:38 PM CST TorGate wrote:
i am iterrested :-) have you a ovm or harddiskimage ?
Right now it's a RAW image, but it can be converted to whatever format you need with QEMU-image... I just converted it to VDI right now to start nuking the /usr/src stuff.
regards Steffen TorGate torgate(at)linux-hus.dk OpenGPG 7FD5 65EF A4EF EEF3 7A13 4372 8409 49D6 01A2 0890
Am 25.02.2018 um 21:50 schrieb Conrad Rockenhaus <conrad@rockenhaus.com>:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Regards,
Conrad Rockenhaus_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs. However, I'd be wary of an image that I didn't build myself, personally.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%. https://torbsd.org/oostats/relays-bw-by-asn.txt OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters. The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images. http://wiki.torbsd.org/doku.php?id=en:bsd-vps g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
+1 -- https://mastodon.social/@nusenu twitter: @nusenu_
On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
My main thought process behind trying to ease the implementation of BSD relays is the fact that we should diversify what we have online within the network. Most of our nodes are Linux. What if we have another vulnerability that comes out that hits Linux specifically again?
However, I'd be wary of an image that I didn't build myself, personally.
That's your opinion. The AWS relay project was very successful. Numerous people ran an image that they didn't build. Numerous people also run Docker containers that they didn't build. Numerous people run Vagrant boxes they didn't build. You have the right to be weary, but there's numerous people out there who run other people's images everyday.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why 15% of our exits are on OVH.
https://torbsd.org/oostats/relays-bw-by-asn.txt
OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters.
I completely agree.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
It would actually be very easy to find tampering within a BSD operating system. Again, you're welcome to your opinion, but this is no the first time an image has been offered to assist people within in the network, and again, with your view, let's get rid of the tor docker containers, the AWS AMIs, etc. Regards, Conrad
http://wiki.torbsd.org/doku.php?id=en:bsd-vps
g
Conrad Rockenhaus:
On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
My main thought process behind trying to ease the implementation of BSD relays is the fact that we should diversify what we have online within the network. Most of our nodes are Linux. What if we have another vulnerability that comes out that hits Linux specifically again?
Oh, absolutely. Completely valid and the reason for The Tor BSD Diversity Project's existence. It's even uglier with bridges than with public relays. Our stats give daily snapshots to back your point: https://torbsd.org/oostats.html
However, I'd be wary of an image that I didn't build myself, personally.
That's your opinion. The AWS relay project was very successful. Numerous people ran an image that they didn't build. Numerous people also run Docker containers that they didn't build. Numerous people run Vagrant boxes they didn't build. You have the right to be weary, but there's numerous people out there who run other people's images everyday.
Yes, being wary should be a guiding principle IMHO. I'm aware of the other image-based roll-outs, but I just wanted to add a disclaiming comment. Personally, I'm purely for bare-metal server solutions to minimize (although it doesn't eliminate) external trust. I understand that images from whatever method are a gateway, but caution is compulsory.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why 15% of our exits are on OVH.
Yes, of course. However, you refer to the lack of diversity in operating systems, but monocultures in providers/ASNs is another danger we should be conscious of.
https://torbsd.org/oostats/relays-bw-by-asn.txt
OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters.
I completely agree.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
It would actually be very easy to find tampering within a BSD operating system. Again, you're welcome to your opinion, but this is no the first time an image has been offered to assist people within in the network, and again, with your view, let's get rid of the tor docker containers, the AWS AMIs, etc.
All hardware, all operating systems can be tampered with. From network cards to your shell. That is an accepted reality. IMHO think virtualization in the current trend is dangerous and should be avoided, from clouds to docker. It's more code to have bugs, more systems to patch and more trust to grant. But I'm not looking to debate those larger (and very real) issues. Quite bluntly, it's easier for an adversary to just provide compromised, back-doored images than to crack AES, compromise hardware, etc. By no means am I being accusatory towards you, and as I started my replies with, I think you're raising a wildly valid issue, but full systems provided by someone on a mailing list don't pass a reasonable sniff test. g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
George, I'm sorry, I didn't take your points as accusatory at all. I apologize if I came across that way. You had valid points, and after everyone on the mailing list pouncing me about these points, I can completely understand now that providing an image for production use is a bad idea. I know I've just started with the project, and I still have quite a bit to learn, so I apologize for offending anyone and stepping on any toes. Anyway, I know the BSD/Linux relay counts are totally skewed to Linux, which is why I converted all five of my exits to FreeBSD. Hopefully that helps a little. Thanks, Conrad On Sunday, February 25, 2018 4:03:00 PM CST George wrote:
Conrad Rockenhaus:
On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
My main thought process behind trying to ease the implementation of BSD relays is the fact that we should diversify what we have online within the network. Most of our nodes are Linux. What if we have another vulnerability that comes out that hits Linux specifically again?
Oh, absolutely. Completely valid and the reason for The Tor BSD Diversity Project's existence.
It's even uglier with bridges than with public relays. Our stats give daily snapshots to back your point:
https://torbsd.org/oostats.html
However, I'd be wary of an image that I didn't build myself, personally.
That's your opinion. The AWS relay project was very successful. Numerous people ran an image that they didn't build. Numerous people also run Docker containers that they didn't build. Numerous people run Vagrant boxes they didn't build. You have the right to be weary, but there's numerous people out there who run other people's images everyday.
Yes, being wary should be a guiding principle IMHO.
I'm aware of the other image-based roll-outs, but I just wanted to add a disclaiming comment.
Personally, I'm purely for bare-metal server solutions to minimize (although it doesn't eliminate) external trust. I understand that images from whatever method are a gateway, but caution is compulsory.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why 15% of our exits are on OVH.
Yes, of course. However, you refer to the lack of diversity in operating systems, but monocultures in providers/ASNs is another danger we should be conscious of.
https://torbsd.org/oostats/relays-bw-by-asn.txt
OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters.
I completely agree.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
It would actually be very easy to find tampering within a BSD operating system. Again, you're welcome to your opinion, but this is no the first time an image has been offered to assist people within in the network, and again, with your view, let's get rid of the tor docker containers, the AWS AMIs, etc. All hardware, all operating systems can be tampered with. From network cards to your shell. That is an accepted reality.
IMHO think virtualization in the current trend is dangerous and should be avoided, from clouds to docker. It's more code to have bugs, more systems to patch and more trust to grant.
But I'm not looking to debate those larger (and very real) issues.
Quite bluntly, it's easier for an adversary to just provide compromised, back-doored images than to crack AES, compromise hardware, etc. By no means am I being accusatory towards you, and as I started my replies with, I think you're raising a wildly valid issue, but full systems provided by someone on a mailing list don't pass a reasonable sniff test.
g
Conrad Rockenhaus:
George,
I'm sorry, I didn't take your points as accusatory at all. I apologize if I came across that way. You had valid points, and after everyone on the mailing list pouncing me about these points, I can completely understand now that providing an image for production use is a bad idea. I know I've just started with the project, and I still have quite a bit to learn, so I apologize for offending anyone and stepping on any toes.
Yeah, but don't stop moving. No need for apologies. The very fact that you're taking a very real question and hammering at it is a good thing.
Anyway, I know the BSD/Linux relay counts are totally skewed to Linux, which is why I converted all five of my exits to FreeBSD. Hopefully that helps a little.
As long as you're comfortable in managing FreeBSD, then great. g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
Yes, of course. However, you refer to the lack of diversity in operating systems, but monocultures in providers/ASNs is another danger we should be conscious of.
These calculation don’t show the situation as it currently really is - unfortunately: About 32 out of these https://metrics.torproject.org/rs.html#search/nifty relays seem not to get counted in ASN nor in cw-fraction (probably because as in this example https://metrics.torproject.org/rs.html#details/609E598FB6A00BCF7872906B602B7... AS Name and AS Number are unknown). But they are about 15% of total Exit https://github.com/nusenu/OrNetStats/blob/master/allexitfamilies.md - that seems kind of monocultures? Paul
No multihoming = no AS. I do not pay for things I do not really need. https://nusenu.github.io/OrNetStats/asnameshare <https://nusenu.github.io/OrNetStats/asnameshare> 0 OVH SAS 15.76 22.92 7.34 499 1 Online S.a.s. 9.6 10.1 10.59 372 2 Hetzner Online GmbH 6.37 8.89 1.93 273 3 DigitalOcean, LLC 4.47 5.79 2.3 280 My relays are #4. OVH is 4 times bigger than me... Markus
On 26. Feb 2018, at 19:06, Paul <pa011@web.de> wrote:
Yes, of course. However, you refer to the lack of diversity in operating systems, but monocultures in providers/ASNs is another danger we should be conscious of.
These calculation don’t show the situation as it currently really is - unfortunately:
About 32 out of these https://metrics.torproject.org/rs.html#search/nifty relays seem not to get counted in ASN nor in cw-fraction (probably because as in this example https://metrics.torproject.org/rs.html#details/609E598FB6A00BCF7872906B602B7... AS Name and AS Number are unknown).
But they are about 15% of total Exit https://github.com/nusenu/OrNetStats/blob/master/allexitfamilies.md - that seems kind of monocultures?
Paul <0xC8C330E7.asc>_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%. They're one of the few providers out there that allow exits. That's why 15% of our exits are on OVH.
For what it's worth, my entire OVH account was terminated as a result of hosting an exit on their VPS line, citing "hosting a proxy" as grounds for termination. They're slow to act on abuse (if you reply with *any* response it satisfies their automated system until a human looks at it), but they do not explicitly support Tor when it comes to VPS's. -- Jordan https://yui.cat/
On Sunday, February 25, 2018 4:03:30 PM CST Jordan wrote:
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why 15% of our exits are on OVH.
For what it's worth, my entire OVH account was terminated as a result of hosting an exit on their VPS line, citing "hosting a proxy" as grounds for termination. They're slow to act on abuse (if you reply with *any* response it satisfies their automated system until a human looks at it), but they do not explicitly support Tor when it comes to VPS's.
That clause is in the TOS for the VPS services but it's not in the TOS for the OpenStack Public/Private cloud services. Of course, You're paying more than $4.99/mo to run an OpenStack instance to run a Tor node.
2018-02-25 21:23 GMT+00:00 Conrad Rockenhaus <conrad@rockenhaus.com>:
On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS
image
that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
My main thought process behind trying to ease the implementation of BSD relays is the fact that we should diversify what we have online within the network. Most of our nodes are Linux. What if we have another vulnerability that comes out that hits Linux specifically again?
However, I'd be wary of an image that I didn't build myself, personally.
That's your opinion. The AWS relay project was very successful. Numerous people ran an image that they didn't build. Numerous people also run Docker containers that they didn't build. Numerous people run Vagrant boxes they didn't build. You have the right to be weary, but there's numerous people out there who run other people's images everyday.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why 15% of our exits are on OVH.
https://torbsd.org/oostats/relays-bw-by-asn.txt
OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters.
I completely agree.
I wonder if people hosting Tor relays in any sort of VPS are doing filesystem encryption.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
you can combine the FreeBSD jails feature with your idea. plus, do not share many Tor instances on the same machine/server/jail.
It would actually be very easy to find tampering within a BSD operating system. Again, you're welcome to your opinion, but this is no the first time an image has been offered to assist people within in the network, and again, with your view, let's get rid of the tor docker containers, the AWS AMIs, etc.
Regards,
Conrad
http://wiki.torbsd.org/doku.php?id=en:bsd-vps
g
-- Vinícius Zavam keybase.io/egypcio/key.asc
On Monday, February 26, 2018 11:24:37 AM CST Vinícius Zavam wrote:
2018-02-25 21:23 GMT+00:00 Conrad Rockenhaus <conrad@rockenhaus.com>:
On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS
image
that is fully configured and ready to run Tor. Right now it's an
eight GB
image, but I'm reducing the size by removing all of the extra stuff
on it
from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
My main thought process behind trying to ease the implementation of BSD
relays
is the fact that we should diversify what we have online within the
network.
Most of our nodes are Linux. What if we have another vulnerability that
comes
out that hits Linux specifically again?
However, I'd be wary of an image that I didn't build myself, personally.
That's your opinion. The AWS relay project was very successful. Numerous people ran an image that they didn't build. Numerous people also run
Docker
containers that they didn't build. Numerous people run Vagrant boxes they didn't build. You have the right to be weary, but there's numerous people
out
there who run other people's images everyday.
If you're interested in the image let me know. This image has been
fully
tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why
15% of
our exits are on OVH.
https://torbsd.org/oostats/relays-bw-by-asn.txt
OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters.
I completely agree.
I wonder if people hosting Tor relays in any sort of VPS are doing filesystem encryption.
I can tell you on OVH, a basic level VPS (one for $5.00/mo) is not encrypted. If a customer is willing to spend $7.00/mo more for an additional partition, they will be able to have storage to encrypt the the Tor relay information at rest. On the Cloud side, you encrypt the primary volume, so all storage is encrypted at rest. I can't speak of any of the other providers that provide BSD VPSes or BSD Cloud Instances.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
you can combine the FreeBSD jails feature with your idea. plus, do not share many Tor instances on the same machine/server/jail.
What my plan is to utilize the official FreeBSD Virtual Machine Images from their site and build on top of them with my Ansible Scripts. I should hopefully have a beta released next week that we can start hacking on.
It would actually be very easy to find tampering within a BSD operating
system.
Again, you're welcome to your opinion, but this is no the first time an
image
has been offered to assist people within in the network, and again, with
your
view, let's get rid of the tor docker containers, the AWS AMIs, etc.
Regards,
Conrad
http://wiki.torbsd.org/doku.php?id=en:bsd-vps
g
-- Vinícius Zavam keybase.io/egypcio/key.asc
Why would it be important to encrypt the storage of your tor server? For me this looks like it only complicates things if law enforcement wants to take a look at your server and the cloud provider should be able to break the encryption relative easy or can simply take a memory dump On 26 February 2018 11:27 PM, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
snip
I wonder if people hosting Tor relays in any sort of VPS are doing
filesystem encryption.
I can tell you on OVH, a basic level VPS (one for $5.00/mo) is not encrypted.
If a customer is willing to spend $7.00/mo more for an additional partition,
they will be able to have storage to encrypt the the Tor relay information at
rest.
On the Cloud side, you encrypt the primary volume, so all storage is encrypted
at rest.
I can't speak of any of the other providers that provide BSD VPSes or BSD
Cloud Instances.
On Tue, Feb 27, 2018 at 12:09:36PM -0500, Otheontelth wrote:
Why would it be important to encrypt the storage of your tor server? For me this looks like it only complicates things if law enforcement wants to take a look at your server and the cloud provider should be able to break the encryption relative easy or can simply take a memory dump
I think there's a good argument for not using disk encryption for your relay, especially for your exit relay. The reasoning is that if some law enforcement group shows up to steal your computer, everything will go more smoothly if it's easy for them to conclude that there's no useful evidence on the disk. In that scenario, an encrypted disk means a much longer wait before they move on from thinking you're the bad person. (I'd say "a much longer wait before they give your hardware back", but while that's probably true too, it's hard to imagine a scenario where they steal your computer for a while, and then give it back, and you still want to trust it for running a relay or doing anything else interesting.) Capturing the on-disk keys from a relay will let them impersonate the relay in the future, but it shouldn't help them with decrypting past circuits or with deanonymizing what people did in the past: https://www.torproject.org/docs/faq#KeyManagement For those developer types wanting to help out here, check out this ticket: https://trac.torproject.org/13705 "Allow relays to promise in their descriptor that their IP address won't change" which would make it so people who steal the keys for large stable guards can't just put them back online somewhere else and have clients resume connecting to them. For other context, see also the "what if a bad guy runs a Tor exit relay to provide plausible deniability" paragraph in https://blog.torproject.org/trip-report-tor-trainings-dutch-and-belgian-poli... Apparently the link from my blog post, to https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines no longer has any mention pro or con disk encryption. I wonder if that was intentionally removed by the torservers.net folks (maybe they have even changed their mind on the advice?), or if it just fell out because it's a wiki. --Roger
Roger Dingledine:
Capturing the on-disk keys from a relay will let them impersonate the relay in the future
To limit possibility to impersonate a relay in the future, operators can run in OfflineMasterKey mode with a short SigningKeyLifetime (i.e. 5 days) and push key material via SSH to the relay. This will limit the ability of an attacker to impersonate the relays to 5 days in the worst case, iff the attacker does not also compromise the host storing the Ed25519 master keys. And if you actually want to do it: ansible-relayor does it by default (with 30 days SigningKeyLifetime). -- https://mastodon.social/@nusenu twitter: @nusenu_
On 03.03.2018 07:11, Roger Dingledine wrote:
Apparently the link from my blog post, to https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines no longer has any mention pro or con disk encryption. I wonder if that was intentionally removed by the torservers.net folks (maybe they have even changed their mind on the advice?), or if it just fell out because it's a wiki.
I added the recommendation for "no disk encryption" back then, and it wasn't me who removed it. My own opinion has changed slightly: My general advice would still be to not do disk encryption, to reduce the amount of hassle and allow easier 'audits'. For additional protection, you better move the relay keys to a RAM disk. However, in our case, we don't really care how long they keep the machines for analysis, and we do not reuse hardware that was seized (it goes back into the provider pool, so some other customer might be in for a surprise...). In that case, a relay operator may decide to use disk encryption for integrity reasons: They at least have to ask you for the decryption key and cannot silently copy content or easily manipulate the file system. -- Moritz Bartl https://www.torservers.net/
On 03/03/2018 04:27 AM, Moritz Bartl wrote:
On 03.03.2018 07:11, Roger Dingledine wrote:
Apparently the link from my blog post, to https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines no longer has any mention pro or con disk encryption. I wonder if that was intentionally removed by the torservers.net folks (maybe they have even changed their mind on the advice?), or if it just fell out because it's a wiki. I added the recommendation for "no disk encryption" back then, and it wasn't me who removed it.
My own opinion has changed slightly: My general advice would still be to not do disk encryption, to reduce the amount of hassle and allow easier 'audits'. For additional protection, you better move the relay keys to a RAM disk.
However, in our case, we don't really care how long they keep the machines for analysis, and we do not reuse hardware that was seized (it goes back into the provider pool, so some other customer might be in for a surprise...). In that case, a relay operator may decide to use disk encryption for integrity reasons: They at least have to ask you for the decryption key and cannot silently copy content or easily manipulate the file system.
Personally, I think entire disk encryption just to protect the keys is way too much of a hassle. I completely agree with your solution - place the keys in a ramdisk, that's actually a great idea. I'll put that into what I'm building up right now. Regards, Conrad Rockenhaus
2018-03-03 10:27 GMT+00:00 Moritz Bartl <moritz@torservers.net>:
On 03.03.2018 07:11, Roger Dingledine wrote:
Apparently the link from my blog post, to https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines no longer has any mention pro or con disk encryption. I wonder if that was intentionally removed by the torservers.net folks (maybe they have even changed their mind on the advice?), or if it just fell out because it's a wiki.
I added the recommendation for "no disk encryption" back then, and it wasn't me who removed it.
My own opinion has changed slightly: My general advice would still be to not do disk encryption, to reduce the amount of hassle and allow easier 'audits'. For additional protection, you better move the relay keys to a RAM disk.
However, in our case, we don't really care how long they keep the machines for analysis, and we do not reuse hardware that was seized (it goes back into the provider pool, so some other customer might be in for a surprise...). In that case, a relay operator may decide to use disk encryption for integrity reasons: They at least have to ask you for the decryption key and cannot silently copy content or easily manipulate the file system.
-- Moritz Bartl https://www.torservers.net/
cool. thank you all for your words+thoughts+considerations. very appreciated! -- Vinícius Zavam keybase.io/egypcio/key.asc
Moritz Bartl:
On 03.03.2018 07:11, Roger Dingledine wrote:
Apparently the link from my blog post, to https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines no longer has any mention pro or con disk encryption. I wonder if that was intentionally removed by the torservers.net folks (maybe they have even changed their mind on the advice?), or if it just fell out because it's a wiki.
I added the recommendation for "no disk encryption" back then, and it wasn't me who removed it.
This was my mistake in an edit on 2018-01-12 [1], I fixed/restored it now [2]. Is the information about "contact us at support@torservers.net" and the XMPP chat still valid?
My own opinion has changed slightly: My general advice would still be to not do disk encryption, to reduce the amount of hassle and allow easier 'audits'. For additional protection, you better move the relay keys to a RAM disk.
Also consider OfflineMasterKeys. [1] https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines?action=d... [2] https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines?sfp_emai... -- https://mastodon.social/@nusenu twitter: @nusenu_
I can tell you on OVH, a basic level VPS (one for $5.00/mo) is not encrypted. If a customer is willing to spend $7.00/mo more for an additional partition, they will be able to have storage to encrypt the the Tor relay information at rest.
If ovh vps gives root, bypass the fee with: md(4) vnode > geli > mount. Then again, if the iron isn't dipped in epoxy (not done), in your own secure datacenter (not extant), on trusted #OpenHW (not AMD / Intel / or any other to date), built in trusted #OpenFabs (non extant), running validated #OpenSW (non extant), in a voluntarist libertarian environment free from force, one's use case might be moot.
On Tue, 27 Feb 2018 14:47:06 -0500 grarpamp <grarpamp@gmail.com> allegedly wrote:
If ovh vps gives root, bypass the fee with: md(4) vnode > geli > mount.
Then again, if the iron isn't dipped in epoxy (not done), in your own secure datacenter (not extant), on trusted #OpenHW (not AMD / Intel / or any other to date), built in trusted #OpenFabs (non extant), running validated #OpenSW (non extant), in a voluntarist libertarian environment free from force, one's use case might be moot.
Gotta love you Grarpamp. :-) But in the real world we /have/ to trust someone, somewhere, somehow, sometime. What everyone has to decide for themselves is /how much/ trust to give, to whom, when, where and why. And that depends entirely on your threat model and your appetite for risk. Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net/about-trivia ---------------------------------------------------------------------
On Wed, Feb 28, 2018 at 6:38 PM mick <mbm@rlogin.net> wrote:
But in the real world we /have/ to trust someone, somewhere, somehow, sometime. What everyone has to decide for themselves is /how much/ trust to give, to whom, when, where and why. And that depends entirely on your threat model and your appetite for risk.
Mick
well sed -- 0101100101000001010010000101010101000001010010000010000001000010 0100110001000101010100110101001100100000010110010100111101010101
On Wed, Feb 28, 2018 at 10:43 AM, mick <mbm@rlogin.net> wrote:
On Tue, 27 Feb 2018 14:47:06 -0500 grarpamp <grarpamp@gmail.com> allegedly wrote:
If ovh vps gives root, bypass the fee with: md(4) vnode > geli > mount.
Then again, if the iron isn't dipped in epoxy (not done), in your own secure datacenter (not extant), on trusted #OpenHW (not AMD / Intel / or any other to date), built in trusted #OpenFabs (non extant), running validated #OpenSW (non extant), in a voluntarist libertarian environment free from force, one's use case might be moot.
Gotta love you Grarpamp. :-)
But in the real world we /have/ to trust someone, somewhere, somehow, sometime. What everyone has to decide for themselves is /how much/ trust to give, to whom, when, where and why. And that depends entirely on your threat model and your appetite for risk.
Sorry, but with decades of both plausible and exploited risk extant, with however many million millionaires and significant billionaires, and crowdfunding (further enhanced by the dawn of cryptocurrency and all its new models that can be brought to bear)... there is no rational reason to continue this global head in sand downplay and refusal to get moving and start building #OpenHW in #OpenFabs. The old goalpost of who, where, how, when, and how much open and even explicitly proven trust exists in HW / Fabs simply must start shifting for the better until it becomes the new "real world". Further, such trust is profitable business model. If kids can build home semiconductor labs making open IC's, you can bet the above sponsors with those visionaries can easily scale beyond a billion gates. https://www.youtube.com/results?search_query=home+semiconductor+fab (Obligatory credit given to #OpenSW for at least being opensource, but they're hardly under open validation programs yet either.)
grarpamp:
On Wed, Feb 28, 2018 at 10:43 AM, mick <mbm@rlogin.net> wrote:
On Tue, 27 Feb 2018 14:47:06 -0500 grarpamp <grarpamp@gmail.com> allegedly wrote:
If ovh vps gives root, bypass the fee with: md(4) vnode > geli > mount.
Then again, if the iron isn't dipped in epoxy (not done), in your own secure datacenter (not extant), on trusted #OpenHW (not AMD / Intel / or any other to date), built in trusted #OpenFabs (non extant), running validated #OpenSW (non extant), in a voluntarist libertarian environment free from force, one's use case might be moot.
Gotta love you Grarpamp. :-)
But in the real world we /have/ to trust someone, somewhere, somehow, sometime. What everyone has to decide for themselves is /how much/ trust to give, to whom, when, where and why. And that depends entirely on your threat model and your appetite for risk.
Sorry, but with decades of both plausible and exploited risk extant, with however many million millionaires and significant billionaires, and crowdfunding (further enhanced by the dawn of cryptocurrency and all its new models that can be brought to bear)... there is no rational reason to continue this global head in sand downplay and refusal to get moving and start building #OpenHW in #OpenFabs. The old goalpost of who, where, how, when, and how much open and even explicitly proven trust exists in HW / Fabs simply must start shifting for the better until it becomes the new "real world". Further, such trust is profitable business model.
If kids can build home semiconductor labs making open IC's, you can bet the above sponsors with those visionaries can easily scale beyond a billion gates.
https://www.youtube.com/results?search_query=home+semiconductor+fab
(Obligatory credit given to #OpenSW for at least being opensource, but they're hardly under open validation programs yet either.)
Yes, and while grarpamp digs down to undercut abstractions, others build up and up with more virtualization as a security feature. Note that I'm not referring to just using VPS', which for many is an easy and necessary gateway to running Tor nodes. Build a system on top of another system and you have more systems to trust, more to patch. More systems doesn't mean more security. And that Intel "quirk" now impacts more systems. Ultimately more code translates into more bugs. Yes, a bit of a rant, but also an opportunity to strongly counter the privacy-enhancing technology community over the past few years that stacking systems with virtualization is somehow a security enhancement. g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
Vinícius Zavam:
2018-02-25 21:23 GMT+00:00 Conrad Rockenhaus <conrad@rockenhaus.com>:
On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS
image
that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
My main thought process behind trying to ease the implementation of BSD relays is the fact that we should diversify what we have online within the network. Most of our nodes are Linux. What if we have another vulnerability that comes out that hits Linux specifically again?
However, I'd be wary of an image that I didn't build myself, personally.
That's your opinion. The AWS relay project was very successful. Numerous people ran an image that they didn't build. Numerous people also run Docker containers that they didn't build. Numerous people run Vagrant boxes they didn't build. You have the right to be weary, but there's numerous people out there who run other people's images everyday.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why 15% of our exits are on OVH.
https://torbsd.org/oostats/relays-bw-by-asn.txt
OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters.
I completely agree.
I wonder if people hosting Tor relays in any sort of VPS are doing filesystem encryption.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
you can combine the FreeBSD jails feature with your idea. plus, do not share many Tor instances on the same machine/server/jail.
Actually, that raises a side point... FreeBSD jails are usually viewed as a tool to create full system with the glorious addition of root. But they can also be used to build minimal chroot-looking systems, in that they can be deliciously small, yet incredibly secure, especially compared to chroot. FreeBSD jails started as a simple http hosting solution a long while back, very much a "unorthodox solution to a traditional problem." But they have a utility that gets confused when they are considered just-another-virtualization alternative to delude users into thinking they have full system control. <snip> g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
On Wednesday, February 28, 2018 6:46:00 PM CST George wrote:
Vinícius Zavam:
2018-02-25 21:23 GMT+00:00 Conrad Rockenhaus <conrad@rockenhaus.com>:
On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS
image
that is fully configured and ready to run Tor. Right now it's an
eight GB
image, but I'm reducing the size by removing all of the extra stuff
on it
from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
My main thought process behind trying to ease the implementation of BSD
relays
is the fact that we should diversify what we have online within the
network.
Most of our nodes are Linux. What if we have another vulnerability that
comes
out that hits Linux specifically again?
However, I'd be wary of an image that I didn't build myself, personally.
That's your opinion. The AWS relay project was very successful. Numerous people ran an image that they didn't build. Numerous people also run
Docker
containers that they didn't build. Numerous people run Vagrant boxes they didn't build. You have the right to be weary, but there's numerous people
out
there who run other people's images everyday.
If you're interested in the image let me know. This image has been
fully
tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why
15% of
our exits are on OVH.
https://torbsd.org/oostats/relays-bw-by-asn.txt
OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters.
I completely agree.
I wonder if people hosting Tor relays in any sort of VPS are doing filesystem encryption.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
you can combine the FreeBSD jails feature with your idea. plus, do not share many Tor instances on the same machine/server/jail.
Actually, that raises a side point...
FreeBSD jails are usually viewed as a tool to create full system with the glorious addition of root.
But they can also be used to build minimal chroot-looking systems, in that they can be deliciously small, yet incredibly secure, especially compared to chroot.
FreeBSD jails started as a simple http hosting solution a long while back, very much a "unorthodox solution to a traditional problem." But they have a utility that gets confused when they are considered just-another-virtualization alternative to delude users into thinking they have full system control.
<snip>
g
We could always make it more fun and throw FreeBSD/Docker on top of the mess: https://wiki.freebsd.org/Docker I was looking at Jails before, but I ruled it out because I'm looking at this project from the level of I'm running a VM on a OpenStack/VMware, or AWS infrastructure as a small VM dedicated to just Tor. So the who VM is dedicated to just Tor. So, basically instead of virtualizing an environment already running in a virtual machine dedicated to the task of running that run task, I figured just keep things on the VM. Of course, I may be looking at that wrong, but I think that would be the best option to weigh all of the factors that go into the project. Conrad
2018-03-01 0:46 GMT+00:00 George <george@queair.net>:
Vinícius Zavam:
2018-02-25 21:23 GMT+00:00 Conrad Rockenhaus <conrad@rockenhaus.com>:
On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS
image
that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
My main thought process behind trying to ease the implementation of BSD relays is the fact that we should diversify what we have online within the network. Most of our nodes are Linux. What if we have another vulnerability that comes out that hits Linux specifically again?
However, I'd be wary of an image that I didn't build myself,
personally.
That's your opinion. The AWS relay project was very successful. Numerous people ran an image that they didn't build. Numerous people also run Docker containers that they didn't build. Numerous people run Vagrant boxes they didn't build. You have the right to be weary, but there's numerous people out there who run other people's images everyday.
If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth).
Another issue is that OVH is over relied upon for public nodes. It's the leading ASN with almost 15%.
They're one of the few providers out there that allow exits. That's why 15% of our exits are on OVH.
https://torbsd.org/oostats/relays-bw-by-asn.txt
OTOH, I do think we (in particular BSD people) need to facilitate the implementation of BSD relays, including for VPS services for those looking to test the waters.
I completely agree.
I wonder if people hosting Tor relays in any sort of VPS are doing filesystem encryption.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's
scripts
that can be reviewed and hacked is a better gateway for new relay operators than images.
you can combine the FreeBSD jails feature with your idea. plus, do not share many Tor instances on the same machine/server/jail.
Actually, that raises a side point...
FreeBSD jails are usually viewed as a tool to create full system with the glorious addition of root.
But they can also be used to build minimal chroot-looking systems, in that they can be deliciously small, yet incredibly secure, especially compared to chroot.
FreeBSD jails started as a simple http hosting solution a long while back, very much a "unorthodox solution to a traditional problem." But they have a utility that gets confused when they are considered just-another-virtualization alternative to delude users into thinking they have full system control.
<snip>
g
--
34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
we can also use jails to run "qemu-based environments" and be able to use/test Tor (in this case) in many different architectures; a particular case may also involve a FreeBSD "qemu-jail", Tor and BuildBot -- Vinícius Zavam keybase.io/egypcio/key.asc
On Sun, Feb 25, 2018 at 09:05:00PM +0000, George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
However, I'd be wary of an image that I didn't build myself, personally.
I agree with that sentiment. I would rather Tor relay operators set up their systems themselves so that they know how that system is configured. I would also suggest users run operating systems that specialize in security, like OpenBSD or HardenedBSD. Running Tor on FreeBSD opens the door to mass exploitation via copy and paste style exploits. I would caution against such setups. Tor has a very unique threat landscape and the security of the relay should be of upmost importance.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
Agreed. Not only does the Tor network need to be diversified with regards to operating system, but it also needs to be diversified with regards to hosting providers. Tor needs to be resilient against any and all attacks. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
Wow, I didn't expect my friendly gesture to start another debate, but the reasoning behind offering this image was mainly for people who were operating on OpenStack clouds who wanted to upload the image to their infrastructure using glance and start things up quickly. I'm more than willing to provide the ansible scripts I use to initially spin things up, once I clean things up since there's still some manual things that can be automated. I'll just consider this idea dead in the water. That being said: On Sunday, February 25, 2018 3:50:44 PM CST Shawn Webb wrote:
On Sun, Feb 25, 2018 at 09:05:00PM +0000, George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
However, I'd be wary of an image that I didn't build myself, personally.
I agree with that sentiment. I would rather Tor relay operators set up their systems themselves so that they know how that system is configured.
I would also suggest users run operating systems that specialize in security, like OpenBSD or HardenedBSD. Running Tor on FreeBSD opens the door to mass exploitation via copy and paste style exploits. I would caution against such setups. Tor has a very unique threat landscape and the security of the relay should be of upmost importance.
I'll be honest, I have never heard of a copy and paste style exploit. What is it? Could you provide me a link with info about it, because I run several FreeBSD instances and if I have a ticking timebomb on my hands, I need to fix it.
The TDP wiki has a list of other BSD-offering VPSs, plus a script for Vultur to build on OpenBSD. I tend to think using other people's scripts that can be reviewed and hacked is a better gateway for new relay operators than images.
Agreed. Not only does the Tor network need to be diversified with regards to operating system, but it also needs to be diversified with regards to hosting providers. Tor needs to be resilient against any and all attacks.
Thanks,
Thanks, Conrad
On Sun, Feb 25, 2018 at 04:03:49PM -0600, Conrad Rockenhaus wrote:
Wow, I didn't expect my friendly gesture to start another debate, but the reasoning behind offering this image was mainly for people who were operating on OpenStack clouds who wanted to upload the image to their infrastructure using glance and start things up quickly. I'm more than willing to provide the ansible scripts I use to initially spin things up, once I clean things up since there's still some manual things that can be automated.
I'll just consider this idea dead in the water. That being said:
On Sunday, February 25, 2018 3:50:44 PM CST Shawn Webb wrote:
On Sun, Feb 25, 2018 at 09:05:00PM +0000, George wrote:
Conrad Rockenhaus:
Hello All,
If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1.
I think it's great to ease the implementation of Tor relays, particularly on BSDs.
However, I'd be wary of an image that I didn't build myself, personally.
I agree with that sentiment. I would rather Tor relay operators set up their systems themselves so that they know how that system is configured.
I would also suggest users run operating systems that specialize in security, like OpenBSD or HardenedBSD. Running Tor on FreeBSD opens the door to mass exploitation via copy and paste style exploits. I would caution against such setups. Tor has a very unique threat landscape and the security of the relay should be of upmost importance.
I'll be honest, I have never heard of a copy and paste style exploit. What is it? Could you provide me a link with info about it, because I run several FreeBSD instances and if I have a ticking timebomb on my hands, I need to fix it.
With FreeBSD's complete lack of exploit mitigations, all tor instances running on like FreeBSD systems can be exploited the same way. The memory layout is predictable, memory mappings can be writable and executable, etc. The virtual memory layout of tor on your FreeBSD 11.1-RELEASE-p6 instance is going to be the exact same as John Smith's instance. This means that attackers can write their exploits with 100% reliability, even with virtual memory addresses hardcoded. There's no need for ROP, JOP, SROP, etc. on FreeBSD. FreeBSD is literally stuck in 1999-era security. Writing exploits for such systems is extremely easy for today's offensive security researchers. FreeBSD really needs ASLR and W^X, at a minimum, for me to put even the slightest trust in for applications that are security-sensitive (like tor). Until then, I'd encourage Tor relay operators to make use of operating systems that put a focus on security, like OpenBSD or HardenedBSD. Just yesterday, I was notified of yet another FreeBSD box getting popped by an offensive security researcher. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
Conrad Rockenhaus:
I'm more than willing to provide the ansible scripts I use to initially spin things up
looking forward to it -- https://mastodon.social/@nusenu twitter: @nusenu_
On Sun, Feb 25, 2018 at 4:05 PM, George <george@queair.net> wrote:
However, I'd be wary of an image that I didn't build myself, personally.
Yes, especially of image without source [script] (not to diminish such work). FreeBSD is largely reproducible these days, OpenBSD maybe not yet (you'd have to test it). In general, if anyone wants to offer an image, they really should also be posting the latest release from the vendor, then a diff script that recreates the image, including overlay network bits, etc. To the user, it's the same choice as using a prebuilt binary, or the sourcecode. That routes around any remaining reproducibility issues in the base OS. FreeBSD and OpenBSD are trivial to install a well outfitted box by script. And if you can't script it, you're not doing it right, try again.
On Sunday, February 25, 2018 11:13:12 PM CST grarpamp wrote:
On Sun, Feb 25, 2018 at 4:05 PM, George <george@queair.net> wrote:
However, I'd be wary of an image that I didn't build myself, personally.
Yes, especially of image without source [script] (not to diminish such work).
FreeBSD is largely reproducible these days, OpenBSD maybe not yet (you'd have to test it).
In general, if anyone wants to offer an image, they really should also be posting the latest release from the vendor, then a diff script that recreates the image, including overlay network bits, etc. To the user, it's the same choice as using a prebuilt binary, or the sourcecode.
That routes around any remaining reproducibility issues in the base OS.
FreeBSD and OpenBSD are trivial to install a well outfitted box by script. And if you can't script it, you're not doing it right, try again. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I'm more than willing to offer source :D, but I'm just going to make it a script only project instead based on what seems to be the consensus opinion. I'm just going to clean up some small things now that could be automated that I was doing by hand prior to releasing it for review/comments.
On Mon, Feb 26, 2018 at 12:21 AM, Conrad Rockenhaus <conrad@rockenhaus.com> wrote:
I'm more than willing to offer source :D, but I'm just going to make it a script only project instead based on what seems to be the consensus opinion. I'm just going to clean up some small things now that could be automated that I was doing by hand prior to releasing it for review/comments.
Both image and script seem viable. Image for the "tryers". Script for the "serious". For whatever those mean. Script probably gets you more detailed step by step feedback.
please ensure the tor keys folder is empty in your image and SSH hostkeys are also not there (generated on first boot) -- https://mastodon.social/@nusenu twitter: @nusenu_
On Sunday, February 25, 2018 3:08:00 PM CST nusenu wrote:
please ensure the tor keys folder is empty in your image
and SSH hostkeys are also not there (generated on first boot)
It's completely clean. It's a completely default install of tor with no keys generated, waiting for it's first start after configuration, and the ssh keys have been removed. The only difference is rc.conf and sysctl.conf have been properly configured to allow tor to run.
participants (15)
-
Conrad Rockenhaus -
George -
grarpamp -
Jordan -
mick -
Moritz Bartl -
niftybunny -
nusenu -
Otheontelth -
Paul -
Quintin -
Roger Dingledine -
Shawn Webb -
TorGate -
Vinícius Zavam