Many years ago, I was put into a situation where I had to start using online banking. Being skeptical about security, I asked for something along the lines of a certificate hash that could be verified in person. They couldn't answer that. So I tried asking how I could verify that the certificate displayed by the web browser was correct. They couldn't answer that. In the end, I ended up trusting the padlock icon and being left with the impression that commercial security was mostly about the illusion of security. To this day I'm left with the impression that some sort of MITM attack would be possible through the creative abuse of certificate issuers and proxies since there is no direct means of verifying the certificate is authentic. And they won't take that final step since it shatters the illusion of security being simple.

> mostly about the illusion of security. To this day I'm left with the impression that some sort of MITM attack would be possible through the creative abuse of certificate issuers and proxies since there is no direct means of verifying the certificate is authentic

Why would a bank's customer support agent know about encryption? Usually IT is a siloed function in most banks.

In a sane world, the bank would have a flier for the teller to give to the GP with several ways to verify the bank's key.

We only live without this because the bank can just reverse transactions when there is a problem and the police will fall pretty heavily on anybody that exploits the weakness. And also, because there are plenty of easier to exploit ones.

I think it was more that a random bank teller could not be expected to explain the intricacies of certificate authorities and online encryption. The bank likely has a security whitepaper on their website which explains all this.

Nowadays, all certificates have to be submitted to Certificate Transparency Logs and must have attached proof to be considered valid. Also, there are CAA records to ensure that only specific CAs are able to issue certificates.

> People, or businesses, that you know in real life could exchange certificate hashes in person.

This happens about as often as using PGP email. Approximately never.

This is the exact response that I tried to cover with the rest of my comment.

I actually think it’s an interesting idea that merits some investigation.

My first idea is that it would be a nightmare from a supply chain security perspective. Eventually someone from the Amazon box printing company will be bribed to print a different certificate hash on 0.5% of the printed boxes, for example.

.onion addresses are hashes, but a hash long enough to prevent a brute forcing is also too long for people to consistently recognize. Is facebookwkhpilnemxj7asaniu7vnjjbiltxjghye3mhbshg7kx5tfyd.onion the right URL for Facebook or a clever near-collision?

(The correct address is facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion)

("q" instead of "g").

This is only true if you limit yourself to standard character based hash representations.

I feel like whatever scheme you use, if it is too simple there won't be enough unique keys to go around, but if it is complex enough it can be subtly changed in ways a human would find hard to notice.

Isn't the whole point of a hash that you can't "subtly" change it?

that's the point of a machine-checked hash, because computers are really good at exact equality operations. humans have a much harder time with it.

Would you notice if someone changed the "f" in the middle of that onion link to an "l"?

Again, it's impossible, or should be impossible, to easily change a single character in a hash. The avalanche effect means that small changes in the input data will result in huge changes to the hash.

The input data in this case is the private key so if you had that available to change, you would not need to do anything more as you could already control the real .onion domain.

The attack on things like onion domains would be finding another domain that to a human looks similar enough to be mistaken for the real deal. You'd do that by brute forcing (same as what Facebook did to get the "facebook" prefix in their onion domain) and for a sucessfull attack the space you need to brute force is limited by what humans can distinguish, which is smaller than the whole hash space.

On the other hand, it's probably easy to brute force search a hash which is visually close enough for most people to not notice the difference.

The limit is much more about how many bits a human is capable of distinguishing reliably at a glance, which I think is very likely below the brute-forcible level

It’s a good form of secondary support for authentication, and is a reasonable foothold to start expanding circles of trust (I.e. second hand trust.. or “trust what my trusted source trusts”).