Full Node Behind TOR Guide

[size=24pt]UPDATE Oct 14 2014: This method is not functional for use under the current version of peerunity (v0.1.1) and peercoin(v0.4). [/size]
[size=14pt]see http://www.peercointalk.org/index.php?topic=3477.msg33767#msg33767 I’m keeping the information here for reference in case someone makes use of it for further deveolpment. I will soon be creating a peer4commit project aimed at the integration of peercoin with hidden services networks like TOR and I2P. Stay tuned for the link to the project and the proposal.[/size]

[size=24pt]WARNING: Do not use until community has had time to discuss the solution viability. Follow the thread for updates.[/size]

–[size=36pt]DRAFT[/size]: Still editing. Just needed to post it so i can work on it more later. I fail at editing lol –

From SunnyKing interview: http://www.peercointalk.org/index.php?topic=2934.0

Ben: Do you have any guidance on what the community can do to ensure network security? Is it as simple as "start minting"?

Sunny King: Right that’s sort of comparable to 51% attack in bitcoin

Sunny King: I know many users are hesitant to do this because of risk of getting hacked. That’s why the cold minting feature is an important consideration

Sunny King: Before that feature is implemented, you can do two things to help mitigate the risk

Sunny King: One is to use the ‘minting only’ unlock mode for minting with an encrypted wallet

Sunny King: The other is to proxy your minting node behind tor

Ben: For the second mitigation strategy, we, the community, can help educate people about setting up Tor and enabling the proxy settings on their wallet client

Minting behind TOR was suggested by SunnyKing beack in June 2014 as a way to mint semi-securely while waiting for the cold-minting development. However, minting and securing the network isn’t the only thing needed to ensure the survival of the network. Full Nodes that accept incoming connections are VITAL for the health of the network’s infrastructure.

In here, we are attempting to create a full node (acceptes incoming connections) in a way that doesn’t disclose the IP address and limits access to only the ports required for the peercoin network communication.

I’ve been thinking about this for quite a while but never had the time to play around with it. Today I managed to finish setting it up and testing it. It’s working! :slight_smile:

Why is this significant ?
To run a full node means that the device will be accepting incoming connections and with that it needs to disclose its external IP address. Malicious people out there could get their hands on your ip address and attempt multiple attacks on your device hoping to hit the jackpot by getting through a security vulnerability or open ports that the user wasn’t aware was open. That’s the reason people who mint on their wallets (meaning they keep the majority of their funds on that wallet that’s online) tend not to run a full node. Since minting requires an unlocked wallet, if an attacker manages to find a breach in your connection by knowing your IP address, he gets access to your funds. There are multiple projects attempting to solve this problem like the cold-minting (protocol side protection), peerbox ( OS security ) and maybe others that i’m not aware of. This method attempts to provide a safe way to run a full node without disclosing the user’s IP and only explicitly open the ports that the peercoin network needs. In essence it achieves a software version of the same protection princibles that the Peerbox project is providing.

How do we achieve this?
We use the TOR network and the Hidden Services feature it provides. To read more on that https://www.torproject.org/docs/hidden-services

Pros:

  • Can run Full Node without fear of exposing IP address
  • Miniting on Full Node is achievable securely without need for hardware isolation like peerbox nor do we have to wait for cold-minting to finish development. You can start minting on full node today!
  • Does not create disjoint networks. The client will still be able to connect to nodes not running a tor hidden service (Note: if the peercoin client is updated to provide tor hidden service by default this issue would be obsolete)
  • As everyone feels secure about minting on full nodes, the number of full nodes will explode and we’ll have a more robust infrastructure for the network.
  • TOR is a already well established system that’s robust and can be trusted. We do not need to reinvent the wheel.
  • Can be used to support the TOR network by running tor as a relay as well

Cons:

  • Higher bandwidth usage for users as all information passing in the TOR network requires encapsulation and security overhead
  • Slower transfer rates (Note: this is only significant during initial sync with network. After that, transactions aren’t large enough to notice the a significant change in speed)
  • requires using TOR, a third party application. ( However, since TOR is open source, it can be included in the client or instructions of how the client can set it up could be made available)

– Work In Progress–

[size=18pt]How to run a full node behind TOR[/size]

[size=12pt]STEP 1: TOR download, installation, configuration instructions[/size]
Windows

[ul][li]Download the Vidalia Relay Bundle here : https://www.torproject.org/download/download.html.en [/li]
[li]Follow the installation and run vidalia to run TOR. https://www.torproject.org/docs/tor-doc-windows.html.en [/li]
[li]Follow the instructions here to create a hidden service https://www.torproject.org/docs/tor-hidden-service.html.en and change ports to match the following [/li][/ul]

HiddenServiceDir C:/Users/username/Documents/tor/hidden_service HiddenServicePort 9901 127.0.0.1:9901 HiddenServicePort 9903 127.0.0.1:9903

Choose whichever Dir you like but keep note of it. It will hold both your hostname and the private key associate with that hostname

[ul][li] Restart Vidalia and TOR[/li]
[li] Navigate to the HiddenServiceDir that you specified in the torrc. It will have 2 files now. Take note of the contents of the hostname file. This is the address for your hidden service that will allow others to connect to you. We will need it when configuring peercoin client[/li][/ul]

[size=12pt]STEP 2: Peercoin/Peerunity configuration[/size]

[ul][li]Exit the client[/li]
[li]Delete the current peerlist by deleting addr.dat (Win 8.1 at: C:\Users<user name>\AppData\Roaming\PPCoin\addr.dat ) [/li]
[li]Add the following lines to the peercoin.conf file[/li][/ul]

[code]############# TOR CONFIGUARATIONS ############
upnp=0
socks=5
proxy=127.0.0.1:9050
onion=127.0.0.1:9050
listen=1
discover=0
externalip=

############# END TOR CONFIGUARATIONS ############[/code]
Put your TOR hidden service hostname that we got earlier at the externalip field

[ul][li]Run client[/li][/ul]

[size=12pt]STEP 3 : Router and firewall configuration[/size]

[ul][li]Remove ports 9901 and 9903 from any firewall authorization you have given before[/li]
[li]Remove ports 9901 and 9903 from port forwarding rules on your router if you had it configured before or used UPNP to auto configured it[/li][/ul]

I hope this concept appeals to the peercoin community. There is great value that could increase the number of full nodes exponentially which is much needed for the peercoin network. I see great potential in implementing this concept into the client for ease of setup for all users and this way every user out there will be running a full node regardless of their network configuration and whether they can achieve port forwarding or not.

Best regards

IndigoMan

  • Anonymous minting, there is nothing that makes is secure.

I understand that this doesn’t make minting in itself secure. Although, the whole premise for the PeerBox project is securing the surroundings of the client and the protocol rather than the client itself by limiting hardning the security around it. This method takes a differnt approch to achieve the same thing as PeerBox. PeerBox gives out the IP address to the public because it’s confident of its security. This method doesn’t disclose the IP address and only limits access through one annonymous door with one single open port and hence don’t need to worry about hardening security of the os. The OS may still remain vaulnrable but we’re not announcing our location to the world to come and test my security :slight_smile: … I hope this makes sense.

The premise of the PeerBox project was stated here : http://peerbox.me/info.html

Peerbox is created to address security and privacy concerns regarding using cryptocurrencies. Security and quality of Peercoin client (or any Bitcoin based client) is not tested enough and it taken for granted. Most crypto coins, the other forks of Bitcoin have wallet's that are not being used in same way as Peercoin's wallet, that is running 0-24h connected to the Internet. They are mined with specialized software, not linked with wallet and thus coins are not exposed to attack as they are simply not connected. This kind of cryptocurrencies, the POW ones are the most popular cryptocurrencies at the moment, and this approach that takes security and privacy for granted just works for most of people. Peercoin however utilizes process called minting that requires that wallet is unlocked and then connected to at least 8 peers on the network, each and everyone of those peers now knows IP of person minting, thus enabling attack vector. Running full node is even more risky, now you connect to 20-70 peers with port 9901 forwarded. That means this port, on which Peercoin wallet is running is now completely open to anyone on the internet, exposing it to attacker. Knowing this people tend to avoid minting and risk entire network security by doing so. One way to solve this is to develop cold-locked minting where coins remain encrypted even if in minting mode. So, they are safe even if attacker does succeed and hacks the wallet. In my opinion this is not elegant solution, as it calls for changing the protocol itself and will probably cost a lot of time to develop and properly test. I do admit that it will ease a lot of minds and persuade them to start minting. Peerbox is taking diffirent approach to this, instead of dealing with Peercoin code and protocol it ensures that underlying OS is secure and limits possible attack vectors. So, it protects the wallet software and thus indirectly coins in it.

Thus, this project’s ultimate goal is to provide maximum security platform for minting and running nodes.

[ul][li]Security will be enforced by underlying OS, which will be hardened by default to repel most of the attack vectors.[/li]
[li]Secondary goal of Peerbox is to provide plug&play platform for running Peercoin nodes and to allow safe minting as easily as running a wallet software.[/li][/ul]

Yes, but running the client on the TOR is not a method it is simply running it on different network. I have already spoken about running over TOR disconnects you from “regular” network, and people could easily be stuck chasing ghost chains or fork in the TOR network since there is no exchange of information with other network clients.

This method doesn't disclose the IP address and only limits access through one anonymous door with one single open port and hence don't need to worry about hardening security of the OS.

Exactly, and beyond those doors there be dragons.
Thus, OS is very easily compromised and thus your wallet.dat is very easily compromised.

Please understand that I’m not trying to disapprove what are you doing, just trying to get some sense here. Please do not advertise this as a solution to security problems as it is not.
TOR is not secure, it is only anonymous and if TOR (as a program) is not secured on the OS, the OS is compromised and thus wallet.dat is compromised.

Please understand that I'm not trying to disapprove what are you doing, just trying to get some sense here. Please do not advertise this as a solution to security problems as it is not.

I completely understand. Don’t worry. No hard feelings here. Just collaboration to provide solutions :slight_smile: … I’ve edited the post to include a big warning at the top asking people to wait for further discussion of the matter. :wink: I am also not trying to put down the other projects (cold-minting and PeerBox) … not at all ! I’m introducing a middle ground of some sort. There are people who are already minting without running full nodes. Their OS might not be as secure but they’re taking that risk. This solution would give those people the ability to run full nodes at the same level of risk they were taking when they were minting without running a full node. PeerBox solution is a superior one in terms of security of course as it’s isolating and securing the OS running the node and limiting ANY CONNECTIONS to it. That makes PeerBox superior to this of course but it comes at the cost of less ease of use due to the nature of having the coins on a seperate device that needs to be accessed to spend and also the need for extra hardware. This solution provides a middle ground rather than a replacement :slight_smile: … Speaking of PeerBox, I know the Nubits team want to create a NuBox like PeerBox which I thought was stupid lol … I posted there that they should integrate their work with PeerBox since that would be THE box to use for secure keeping of crypto rather than having to own multiple boxes hahaha … you might want to get in touch with them :slight_smile:

Yes, but running the client on the TOR is not a method it is simply running it on different network. I have already spoken about running over TOR disconnects you from "regular" network, and people could easily be stuck chasing ghost chains or fork in the TOR network since there is no exchange of information with other network clients.

The issue of a disjoint network was brought to my attention before. It was a concern while I was trying to make it work. However, this solution doesn’t create disjoint networks. Before putting this together, I was already running my peercoin/peerunity client over TOR for the past several months. It’s able to connect to non TOR clients normally. It just routes the communication through TOR. By introducing the Hidden Service functionlity, i’ve only added the option to run my node as a full node. I’m still able to to connect to regular full nodes (nodes not on TOR). There won’t be a disjoint as torrified nodes can still connect to regular nodes. If this idea becomes appealing enough, it could be implemented directly in the client and after one update cycle all clients would be torified by default which would make the network disjoint issue obsolete, even though its non existent in this solution.

Exactly, and beyond those doors there be dragons. Thus, OS is very easily compromised and thus your wallet.dat is very easily compromised.
I don't fully understand what you mean by dragons behind the doors. Could you please elaborate? I sense I can address this concern but need better clarification on what exactly is the concern lol
TOR is not secure, it is only anonymous and if TOR (as a program) is not secured on the OS, the OS is compromised and thus wallet.dat is compromised.
TOR is a well established project that has proven to be robust and functional. TOR's communication is secure until it reaches the exit node where it's now outside of the TOR network. That's why TOR users are strongly advised to only access HTTPS sites and not use TOR for HTTP sites. Having said that, there is nothing in the current messaging system of peercoin that needs a full secure connection between nodes. whatever an exit node can do with the peercoin messages, ANYONE today can do with the current peercoin network. We would not be losing any security in that regard. Again im not sure i fully understand your concern on this point as well. If you need more clarification, could you please elaborate?

By the way, thanks for contributing to the discussion … this is much needed and appreciated collaboration :slight_smile:

Indigoman, thanks for your work mapping out the process for running a full node as a TOR Hidden Service. I have been thinking of moving behind TOR myself, but I didn’t want to unplug my full node from supporting the open network. Your method makes it possible for other TOR clients to initiate connections to your node, which is great for building a robust network behind TOR. My hesitation with TOR, however, has always been the trust issue with exit nodes. These are obvious points of weakness which, by this point in time, are likely all housed within NSA facilities or worse. I don’t feel completely comfortable relying on these nodes as the only gateway between TOR and non-TOR peers.

So, I would like to run the following idea past you (and others) to see if it’s something worth pursuing: I would like to host my own TOR “exit node” but only for Peercoin. The way I would accomplish this would be simply to run a TOR Hidden Service node as you describe with an additional (hidden?) connection on the LAN side to a regular full node. Any transactions I receive on the TOR node will be passed immediately to the regular full node on the open network and vise versa.

I will plan to do some experimentation with this set-up when I have time later in the week, but before I started, I just wanted to know if there were any obvious problems I am missing. Specifically, I have been trying to figure out exactly how standard Peercoin nodes broadcast their list of known peers to other nodes. Are local-range IP addresses always included, or is there built-in logic that filters these out. Also, if I use the “connect=” or “addnode=” switches are the corresponding IPs always broadcast or is there a way to keep them private? If I’m using a local proxy to connect my open full node to my hidden TOR node, will this be immediately evident to the entire world?

Thanks again for your work here. Like you, I hope to see this all ultimately worked into a version or Peerunity or such.

@ IndigoMan

The issue of a disjoint network was brought to my attention before. It was a concern while I was trying to make it work. However, this solution doesn't create disjoint networks. Before putting this together, I was already running my peercoin/peerunity client over TOR for the past several months. It's able to connect to non TOR clients normally. It just routes the communication through TOR. By introducing the Hidden Service functionlity, i've only added the option to run my node as a full node. I'm still able to to connect to regular full nodes (nodes not on TOR). There won't be a disjoint as torrified nodes can still connect to regular nodes. If this idea becomes appealing enough, it could be implemented directly in the client and after one update cycle all clients would be torified by default which would make the network disjoint issue obsolete, even though its non existent in this solution.

That is great news if you could connect to non TOR nodes normally. I look forward to see you complete TOR hidden service and map the ground for future development on TOR integration.

Exactly, and beyond those doors there be dragons. Thus, OS is very easily compromised and thus your wallet.dat is very easily compromised. I don't fully understand what you mean by dragons behind the doors. Could you please elaborate? I sense I can address this concern but need better clarification on what exactly is the concern lol

Dragons mean that there are unknown dangers, same as with regular internet and possibly more since TOR is essentially deep dark web.

TOR is not secure, it is only anonymous and if TOR (as a program) is not secured on the OS, the OS is compromised and thus wallet.dat is compromised.

TOR is a well established project that has proven to be robust and functional. TOR’s communication is secure until it reaches the exit node where it’s now outside of the TOR network. That’s why TOR users are strongly advised to only access HTTPS sites and not use TOR for HTTP sites. Having said that, there is nothing in the current messaging system of peercoin that needs a full secure connection between nodes. whatever an exit node can do with the peercoin messages, ANYONE today can do with the current peercoin network. We would not be losing any security in that regard. Again im not sure i fully understand your concern on this point as well. If you need more clarification, could you please elaborate?

TOR may be secure but it leaves the door open for attack, that is what I’m trying to say.
You can not say it makes minting secure, since it does not – you fail to realise this.
Tor does not magically make minting secure, it only makes it anonymous.
And it is not forbidden to mint some crypto-coins, no government forbids this.

This is how people run Tor; https://trac.torproject.org/projects/tor/wiki/doc/TorInChroot
Isolation, so compromised Tor can not harm the system.

I apologize for the dealy. I’ve been swamped with class work and had thanksgiving.

After further testing, I came to notice that the setup proposed is not functional on the peercoin network to level I want it to be yet. The proposed method does create a hidden service and it does allow the node to accept incoming connections from peers on the hidden service. That part is functional and has been tested. It is also able to connect to non TOR hidden serrvices full nodes through TOR so the issue of being able to connect to one network at a time is not an issue. The issue was that the externalip specified doesn’t get relayed to the connected nodes. Meaning, unless you already know my .onion link and have added it manuanly using addnode, you wouldn’t find out about my node regardless of how long I leave my node running. The client disregards the tor link and passes the public link that tor gives your to other peers. And since that ip is not yours and there is not service listening waiting on it, you wonuldn’t be recieving any incoming connections. After further investigation in the code, it turns out that many parts of the code can already support tor links however it hasn’t been fully implemented. The tor functionality was fully supported in bitcoin in v 0.7 while i think peercoin was based on an earlier version and wasn’t fully updated unless I’m mistaken. Eitherways, the code needs updating for this method to work.

The solution requires modification to the peercoin clients both Peerunity ( not significant modification) and Peercoin core ( Significant modification ) as the current clients do not pass on the correct address that’s given in the externalip option. I have forked that latest version of Peerunity v0.1.1 ( on October 13 2014) and will be working on implementing the correct functionality to allow for the same TOR support as the current Bitcoin client. I will attempt to implement the code in a manner that allows for further expansion in the future should we want to include other p2p networks like I2P for example. Having said that, I am currently in my last year at university and could get swamped with course work so it might take much longer than expected to implement that functionality. If anyone is interested in helping with this implementation, feel free contact me and we can coordinate work and bounce ideas off of each other. I’m putting together a proposal and plan to move forward for the integration of peercoin (and hopefully its dervatives peersharesm peerunity, and nu) with TOR and other hidden services networks. I’m creating a project on peer4commit soon and generating a github repository that focuses on implementing the proposal I’m putting together. Stay tuned for the information.

Should there become consensus on the use and need for this by the community and further discussion with the core deveolpment teams for peercoin and peerunity, the functionality would be pulled into the main clients (currently: Peercoin/Peerunity). Since without network consensus, there is a bigger risk of creating dijoint networks which would be hindering the netwrok rather than helping it. Therefore, I will try to introduce the functionality in a fork and possibly keep it in a seperate client until such a consensus is reached. Using this client, the user would be given full explanation of the risks he might be taking based on his chose mode of opreation for his node.

My ultimate goal is to expand the peercoin (and potentially any crypto network) network across multiple networks in a manner that doesn’t create disjoint and keeps it unified while still providing access to the network by means that provide privacy and security for Full Nodes. Today cryptocurrency is not heavily under attack by those who fight freedom but that could change any time. Having this infrastructure allows peercoin to be resilient and not be shaken by governmental action by utilizing current robust technologies that aims to provide that freedom and privacy.

[quote=“learnmore, post:6, topic:2973”]Indigoman, thanks for your work mapping out the process for running a full node as a TOR Hidden Service. I have been thinking of moving behind TOR myself, but I didn’t want to unplug my full node from supporting the open network. Your method makes it possible for other TOR clients to initiate connections to your node, which is great for building a robust network behind TOR. My hesitation with TOR, however, has always been the trust issue with exit nodes. These are obvious points of weakness which, by this point in time, are likely all housed within NSA facilities or worse. I don’t feel completely comfortable relying on these nodes as the only gateway between TOR and non-TOR peers.

So, I would like to run the following idea past you (and others) to see if it’s something worth pursuing: I would like to host my own TOR “exit node” but only for Peercoin. The way I would accomplish this would be simply to run a TOR Hidden Service node as you describe with an additional (hidden?) connection on the LAN side to a regular full node. Any transactions I receive on the TOR node will be passed immediately to the regular full node on the open network and vise versa.

I will plan to do some experimentation with this set-up when I have time later in the week, but before I started, I just wanted to know if there were any obvious problems I am missing. Specifically, I have been trying to figure out exactly how standard Peercoin nodes broadcast their list of known peers to other nodes. Are local-range IP addresses always included, or is there built-in logic that filters these out. Also, if I use the “connect=” or “addnode=” switches are the corresponding IPs always broadcast or is there a way to keep them private? If I’m using a local proxy to connect my open full node to my hidden TOR node, will this be immediately evident to the entire world?

Thanks again for your work here. Like you, I hope to see this all ultimately worked into a version or Peerunity or such.[/quote]

@learnmore… I don’t recommend unplugging your full node and running it on TOR as I came to find out it’s not curretnly functioning they way we want it to be. Also after the implementation is done, even if you’re running a hidden service node, if you’re comfortable with running a full node on your public address then by all means run both! You’re supporting that network that way. As I mentioned above, i’m putting together a proposal that lays down the road map for the TOR/Peercoin integration as I envision it. Stay tuned and do share your thoughts on the proposal when it comes out :wink:

As for your questions regarding the protocol, I am not really the person to ask hahahaha … Yesterday was my first time diving in the peerunity code and I’ve never seen peercoin code before. I might have a better understanding of it and be able to answer your questions in the future but for now you might want to redirect your questions to the protocol and core development guys :slight_smile: …I would imagine that there is some sort of filtering out mechanims as for example if I addnode=192.168.1.50 which would be a LAN node, it wouldn’t make sense to pass that IP to public nodes. However, if there is another local node say 192.168.0.60 that’s connected to us, it could reach first node and therefore passing that IP would be beneficial. It makes sense logically but not sure how it’s implemented without diving deeper in the code. If you want to look into it yourself, a piece of advice focus on the following files: init.cpp main.cpp net.h net.cpp netbase.h netbase.cpp as they hold almost all the logic (i think… don’t quote me on it lol)

[quote=“peerchemist, post:7, topic:2973”]TOR may be secure but it leaves the door open for attack, that is what I’m trying to say.
You can not say it makes minting secure, since it does not – you fail to realise this.
Tor does not magically make minting secure, it only makes it anonymous.
And it is not forbidden to mint some crypto-coins, no government forbids this.[/quote]

@peerchemist … I completely understand that minting isn’t secured in this manner. I thought of it it more like security by obscurity in not discolsing the IP but you’re right it’s not truly “secure”. I will update the topic and remove that reference. The more I thought about that peercoin/TOR integration, the more I realized this is a solution for network infastructure rather than minting. Therefore, the proposal I’m writing will focus only on expanding the number of nodes that accept incoming connections. I’m including in the proposal a role for PeerBox and could use your insight on the topic :slight_smile:

Thank you guys for participating in the discussion. I will update original thread to reflect that the method is not working under the current implementation and put a reference to the thread that has the propoasal and is focused on developing that integration capability.

Wondering if the tor onion address advertisements and onion address lookups still needs to be updated? Or this is already solved and tor bitcoin code has been ported?