You start a container that runs just tor with a config and can read the routing endpoints from your config, or link to localhost:2375
HiddenServicePort <onion port> <host>:<port>
You setup HiddenServiceAuthorizeClient with stealth auth type and a list of authorized clients.
You can lock your firewall rules down as the hidden service only requires outbound to HTTPS.
On the client end you setup regular Tor with HidServAuth <onion address> <auth-cookie>
With stealth auth other tor users won't see the serivce and port published without the auth cookie
You can then use socat to bind the remote hidden service and port to a local host and port:
socat tcp-l:127.0.0.1:2023,fork socks4a:onionaddr.onion:localhost:23,proxyport=9050
You then have the remote ssh server available locally with no public interfaces, no public ports, and an additional layer of confidentiality and authentication
Just tried to upgrade and got this `[warn] Hidden service option HiddenServiceAuthorizeClient is incompatible with version 3 of service in <path>`.
Does anyone know if there is any plan to support stealth authentication? It's a pretty usefull feature.
and additional layers of attack surfaces
One would naturally be the onion address. If they could break the 1024 bit RSA key, they could hijack the name. Risk of this happening: very low. Impact: massive especially outside the realm of tor.
Any additional risks you were thinking about? Backdoors in tor project? Hardware malware specifically designed for tor (rather than than being general)?
That said, I don't think there's any reason to believe Tor is any more likely to be vulnerable than any other software in your stack. The project is open source, and is very much written with a focus on security and privacy.
But this opens another possibility of one-time addresses, and address scalability. My question is, does network cost increase with number of addresses? If peers on the network are using one-time addresses to form circuits, will that scale fine?
Basically I am envisioning two people communicating via dedicated addresses for their own use only. So a single key becomes a network channel to send data to a specific peer. That "peer" could actually be many different devices, but all ultimately connect to the same distributed application with a shared state.
So basically onion addresses are usernames which also let you pipe data to that user, right? How is this not the coolest thing ever?
The use case you suggested should be possible. Also check out ricochet which works with legacy onions for chat.
You'd be able to run namecoin and other systems
edit: to add, I haven't yet completely bought into the new onion services. I like a lot of the security improvements, but it is really going to depend on how name resolution works and how authenticating endpoints will work for users. Running a pluggable name resolution system means we can try out different solutions and see which takes off organically and practically.
BTW check out this link for some survey results that point out that onion length might not matter so much since the legacy onions were already unrememberable:
Cheers and thanks for keeping the discussion fruitful :)
So... it sounds like what you're looking for is a password manager.
In theory, you could achieve this by only storing the password DB in a cloud service you access through the Tor browser, but then you run into two other problems. First, how do you remember the address of the service you're using to store your password DB? If you store that address on your device, you've lost your plausible deniability. I guess you'd have to use a well-known clearnet site you access through Tor (Dropbox, Google Drive, etc).
That leaves another problem though. If you have a password manager installed on your PC, that implies the existence of a password database, which might also cause you to lose your plausible deniability.
Maybe if there was a profiles/password manager feature built into the Tor browser that lets you decrypt and load a profile from a service provider, then destroys all local evidence of that profile when you close the browser? Seems like a feature that could be useful in all browsers actually. A cross-browser password manager and bookmarks sync feature? That'd be really convenient.
Also see this blog post: https://blog.torproject.org/cooking-onions-names-your-onions
But the blockchain can still be flooded with fraudulent onions and at some point you're still putting all of your trust into a form of authority.
The practical implementation would be the bookmarking service would authenticate their links against this blockchain, and the user would either have an agent on their system to validate the claims, or another 3rd party who they trusted to validate the claims?
It's a shame they don't have a description for technical users. I'm more interested than "bigger, tastier, and looks like this", but less interested than 13000 words of specification.
Here is a list of improvements of this proposal over the legacy hidden services:
a) Better crypto (replaced SHA1/DH/RSA1024 with SHA3/ed25519/curve25519)
b) Improved directory protocol leaking less to directory servers.
c) Improved directory protocol with smaller surface for targeted attacks.
d) Better onion address security against impersonation.
e) More extensible introduction/rendezvous protocol.
f) Offline keys for onion services
g) Advanced client authorization
Tor developer here. You are right there is no middle ground there.
I'm kind of on the run right now, so I can't write a big explanation here. However check this section of the proposal that presents some high-level improvements:
But agreed. This is basically offering a paragraph long abstract or read the massive white paper, without much in between.
Put everything on Tor as a hidden service and eventually the stigma will go away.
It's dead easy. Setup a web server basically like normal, but make sure it's listening only on loopback if that's important to you.
Then install tor, and add a couple of lines to the torrc and restart tor.
HiddenServicePort 80 127.0.0.1:8080
You can run as many hidden services as you like on the same tor instance, with different onion addresses, and forwarding to different places.
I've always wanted to set up onion addresses but I'm always wary to open up a new bag of worms for my personal projects.
The fact it sounds so easy is encouraging.
I've not experienced any random breakages.
I'm hoping at some point blockchain DNS systems are adopted by mainstream (or niche in case of Tor) vendors. It would make it so much much easier to name onions.
PS: It seems that Bittorrent over Tor is a bad idea, .
But what's the end result of hidden services?
I want to be anonymous sometimes but I can't think of a time when I want the host of a service I use to be anonymous.
In most situations their identity is actually important to me. I want to know the source of news, to trust that I'm sending a message to the right person, to trust that I'm not relying on a site run by some kid in her parents basement.
And I know that legitimate sites can get certs for onions these days (like facebook)... But doesn't that defeat the original purpose of running a hidden service if the purpose is to hide the owner?
It also hides the a service provider's physical location (well, their IP address and hence location in the network graph) from even a user that knows their identity. You might know that I am an investigative journalist you're trying to send information to - or, given the origin or Tor, maybe you're a spy and you know I'm your handler - but I don't want to give away my location.
There are also a lot of use cases where the user doesn't care that much about knowing who the service provider is, and the service provider cares a lot about hiding their identity (enough so that they would not provide the service if they could not be anonymous).
For the example of, say, political commentary - often what you care about there is less the real-world identity of a person, and more their persistent identity and reputation. On the other side of the equation, though, in some environments people might not feel safe expressing their opinions at all if those opinions could be traced back to them.
Obviously, Tor is not the only solution to this problem, but it is one that has the nice property that you don't need to register any accounts, you don't need to pay for anything, the availability of the Tor network is pretty good ...
Also I am not so sure I would call it a side effect, for two reasons:
1. Any application that grows the anonymity set of Tor is useful for the goals of the Tor network. Even if your SSH session does not have any use for the anonymity that Tor provides, it still is good for the Tor network that you add cover traffic to the network for those who need it.
2. Decentralization has a lot of overlap with anonymity, and as such I would consider this use actually to be well within the use cases that Tor is intended for: ISPs build networks that increaslingly make it difficult to use your own devices for anything more than consuming content that is delivered from the network, thus contributing to the growth of the kind of centralized services that don't provide any anonymity at all. Using Tor to access your own machines and thus enabling you to build infrastructure that is not inspected by third parties is very much aligned with the goals of the Tor project.
IPFS or Keybase seem like better approaches towards those goals. And, yes, Tor makes sense if you need to hide your IP address. But beyond that I don't see much further use.
And in doing so you contribute to the usefulness of Tor, since it relies on people using it to create an anonymity set.
So now I have a private channel to that address and I don't have to worry about the exit nodes (unlike when I use Tor for clearnet sites).
But now how do I know that I can trust the owner of that onion?
How can you trust anyone?
That's a deep philosophical question but doesn't really have anything to do with the technology you are using?
Personally I trust something more when someone puts their reputation on the line for it.
You see it with the drug marketplaces - users self-organize a distributed reputation system that tells other users which sites can be trusted with bitcoin and drug transactions and which cannot.
It's a remarkably well functioning and resilient system - and its hosted across reddit, forums, blogs, etc.
It's not just hidden, it's also decentralized. You can:
* Register and publish a site in seconds ...
* ... without a central registar (just generate a key) ...
* ... from just about any Internet connection.
* Get a secure transport without the clusterfuck of backdoors that is HTTPS.
* All for a concentrated audience that likes a different, simpler, smaller, homier Web.
What I don't understand is what any of that has to do with any sort of "correctness"?!
How do you find out the correct name of James Miller? How do you find out the correct domain of google.com? That just seems like a set of nonsensical questions to me.
An other use case would be access to a server IPMI/Online KVM switch, which has a tendency to not get updated regularly.
In general any situation where you in the past had to go through a third-party hub could be replaced with a hidden service for a end-to-end solution, as long latency isn't a major requirement.
That's a strange comment.
Why would they accept money to make the TOR system slower?
That he believes there is something "suspicious" about Tor nodes because their IP doesn't match to any country or AS name in the free distribution of the GeoIP database built into Tor is just smh bad
Why he also believes bots accessing his HS has anything to do with Tor Exit nodes is also beyond me .. but he provides no evidence for any of that either
He was asked to ping tor-security or file an issue and never did, afaik - nor was it ever really seriously discussed
I've tried to communicate with the hackerfactor person about this and figure out ways forward, but I received unproductive responses which did not make me want to proceed in discussion.
We need the community to help us understand how they best want to manage the DoS risks and build sustainable proposals to fight them.