Combined relay and hidden service, good idea or not?
When operating a hidden service and a relay in one tor instance, tor currently warns: [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742 First, that issue has been fixed and closed. Second, I had read in the past opinions stating: When operating a hidden service, running a relay helps mix traffic so that anyone observing traffic from the machine cannot easily run an analysis targeted at a hidden service that might exist on that machine. The text of the startup warning seems to contradict that belief. Is there more to know, or is the warning only applicable to the now-closed information leak? Can someone kindly clarify the current best practice in this regard and address whether or not that warning should be removed from tor's startup diagnostics?
It is safe to assume that both relays and select hidden services are being scanned 24/7. When your host reboots (say, as a result of an automatic OS update), both your relay and your hidden service become unavailable at the same time, instantly revealing the IP of the hidden service. On Thu, Jan 4, 2018 at 7:08 PM, <tortilla@mantablue.com> wrote:
When operating a hidden service and a relay in one tor instance, tor currently warns:
[warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742
First, that issue has been fixed and closed.
Second, I had read in the past opinions stating:
When operating a hidden service, running a relay helps mix traffic so that anyone observing traffic from the machine cannot easily run an analysis targeted at a hidden service that might exist on that machine.
The text of the startup warning seems to contradict that belief. Is there more to know, or is the warning only applicable to the now-closed information leak?
Can someone kindly clarify the current best practice in this regard and address whether or not that warning should be removed from tor's startup diagnostics?
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hey, On 2018-01-05 04:08, tortilla@mantablue.com wrote:
When operating a hidden service and a relay in one tor instance, tor currently warns:
[warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742
First, that issue has been fixed and closed.
The issue is fixed by adding the above warning message: if you care about your hidden service's "hidden" property, do not run a relay on the same process.
Second, I had read in the past opinions stating:
When operating a hidden service, running a relay helps mix traffic so that anyone observing traffic from the machine cannot easily run an analysis targeted at a hidden service that might exist on that machine.
The part "cannot easily run an analysis targeted at a hidden service" looks just wrong to me. If you want an example of an active attacker able to easily uncover such a hidden service (when mixed with a relay), you can give a look at our paper "Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols" [1] (to appear in PoPETs18). The techniques presented are not applied on that particular setup, but this is somewhat trivial to do. Best, Florentin [1] https://uclouvain.be/crypto/people/show/462
When operating a hidden service and a relay in one tor instance, tor currently warns:
[warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742
First, that issue has been fixed and closed.
The issue is fixed by adding the above warning message: if you care about your hidden service's "hidden" property, do not run a relay on the same process.
Would you mind elaborating? As I read the tracker link, the issue was an informational leak in bandwidth reporting that has now been solved and closed. As such, the startup warning is misleading unless there are other concerns (such as Igor's below) and in which case, the warning should be re-worded. Why do you say it is *fixed* by adding a warning? Igor's point:
It is safe to assume that both relays and select hidden services are being scanned 24/7. When your host reboots (say, as a result of an automatic OS update), both your relay and your hidden service become unavailable at the same time, instantly revealing the IP of the hidden service.
This seems crucial, unless an operator somehow schedules random downtime for the relay or hidden service so that coinciding downtime can't be as easily correlated.
Second, I had read in the past opinions stating:
When operating a hidden service, running a relay helps mix traffic so that anyone observing traffic from the machine cannot easily run an analysis targeted at a hidden service that might exist on that machine.
The part "cannot easily run an analysis targeted at a hidden service" looks just wrong to me. If you want an example of an active attacker able to easily uncover such a hidden service (when mixed with a relay), you can give a look at our paper "Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols" [1] (to appear in PoPETs18). The techniques presented are not applied on that particular setup, but this is somewhat trivial to do.
I believe the logic was that if a machine is identified in some way as one to watch, and if it is seen participating in the Tor network but is not listed as a public relay, it's easier to conclude that it may be hosting a hidden service, after which other correlation attacks can be targeted at the machine. Thus, the recommendation that running a public relay helps mask HS traffic. Perhaps in the case that the HS operator is not trying to mask the HS location, the act of mixing public relay traffic can be nothing but a *help* to defeat anyone trying to correlate traffic coming to the HS with traffic emanating from any one client. Forgive me for only skimming your paper, but I didn't see any explanation that the attack outlined was either facilitated or enhanced by the HS also running a relay. Would you mind commenting?
Hey Tortilla, Sorry for the late reply: On 2018-01-05 21:13, Tortilla wrote:
The issue is fixed by adding the above warning message: if you care about your hidden service's "hidden" property, do not run a relay on the same process. Would you mind elaborating? As I read the tracker link, the issue was an informational leak in bandwidth reporting that has now been solved and closed. As such, the startup warning is misleading unless there are other concerns (such as Igor's below) and in which case, the warning should be re-worded. Why do you say it is *fixed* by adding a warning?
https://trac.torproject.org/8742 issue is already a stronger concern than Igor's point, and there are more. The informational leak in bandwidth is still there today, since these measurements are public. The issue is marked as fixed because, if you do relay+HS, you got a warning "not secure" that links to a possible attack (#8742) to recover your HS's location. To be honest, I don't really get why you feel that the startup warning is misleading. Is it because it links a fixed and closed trac issue?
<skip>
The part "cannot easily run an analysis targeted at a hidden service" looks just wrong to me. If you want an example of an active attacker able to easily uncover such a hidden service (when mixed with a relay), you can give a look at our paper "Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols" [1] (to appear in PoPETs18). The techniques presented are not applied on that particular setup, but this is somewhat trivial to do. I believe the logic was that if a machine is identified in some way as one to watch, and if it is seen participating in the Tor network but is not listed as a public relay, it's easier to conclude that it may be hosting a hidden service, after which other correlation attacks can be targeted at the machine. Thus, the recommendation that running a public relay helps mask HS traffic.
Perhaps in the case that the HS operator is not trying to mask the HS location, the act of mixing public relay traffic can be nothing but a *help* to defeat anyone trying to correlate traffic coming to the HS with traffic emanating from any one client.
Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed.
Forgive me for only skimming your paper, but I didn't see any explanation that the attack outlined was either facilitated or enhanced by the HS also running a relay. Would you mind commenting?
Ok, so suppose a public relay and a hidden service running on the same process, and the attacker knows the onion address. The hidden service's location can be uncovered using public bandwidth leaks of the relay. Just do the following trick: send a few GB of trash data to the hidden service using the kind of method described in the paper. Then, wait that the public measurements are updated and look for the relay having a few more GB of read data than write data. You should obtain only one IP. Congrats, it's the IP of the hidden service. So, if you care about your HS's hidden location, do not run a relay on the same process :-) Best, Florentin
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2018-01-08 03:21, Florentin Rochet wrote:
Perhaps in the case that the HS operator is not trying to mask the HS location, the act of mixing public relay traffic can be nothing but a *help* to defeat anyone trying to correlate traffic coming to the HS with traffic emanating from any one client.
Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed.
Indeed. I run some public resources (e.g. torproject.org mirror) on a public URL with a .onion site as well. Nothing is intended to be hidden, I simply want the content of anything I mirror to be available to Tor users without relying on an exit. After an "abuse" report warning me that my hidden site is "leaking" its location, my root robots.txt and a separate README file now both display the public and .onion addresses with a note that nothing is intended to be hidden. (I also appreciate the individual who sent the warning!) On the flip side, to a new/naive hidden service operator the warning could be useful as it may not be immediately obvious to someone just dipping their toes in Tor as to why and how this configuration might reveal their hidden service's real physical location. I avidly dislike warnings appearing in my logs that I intend to ignore, I would prefer to see this be controlled by a preference in torrc, either by an option to disable the warning, or better, require an explicit switch to be set before tor will act as both a relay and a hidden service. By making a "allow both HS and relay function" switch that is disabled by default, we could place appropriate comments in the default torrc file which explain the risks. Whether any of this really matters in the real world, I don't know, but getting the attention of an inexperienced operator before they make a privacy-reducing mistake seems like A Good Thing.
On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
On 2018-01-08 03:21, Florentin Rochet wrote:
Perhaps in the case that the HS operator is not trying to mask the HS location, the act of mixing public relay traffic can be nothing but a *help* to defeat anyone trying to correlate traffic coming to the HS with traffic emanating from any one client.
Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed.
Indeed. I run some public resources (e.g. torproject.org mirror) on a public URL with a .onion site as well. Nothing is intended to be hidden, I simply want the content of anything I mirror to be available to Tor users without relying on an exit.
After an "abuse" report warning me that my hidden site is "leaking" its location, my root robots.txt and a separate README file now both display the public and .onion addresses with a note that nothing is intended to be hidden. (I also appreciate the individual who sent the warning!)
On the flip side, to a new/naive hidden service operator the warning could be useful as it may not be immediately obvious to someone just dipping their toes in Tor as to why and how this configuration might reveal their hidden service's real physical location.
Certainly! I'm not new to Tor/HS and still got tripped up by this, especially seeing the issue as having been closed, not having realized it has not in fact been "fixed" and the only thing done was to add a startup warning. The issue really should be re-opened. It's not unreasonable to conclude that if the issue linked in the warning is closed that the warning is obsolete.
I avidly dislike warnings appearing in my logs that I intend to ignore, I would prefer to see this be controlled by a preference in torrc, either by an option to disable the warning, or better, require an explicit switch to be set before tor will act as both a relay and a hidden service. By making a "allow both HS and relay function" switch that is disabled by default, we could place appropriate comments in the default torrc file which explain the risks.
Absolutely agree -- at least if the intention is not to fix the information leak. Less careful HS operators may never even see the warning. Tor should probably refuse to start without explicit permission to act as a relay while hosting a HS.
On 2018-01-08 14:09, Tortilla wrote:
On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
On 2018-01-08 03:21, Florentin Rochet wrote:
Perhaps in the case that the HS operator is not trying to mask the HS location, the act of mixing public relay traffic can be nothing but a *help* to defeat anyone trying to correlate traffic coming to the HS with traffic emanating from any one client.
Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed.
Indeed. I run some public resources (e.g. torproject.org mirror) on a public URL with a .onion site as well. Nothing is intended to be hidden, I simply want the content of anything I mirror to be available to Tor users without relying on an exit.
After an "abuse" report warning me that my hidden site is "leaking" its location, my root robots.txt and a separate README file now both display the public and .onion addresses with a note that nothing is intended to be hidden. (I also appreciate the individual who sent the warning!)
On the flip side, to a new/naive hidden service operator the warning could be useful as it may not be immediately obvious to someone just dipping their toes in Tor as to why and how this configuration might reveal their hidden service's real physical location.
Certainly! I'm not new to Tor/HS and still got tripped up by this, especially seeing the issue as having been closed, not having realized it has not in fact been "fixed" and the only thing done was to add a startup warning. The issue really should be re-opened. It's not unreasonable to conclude that if the issue linked in the warning is closed that the warning is obsolete.
I think the issue itself should be listed as WONTFIX, as this is simply a reality of how the internet works. Even if Tor didn't supply any relay statistics, a curious and enterprising individual could "explore" by seeing what happens to a particular onion when one launches a DoS attack against an external IP that one believes might be connected to the .onion service. Notifying the administrator is sufficient, but I don't think an otherwise harmless log WARNING is sufficient to know that the administrator has been notified. Given that an administrator may not even review the logs if everything is functioning the way they expect, I would like to see something that forces the administrator to make a conscious choice.
On Mon, Jan 08, 2018 at 03:59:25PM -0700, Dave Warren wrote:
Even if Tor didn't supply any relay statistics, a curious and enterprising individual could "explore" by seeing what happens to a particular onion when one launches a DoS attack against an external IP that one believes might be connected to the .onion service.
Yep. If you want to go a step further, check out this paper: https://www.freehaven.net/anonbib/#remote-traffic-pets12 where they investigate inducing congestion on a target IP address to learn *what web page it's loading*. Turns out the attack is only effective in certain situations, but the fact that it's worth taking seriously at all is bad news for the Internet as a whole. --Roger
On 2018-01-08 16:08, Roger Dingledine wrote:
On Mon, Jan 08, 2018 at 03:59:25PM -0700, Dave Warren wrote:
Even if Tor didn't supply any relay statistics, a curious and enterprising individual could "explore" by seeing what happens to a particular onion when one launches a DoS attack against an external IP that one believes might be connected to the .onion service.
Yep. If you want to go a step further, check out this paper: https://www.freehaven.net/anonbib/#remote-traffic-pets12 where they investigate inducing congestion on a target IP address to learn *what web page it's loading*.
Turns out the attack is only effective in certain situations, but the fact that it's worth taking seriously at all is bad news for the Internet as a whole.
I forgot about that one! Not a surprise that it's possible in certain circumstances, I suppose. Nonetheless, a hidden service should be relatively immune if the IP address isn't known (and isn't trivially determined, such as also hosting a relay).
On 08.01.2018 23:59, Dave Warren wrote:
On 2018-01-08 14:09, Tortilla wrote:
On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
On 2018-01-08 03:21, Florentin Rochet wrote:
Perhaps in the case that the HS operator is not trying to mask the HS location, the act of mixing public relay traffic can be nothing but a *help* to defeat anyone trying to correlate traffic coming to the HS with traffic emanating from any one client.
Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed.
Indeed. I run some public resources (e.g. torproject.org mirror) on a public URL with a .onion site as well. Nothing is intended to be hidden, I simply want the content of anything I mirror to be available to Tor users without relying on an exit.
I think the real issue here is once more the wording "hidden service" for something which is, in your case, not intended to be hidden. I believe thats why the term "Onion Service" was introduced. A foolproof solution would be, that a relay complains and refuses to start if a "hidden onion service" is configured on the same instance. But would run without warning with "public onion services". I have no idea if a distinction between "public" and "hidden" onion services is planned or if its just change of wording until now.
On 2018-01-08 19:54, Alain Wolf wrote:
I think the real issue here is once more the wording "hidden service" for something which is, in your case, not intended to be hidden.
I believe thats why the term "Onion Service" was introduced.
Indeed. I use Onion Service when starting a conversation, but when Hidden Service is already in use, it seems to be less confusing to stick with the terminology being used in the existing thread.
A foolproof solution would be, that a relay complains and refuses to start if a "hidden onion service" is configured on the same instance. But would run without warning with "public onion services".
I have no idea if a distinction between "public" and "hidden" onion services is planned or if its just change of wording until now.
I don't think there is a technical difference between and "Onion" vs "Hidden" service, although there is obviously a huge real-world difference.
Hi, On 9 Jan 2018, at 08:09, Tortilla <tortilla@mantablue.com> wrote:
Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed.
Indeed. I run some public resources (e.g. torproject.org mirror) on a public URL with a .onion site as well. Nothing is intended to be hidden, I simply want the content of anything I mirror to be available to Tor users without relying on an exit.
After an "abuse" report warning me that my hidden site is "leaking" its location, my root robots.txt and a separate README file now both display the public and .onion addresses with a note that nothing is intended to be hidden. (I also appreciate the individual who sent the warning!)
On the flip side, to a new/naive hidden service operator the warning could be useful as it may not be immediately obvious to someone just dipping their toes in Tor as to why and how this configuration might reveal their hidden service's real physical location.
Certainly! I'm not new to Tor/HS and still got tripped up by this, especially seeing the issue as having been closed, not having realized it has not in fact been "fixed" and the only thing done was to add a startup warning. The issue really should be re-opened. It's not unreasonable to conclude that if the issue linked in the warning is closed that the warning is obsolete.
I avidly dislike warnings appearing in my logs that I intend to ignore, I would prefer to see this be controlled by a preference in torrc, either by an option to disable the warning, or better, require an explicit switch to be set before tor will act as both a relay and a hidden service. By making a "allow both HS and relay function" switch that is disabled by default, we could place appropriate comments in the default torrc file which explain the risks.
Absolutely agree -- at least if the intention is not to fix the information leak. Less careful HS operators may never even see the warning. Tor should probably refuse to start without explicit permission to act as a relay while hosting a HS.
Please open a ticket in the Core Tor / Tor component of: https://trac.torproject.org Thanks! T
On Mon, January 8, 2018 2:21 am, Florentin Rochet wrote:
Hey Tortilla,
Sorry for the late reply:
On 2018-01-05 21:13, Tortilla wrote:
The issue is fixed by adding the above warning message: if you care about your hidden service's "hidden" property, do not run a relay on the same process. Would you mind elaborating? As I read the tracker link, the issue was an informational leak in bandwidth reporting that has now been solved and closed. As such, the startup warning is misleading unless there are other concerns (such as Igor's below) and in which case, the warning should be re-worded. Why do you say it is *fixed* by adding a warning?
https://trac.torproject.org/8742 issue is already a stronger concern than Igor's point, and there are more. The informational leak in bandwidth is still there today, since these measurements are public. The issue is marked as fixed because, if you do relay+HS, you got a warning "not secure" that links to a possible attack (#8742) to recover your HS's location.
To be honest, I don't really get why you feel that the startup warning is misleading. Is it because it links a fixed and closed trac issue?
Now I understand. The misunderstanding was because the description of the issue lists three "Possible solutions," none of which include merely adding a startup warning and punting on the real solution. And yes, because the issue is marked as closed. Seems a little weak to consider the issue closed, at least IF it's not considered impossible due to other design constraints, and the comments on the issue don't give that impression. So I had assumed that with the issue being closed, one of the "Possible solutions" had been implemented and the information was no longer being leaked. I do think it's pretty important for people reading that startup warning and following the link to see that the issue is in fact NOT fixed. Whoever has permission to do so really should re-open the issue! Thanks for your other comments, Florentin.
On 08.01.2018 11:21, Florentin Rochet wrote:
Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed.
So assuming I just want to run SSH on some port on an .onion on the relay, what is the downside there? Just wondering if for that usecase, SSH to login remotely on to the relay would still have any disadvantages that I missed to consider. Thanks. yl
On 2018-01-09 13:33, yl wrote:
On 08.01.2018 11:21, Florentin Rochet wrote:
Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed.
So assuming I just want to run SSH on some port on an .onion on the relay, what is the downside there? Just wondering if for that usecase, SSH to login remotely on to the relay would still have any disadvantages that I missed to consider.
Do you care if a random third party could determine the real internet IP address of your .onion? If this isn't a problem, then you can probably proceed safely.
So assuming I just want to run SSH on some port on an .onion on the relay, what is the downside there? Just wondering if for that usecase, SSH to login remotely on to the relay would still have any disadvantages that I missed to consider
The relay is on clearnet in consensus, thus observable, attackable, correlatable, influenceable, patternable, DoSable, offlineable, rebootable, etc. If the onion is running on the relay and - its onion address is known to anyone else other than you, by or for any reason, including via v2 HSDir harvesting, the node is generally findable in time by them via correlation to above relay *ables [1]. - its onion address is only known to you, including by requirement of using only v3 onion addressing which claims HSDir unharvestability, then you stand a better chance, perhaps even a strong one. Adding an HsFootShoot config knob before tor will enable "HS + any other public mode of operation" seems potentially helpful. [1] Not much different than a client and some guards being used to find a HS over time. Or if all else fails, sequentially troll up to the entire allocated v4/v6 space till the services drop (this could already be in use against well and narrowly chosen likely subsets of hosts).
On Fri, Jan 05, 2018 at 03:08:48AM -0000, tortilla@mantablue.com wrote:
Second, I had read in the past opinions stating:
When operating a hidden service, running a relay helps mix traffic so that anyone observing traffic from the machine cannot easily run an analysis targeted at a hidden service that might exist on that machine.
The text of the startup warning seems to contradict that belief. Is there more to know, or is the warning only applicable to the now-closed information leak?
Can someone kindly clarify the current best practice in this regard and address whether or not that warning should be removed from tor's startup diagnostics?
I believe it is riskier to run an onion service on a public relay if you want to keep the onion service's location hidden. The original reason for this recommendation was because it's easier to induce load on the relay, and then look for corresponding congestion at the onion service. This congestion "guess and check" concern is similar to the concern around running your local Tor client as a bridge. You can read more here: https://blog.torproject.org/risks-serving-whenever-you-surf https://www.freehaven.net/anonbib/#wpes09-bridge-attack --Roger
On Fri, January 5, 2018 12:31 pm, Roger Dingledine wrote:
On Fri, Jan 05, 2018 at 03:08:48AM -0000, tortilla@mantablue.com wrote:
Second, I had read in the past opinions stating:
When operating a hidden service, running a relay helps mix traffic so that anyone observing traffic from the machine cannot easily run an analysis targeted at a hidden service that might exist on that machine.
The text of the startup warning seems to contradict that belief. Is there more to know, or is the warning only applicable to the now-closed information leak?
Can someone kindly clarify the current best practice in this regard and address whether or not that warning should be removed from tor's startup diagnostics?
I believe it is riskier to run an onion service on a public relay if you want to keep the onion service's location hidden. The original reason for this recommendation was because it's easier to induce load on the relay, and then look for corresponding congestion at the onion service.
This congestion "guess and check" concern is similar to the concern around running your local Tor client as a bridge. You can read more here: https://blog.torproject.org/risks-serving-whenever-you-surf https://www.freehaven.net/anonbib/#wpes09-bridge-attack
Ah, makes perfect sense. Thanks for the links. I'd strongly recommend changing the tor startup warning; remove the link to that closed issue and leave without further qualification OR include the links you've provided. Having a closed issue linked to the warning can lead one to believe the warning no longer applies. Do you have thoughts on a scenario when the HS operator is not concerned with hiding the HS location? -- Can operating a relay and HS together help enhance client anonymity, make end-to-end correlation more difficult in that case?
participants (10)
-
Alain Wolf -
Dave Warren -
Florentin Rochet -
grarpamp -
Igor Mitrofanov -
Roger Dingledine -
teor -
Tortilla -
tortillaï¼ mantablue.com
-
yl