The Lurker

HTTPS certificates are bullshit

posted by ajf on 2010-10-08 at 09:43 pm

National Novel Writing Month is imminent. I don't write fiction; for me, NaNoWriMo is just an annual reminder that I neglect my blog. I file this rant under "shit that is stupid that I cannot possibly hope to do anything about".

In an interesting discussion of decentralised addressing (as an alternative to centralised DNS), Daniel Kahn Gillmor writes (ending with slightly less emphasis than I'm using here):

If they're looking for John Smith because the word on the street is that John Smith is a good knitter and they need a pair of socks, they can just examine what information we each publish about ourselves, and decide on a sock-by-sock basis which of us best suits their needs.

But if they're looking for "John Smith" because their cousin said "hey, i know this guy John Smith. I think you would like to argue politics over a beer with him", then what matters is the introduction.

This is how HTTPS should work:

I have an existing relationship with a bank. My trust in them is based on the relationship I have had with them for a decade or two.
I want to use Internet banking services, but there are two vital precautions I need to take. Anyone could be observing the traffic between my computer and my bank, and use what they observe to steal my money. Encryption prevents the "man in the middle" from reading the data travelling between me and my bank. But, more subtly, an attacker could manipulate the network to force my web browser to connect to a hostile server instead of the bank's server. It is obvious to everyone who has used Internet banking that I need to prove to the bank that I am the customer I say I am, but it is equally important that the bank's web server proves to me that it really does belong to the bank. We need mutual authentication.
I get, from the bank itself, both my credentials and some means for my computer to verify that the web site it is communicating with really is the bank's. Perhaps they post some sort of token to me, much as they handle credit and debit cards. Or if I don't trust the post, I could go into a branch and collect something in person.
I go to the web site, and my computer is able to confirm that I have an encrypted channel that really is reaching the party I trust.

But this is how HTTPS actually works:

I have the relationship with a bank, and I want to use their Internet services.
The bank issues credentials I can use to prove my identity to them.
I then tell my web browser to go to my bank's web site. To determine whether or not it really is the right site, the server sends a certificate asserting that one of several dozen organisations I have no relationship with and therefore no particular reason to trust has verified that the site belongs to my bank. (Who creates this list of organisations? The company I already trust to provide the web browser itself. So the scheme — a word that sits uncomfortably close in the dictionary to "scam" — is not completely without merit.)
They perform this "verification" by charging the organisation in question nine US dollars. (OK, some of them charge more than that, and others charge less.)
When it is pointed out to these organisations that there is absolutely no reason to believe the certificates they issue, they introduce a new product called "Extended Validation", where "Extended" means "this time, we actually fucking do what we spent the last ten years lying about doing".

SSH uses a different method:

The first time you connect to a server, SSH shows you the server's "fingerprint", giving you the opportunity to confirm that the server really is the one you were trying to reach.
If you confirm that the fingerprint is the right one (and here the SSH process falls down; mostly people don't know what the fingerprint for a new server should be, so they just assume it's the right one), your SSH client remembers that server's identity for you.
When you connect to that server in future, your SSH client is able to determine that the server is the same one that showed you the initial fingerprint.

Supporters of HTTPS claim that their method is better, because even the first connection is verified by an organisation they trust. But consider the real risk that people actually face:

You have an existing relationship with Bank X.
Whenever you to go the Bank X web site, your browser checks the certificates, which confirm that the web site belongs to an organisation called "Bank X".
Later, by accident, or due to malicious tampering with the network, or because you click a misleading link in a phishing email claiming to be from Bank X, you click on the link to your attacker's web site.
Your web browser checks the certificates, and confirms that the web site really does belong to an organisation called "BankXX". It does not know the one thing you really want and need to know: that "BankXX" is just an attacker who has nine US dollars, and has nothing to do with the "Bank X" you have visited in the past. It does know, and could but does not tell you, that it is a party you have never communicated with before.

What you want is to know that, after a trusted introduction, that you are still communicating with the same party that you were introduced to. What HTTPS gives you instead is an assurance that the party is who they claim to be, even if that claim has been crafted to deceive you into thinking it is another party.