I gather that Mist will automatically look for Geth on a local machine via IPC to save it maintaining its own blockchain. Is it possible to tell it to look for an instance of Geth on another machine via HTTP RPC?
Go-Ethereum – How to Attach Mist to Geth Node on Different Computer over HTTP RPC
go-ethereumipcjson-rpcmist
Related Solutions
IPC or Inter-process Communications generally works on your local computers. In the Ethereum space, IPC normally involves geth creating a IPC pipe (which is represented by the file $HOME/.ethereum/geth.ipc) on your computer's local filesystem.
Other processes on the same computer can then use the IPC file to create bi-directional communications with geth.
RPC or Remote Procedure Calls generally works across different computers. In the Ethereum space, RPC normally refers to the RPC endpoint localhost:8545 or 127.0.0.1:8545 or 192.168.1.123:8545.
If you use localhost:8545 or 127.0.0.1:8545 for your RPC endpoint, other process ONLY on the local computer can communicate via this RPC endpoint, as localhost and 127.0.0.1 is only accessible from the local computer.
If you use a non-local IP address like 192.168.1.123, any other computer on your network can access this RPC endpoint.
If your internet connection forwards traffic from your internet IP address to your computer's IP address 192.168.1.123 then any computer from the internet can access your RPC endpoint by connecting to {your internet IP address}:8545.
As documented in How to reduce the chances of your Ethereum wallet getting hacked?, the user Patrick forwarded his internet IP address traffic for port 8545 to his computer's non-local IP address (e.g. 192.168.1.123 instead of 127.0.0.1). When Patrick unlocked his account to transfer some funds, an attacker from the internet was able to execute geth JSON-RPC commands to steal Patrick's ethers.
So if you do enable RPC over geth, enable it using --rpcaddr 127.0.0.1 if you only want it accessible from your local computer. If you enable it using your network IP address (e.g. 192.168.1.123), all computers from your network will be able to access geth's RPC endpoint. If you then have your internet modem forwarding traffic for port 8545 from the internet to your computer's 192.168.1.123:8545, anyone from the internet will be able to access geth's RPC endpoint.
So, don't specify the --rpcaddr parameter and it will default to 127.0.0.1 which is only accessible from your local computer, and if you want to access RPC from other computers on your local network, make sure that your internet connection does not forward internet traffic to your geth machine.
Responding to additional question
The best way to check if your local machine is listening for communications outside your local computer space is to perform the following:
Iota:backup user$ netstat -an | grep LISTEN
tcp4 0 0 127.0.0.1.8545 *.* LISTEN
tcp46 0 0 *.30303 *.* LISTEN
tcp4 0 0 127.0.0.1.8181 *.* LISTEN
tcp4 0 0 127.0.0.1.6379 *.* LISTEN
In the above table, you can see that the ports 8545 (geth), 8181 (my local web server) and 6379 (Redis NoSQL database) are only accessible from my local machine. Port 30303 however is accessible from outside my local machine. As my ADSL router forwards traffic from port 30303 to my local computer, the world can access my local computer via port 30303.
IPC and RPC are not necessarily the same in terms of accessibility. If you have an IPC connection accessible, programs on your local computer may have access to the program listening on the IPC file. But your web browser will not have access to this file as web browsers generally do not connect via IPC.
If you have a RPC connection accessible from your local machine, your web browser running locally on your machine will have access to your RPC connection. The parameter --rpccorsdomain is meant to restrict access from your web browser from domains other than what you specified, but any (malicious) program running on your computer can just ignore this request (it is just a polite request and not a restriction) and access your RPC port anyway.
The problem is that the Azure marketplace is hosting an old version of Geth that does not support EIP 155 replay protection, which the latest version of MetaMask does.
The solutions are:
- Use a different client for testing (like TestRPC).
- Get Azure to update their hosted Geth version.
- MetaMask could add the ability to support the old transaction signing format, which requires a solution to this issue.
As a member of the MetaMask team, I'd love if we didn't have to support old, more dangerous Ethereum clients like this, and would greatly prefer if Azure just updated their Geth version.
Lastly, you can run an older version of MetaMask. Version 3.5.2 was the last version that did not implement EIP155 replay protection: https://github.com/MetaMask/metamask-plugin/releases/tag/v3.5.2
Best Answer
As far as I know Mist can only connect to a local instance, and even then only via IPC. The reason is that is uses a few APIs that are not exposed by default over HTTP and would probably be unsafe to do so (e.g. account management).