Electrum Cash SSL connection: self signed certificates

Technical
#1

A random fulcrum server gave me a list of peers with 27 results, of which 22 have SSL connections enabled.
SSL is great because of 2 things;

  • it protects against snooping. If you’re at the bakery and you open your wallet, that creepy guy in the corner can’t figure out which addresses you’re subscribed to and use the wrench attack on you.
  • it protects against replacement attacks. Data you think comes from a trusted server actually comes from an attacker.

So, SSL is good.

Problem is that there are a number of self-signed certificates. Which makes sense in a way, the alternative is to depend on a certificate system that has various political and similar issues. My country’s government has a root authority and anything signed by them is blindly accepted, for instance. Scary AF!

But self-signed certificates are a real problem in that it really is not hard to man-in-the-middle such a server for that person using the local store’s wifi. So while the protection is better than nothing, it isn’t exactly great. (it does manage to avoid the first bullet point’s problem, which is great for our knees!) I’d rather trust the ssl certificate providers than every single public wifi hotspot owner I ever will connect to. It’s a question of scale.

Yet, it does make me wonder if there is a way to get our cake and eat it too.
From a simple option like a fingerprint being included in the listing of peers API call to maybe something more complex with BCMR web of trust style statements.

Or maybe others have an even better idea?

ps. the observant reader may notice that the p2p traffic of full nodes is likewise not encrypted. I’d agree it would be great if it were. But since there are thousands of full nodes whereas with EC only has two dozen, we avoid this issue by repeating the p2p messages to multiple random peers. Still, any solutions we might come up with may be useful in the p2p domain too.

2 Likes
#2

I can’t even think of any solution other than opening our own certificate authority organization like letsencrypt.

Or maybe somehow leveraging scripts to request certificates from letsencrypt itself? Should not be a big load on them, there isn’t that many Fulcrum servers.

We could create a mockup dirty HTTPS server in the background that would finish the letsencrypt scheme.

Of course, this is still pretty centralized. I also had a decentralized idea which would be feasible… if not for the requirement of reading blockchain first. And you cannot read blockchain without connecting to fullcrum first. Chicken-and-egg problem.

I am afraid all possible solutions will require some kind of trusted central authority.

#3

ok here is an idea. Please read it everyone and see if you can steelman it and poke holes in my thinking.

SSL/TLS connections on the Internet are widely used, http itself uses it to become https.

Any server offering such a connection needs to have a private key and that needs to be signed by a certification authority. Where the CA can be yourself. As the original post states, it is a problem to be self-signed since that means anyone can impersonate you. Like if I pick up the phone to call Shadow (who’m I’ve never met or spoken to before) I have no way to know if I’m not talking to some government operative instead. I can’t identify the guy. (wikipedia: “man in the middle attack”).

So, in short, the problem is one of reputation. And the main way to solve that is to get some official authority to make the claim. This is what the world uses. I’m not so happy with that only default, though. Because if we don’t want to involve them (or we don’t trust them), we are stuck.

Except, reputation may simple be good enough™ to work.

So, my idea:

  1. a server can be self-signed just fine. But they must have one IP address or domain name they are making themselves known under.
  2. A server makes available an SSL based connection on a different port (EC already does this).
  3. Servers 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 server.
  4. When clients get a listing of all known servers, the call returns not just the IP and hostname, it also includes the fingerprint of the certificate.
  5. When a client connects to a server that is self-signed, they validate the fingerprint in order to establish that the peer they connect to is the same one that the servers also connected to. They only connect to servers that have an established reputation.

The implications of this are various;

  • we avoid needing that central authority that the government can override.
  • a server changing their certificate (and thus fingerprint) may become not used for a couple of weeks. Though certificate expiration dates may make an exception. This is actually useful to notice domain theft and instantly stop usage.
  • we can do SSL/TLS encryption without adding any central point of failure.
  • A server that disagrees with the rest on a certain fingerprint (of another server) is suddenly suspect. (reputation goes both ways)
  • Servers need to connect to known servers a bit more often to quickly verify that the fingerprint is still accurate.
  • Servers may need to make sure they don’t just parrot a list of known servers from others, but actually verify it is accurate before sharing the details.

To avoid any illusions, this is not perfect, it just is a big improvement over not having decentralized end-to-end encryption:

  • servers are still run by untrusted parties. This doesn’t instantly make them trusted or more responsible.
    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 about the wifi operator or ISP being able to lie to you about what happened on the blockchain. This is even about being able to hide the fact you’re actually talking to an elecrum or full node server in the first place. Its just encrypted data.

#4

I have to think about this.
Your describing certificate pinning which is generally thought as an old practice.

Fundamentally, encryption is really only valuable with authentication (as you’ve identified). Without that trust how can we know the right recipient is decrypting the message? :thinking:

#5

There are some crucial differences that I think makes it lots better. First of all, there is no actual pinning action by any users. Maybe I wasn’t clear that this proposal is only for improving the reputation of self-signed certificates. People that use any certificate authority will not be affected.

But more importantly, the “pinning” happens by other servers, clients just follow. Unlike the linked article this is not about a trust relationship, this is about being able to ask many others what THEY think is the real identity of a certain hostname or IP.

#6

I wrote:

I then concluded that having SSL that is self-signed actually doesn’t solve the second point. Which is the basis of my suggestion to improve self-signed reputations.

Today I got a PM explaining that actually, a known vulnarability in the WIFI standard makes a self-signed certificate basically the same vulnarability as not having a certificate at all. Making both attacks possible with probably just a phone.

The CVE is described here;

its too new to be in the NIST database, so lets see what rating they give it.

#7

While this is far from perfect, it seems like a significant improvement over what we have now.

Also, it should not require much work to implement.

I like it :+1: