Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm using Tor to access my local network services through hidden services. Since I don't need to hide my IP address I'm going to follow your advice gratefully. Didn't know that's possible.


That's sort of like having backdoor access to your internal network (similar to teredo). Others may use it to gain access to that network. If it's your home, that may be OK to you, but if it is an employer, you may want to obtain approval to do that and be sure all of your hidden services use keys or strong passwords for access.


This is completely incorrect. It is physically impossible to make a connection to a hidden service without the hidden services onion address (I am talking about the current v3 onion addresses, the ones that are 56 characters long). This is thanks to the fact that the onion address itself is the hidden services public key.

If you keep your onion address private then nobody can connect to your hidden service or even know that it exists. Simple as that.


It's also "physically impossible" for someone to gain access to a well configured IPSec endpoint, yet we still consider this a point of access that needs appropriate controls and security oversight. There are many, many ways that people collect key material to use to access tunnels to corporate networks. No matter how confident you might be in the technology, you should never provide an access point to a private network without full consideration of the security and compliance implications.

Perhaps the bigger issue though is that Tor at least used to be frequently used by botnets for C2, I'm not in a SOC environment any more so I'm not sure how much that trend has changed. But it's very common for corporate security programs to configure IDS to report on Tor traffic since it's associated with some sort of compromise a good percentage of the time. This does mean you get occasional false positives from normal Tor use to e.g. anonymously access public materials but that's life in a SOC. The point though is that most corporate environments ought to notice this kind of thing happening whether or not it's done with the approval of IT/security.


Security through obfuscation isn't bad, but its certainly not infallible.


Could you explain this a bit more? How would this be more open than port forwarding? I don't see how someone could leverage this without exploiting whatever app is hosted as the hidden service?


It's a tunnel into your internal network.

If nation states and/or cyber criminals do control most of tor, then you are opening your internal network to those groups.


No, because it is possible establish a token required for access to an onion service on top of the obscurity of having to actually discover the service's public address.

It is also extremely likely that said adversaries control most of Tor, considering that the main mechanisms of tracing Tor circuits do not require control over any nodes of the Tor network whatsoever- snooping on IXPs and as many autonomous systems and underwater wires as possible.


So is port forwarding or running any other services, tor is special in absolutely no meaningful respect here.


The OP said "employer," and most people can't port forward at the office without talking to IT.


there are an almost infinite amount of ways to host services from behind firewalls without port forwarding, or any network admin approval. Tor is not special in this regard, nor dangerous due to supposed bad people controlling the network.


Yes, it's exactly like port forwarding.


This is incorrect. A Tor hidden service is fundamentally different from port forwarding. If you don't have the hidden services onion address (v3 address) then you physically cannot make a connection to the hidden service. This is because the onion address is the hidden services public key.

You can scan the entire internet for open ports, you can't scan the Tor network for hidden services to connect to unless you already have the hidden services onion addresses.


When you create an onion address, does that address get leaked at any point? As in, are there nodes or servers in the Tor network that know that xxxx.onion is a valid address at the time of creation or afterwards?


With the old v2 hidden services (16 character long onion addresses) it was possible to recover the onion addresses of any service running on the Tor network while the v2 hidden service was running.

However, that issue was only present in v2 hidden services. v2 has been depreciated in favor of the new v3 hidden service protocol (56 character long onion addresses) which is not vulnerable to this issue. This new protocol contains a full ed2559 elliptic curve public key in the onion address. The key in the onion address is used to derive what are called "blind keys". These "blinded keys" are then announced to the Tor network in such a way that nobody can recover the original public key without prior knowledge of the it, leaving them unable to establish a connection with the hidden service.

I have only briefly elaborated on how v3 hidden services work. If you are interested in a more in depth and technical explanation I encourage you to read:

[0] - https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.... [1] - https://gitlab.torproject.org/legacy/trac/-/wikis/doc/NextGe...


You can set up a token that is required to actually make the connection[0].

[0] - http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2i...


Are you sure? Don't an attacker need knowledge of the onion address, which is almost unguessable?

But with client authentification that wouldn't be a problem anyways because only chosen clients get access.


Onion address is not unguessable, it's stored on a DHT shared by relays with the HSDir flag (which they earn after ~7 days IIRC).

I think this changed slightly with v3 addresses, so my comment might be out of date, but I think the general premise remains the same. (EDIT: Apparently with V3 addresses, there is still a DHT, but client uses key derivation so that the HSDir only stores a daily-rotated identifier known as a "blinded public key." [0])

Although your hidden service address is not hidden, you can require that any client connecting to it present a valid authorization key (I think this is also new in V3?).

Also, it obviously depends which service you're exposing — if you are exposing an SSH server that only allows key-based authentication, then it shouldn't matter if people can simply connect to it — assuming you trust the SSHD software, and your threat model doesn't depend on avoiding detection completely.

[0] https://blog.torproject.org/v3-onion-services-usage/


Any reason you don't use some kind of VPN solution for that instead?


Hidden services are very easy to configure (the basic config, if you want to be as anonym as possible you have to do more). Install tor, add a few lines to config, done. And: You don't have to change your firewall settings at all. Nothing is exposed to the clearnet.

You can also make your service be accessible only to certain clients which have a certificate. I consider this very secure.


Only recently has there been an easy to setup and secure alternative with the same properties – Tailscale

It is centralized, yes, but it is way, way faster if you care about latency

https://tailscale.com/

(you can also self-host it with the open source “headscale” project)


+1 for tailscale, it is an absolute joy to use.


> You can also make your service be accessible only to certain clients which have a certificate. I consider this very secure.

Are you talking about this? https://community.torproject.org/onion-services/advanced/cli...


Yes, client authentification it is called.


Thanks for mentioning it, I would have overlooked that feature entirely, otherwise.


I guess I can understand that from an ease of configuration standpoint. Having said that I had no trouble with setting up zerotier VPN, which is also very easy to configure.


I do the same but you still need to be careful when running Zerotier to listen only on IP addresses that the ZT link is assigned. I run a private mailserver and I've made sure that there are no sockets listening on any non-ZT externally routable IP address. (I guess for good measure I could have nftables drop traffic coming in on those ports on my WAN link.) But with Tor you just point it to a service listening on 127.0.0.1 or [::1] and you're in business. For me ZT is fine, but for folks who want to muck around a bit less, I can see the appeal of Tor.


Not only it's easier to configure, but it provides better security. The onion address works as a server certificate.

1) You don't have to pay or trust a VPN provider

2) It works on dynamic IP addresses and without relying on DNS

3) It exposes only one TCP service




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: