Low level Internet traffic is by default not encrypted and thus open for anyone to read. This is common knowledge. There are also a lot of cases where this escalates to dangers not known to the general public. For instance on a public WiFi an unencrypted service can be replaced by another evil one.
General risks of not using encrypted traffic, especially in the context of Bitcoin Cash, are the lost of privacy to the loss of actual money due to scammers providing the user with spoofed information.
Encrypting data still requires trust, however. This trust is the core place where attacks can take place and in this page we investigate the trust and provide some solutions.
Trust in a certificate.
When your webbrowser connects to a well known website over TLS the certificate used to encrypt that data is implicitly-trusted. Some known authority signed it, therefore you can use it.
In the context of Bitcoin Cash this is generally speaking a good solution. But the trust may be misplaced if the political situation becomes an issue. It may also be too expensive to get or keep updated a certificate. In short, it is not the perfect solution and while good enough for many we would like to find alternatives.
Mesh services based trust.
A well known way to verify that you are not being fooled by a server is to verify that what you see, and which certificate you are asked to use, is the same as what others see. Do all users, from all countries, see the same information as you? Then you're likely seeing the real server and you can trust the certificate you got to be really from the service you're connecting to.
It is important to understand that this doesn't really increase of decrease the trust of the actual service you connect to. Much like with certificate authorities, they don't judge the web content either. What this confirms is that you connect to the actual owner of the service. Not some 3rd party that impersonates him. Nothing more, nothing less.
Instead of trusting a centralized certificate authority, it may be possible to decentralize this and use the group to replace this trust.
So, my idea:
- a service can be self-signed just fine. But they must have one IP address or domain name they are making themselves known under.
- The mesh based services connect between themselves using the SSL connection and write down the fingerprint (a hash) of the certificate that the remote is using. This gets coupled to the name or IP that is unique to that service.
- As is standard in decentralized systems, each node shares the listing of known other nodes. When clients get this listing, the call returns not just the IP (and hostname), it also includes the fingerprint of the certificate. So the client now has a list of services to connect to and pick one based on whatever algorithm it wants.
- When a client connects to a server using a certificate, they validate the fingerprint in order to establish that the peer they connect to is the same one that the other services also connected to. They only connect to services that have an established reputation.
With these steps the client can establish connections with a sufficient number of peers, building a database of known peers in this specific peer-to-peer network. They all reinforce the mesh networks 'web of trust' by sharing the fingerprint of other peers, as they have observed it. With each new host the client connects to, the trust is increased.
In short: we avoid depending on one of the many central authorities. Many points of failure because any single one being compromised makes the certificate untrustworthy for normal clients.
Some further thoughts on expected problems and possibly recovery:
- When a service is observed changing certificate (and thus fingerprint) clients are advised to simply not use this. Certificate expiration may overrule this as a new fingerprint is expected around that time.
What this provides is when a domainname is stolen from the previous owner, the trust doesn't move to the new service until probably various weeks later. Allowing operators to take action. - A service that disagrees with the rest on a certain fingerprint (of another service) is suddenly suspect. (reputation goes both ways)
- Services need to connect to known services a bit more often to quickly verify that the fingerprint is still accurate.
- services may need to make sure they don’t just parrot a list of known services from others, but actually verify it is accurate before sharing the details.
Securing the connection.
To repeat the actual trust model: this allows us to make sure we connect to the server that the rest of the network agrees is what they see too.
This doesn't make the service itself suddenly trustworthy, just the connection to them. We just know that the server we want to talk to is the one we actually talk to.
A server with a great reputation running in the cloud can still be taken by the operator or the government or naturally by bribing the operator. Access to the private keys (which are online) means compromise.
So, again, this is about the local snoop learning about your wallets. This is going to help a lot to avoid the WiFi operator or ISP being able to listen in on you or even provide false data.
Addendum: protection against what?
The man in the middle idea is a bit abstract for casual readers. It doesn't sound very scary.
But imagine this:
you're at a store and you're about to pay with BitcoinCash. You scan the QR and send your transaction. BUT, you're actually connected via the local free WiFi which captures your requests. Someone there can see your on-line-communication.
If you're unlucky, you maybe just send the merchant a $50 bill from a deposit you made this morning that contains $1000. And now that person in the store with you knows this. And you're phone, or even you, are a target for a theft.
Basic encryption is healthy, good for privacy and just plain smart. Lets make this happen without needing to ask permission from big corporations.
Suggested usage
This strategy can be used for p2p traffic. A wallet connecting to a full node or two full nodes talking to each other.
This strategy can be used also for electron-x servers (like Fulcrum).