SSL And The Future Of Authenticity
thoughtcrime.org
thoughtcrime.org
This article is two years old, and the effort behind the convergence project (http://convergence.io) seems to have moved on to tack (http://tack.io)
The ones that get permanently removed are generally because they've already gone out of business.
Why can't we have two separate systems? One to ensure two parties communicate secretly with each other, and another to somehow verify the real-life identities of those two parties? Why did those to seemingly separate concepts evolve as one?
If we could separate them, it seems we could solve a lot of low-level security problems online: sites could have cost-free, CA-free self-signed certs to ensure only that packets between the client and server are secure/private; then separately, there could be a different system to ensure that the client is really, truly communicating with the Bank of Their Nation, Inc., and not a scammer from Nigeria.
How did identity and privacy become conflated, and how can we separate those to provide monetary-cost-free eavesdropping protection in the future?
A man in the middle could easily reproduce your data to the other party (and viceversa) if you are not sure you are talking to the correct party.
How could you be sure you're doing
A -(encrypted)-> B
A -(encrypted)-> MITM -(encrypted)-> B
You can't, so you'd better ditch the encryption and just talk plaintext.
Encryption relies on the fact that you have a signature from B who says "hey, I'm REALLY B, you're talking to me directly, here's my public key so you can talk only to me and nobody else can read the data inbetween".
That's where CAs come into play: they're the authorities that certify that B's signature/public key is actually tied to the domain you think you're talking to.
> CA-free self-signed certs to ensure only that packets between the client and server are secure/private
What's the difference of a self-signed certificate from www.gmail.com and a self-signed certificate from RandomHacker who says he's www.gmail.com ?
They look the same.
So... both concepts are actually separate already (e.g. did you ever trust a certificate manually in your browser?), but it's pretty pointless when you ignore CAs and therefore don't know if the certificate is real or crafted.
| They look the same
> That's where CAs come into play [...]
Unless you're somehow able to collect all signatures realiably without anyone MITMing while you collect the signatures over the internet.
That's why CAs exist. They're a reliable and secure way to collect signatures.
They're secure because they're authorities whose certificates are in your system and not sent over the wire. That's why they're preloaded in your web browser/OS, so they can't be tampered with in the first place.
Why have CAs and not just signatures for domains?
1. The list of certificates for the whole internet is HUUUUGE.
2. Certificates change.
3. Certificates get revoked.
4. New certificates are issued.
Of course, it can still be tampered if you download certificates (or programs bundled with certificates) from untrusted sources and/or not check the signature before installing.
An analogy might be: 1) I seal a letter in an envelope, and the postal service guarantees that it will arrive at the address I specify, regardless of the human that opens the letter at that address; and 2) I seal a letter in an envelope, and the postal service guarantees that not only will the letter arrive at the address I specify, but that it will only be opened by the human I specify, who is identified by his postal-service-issued ID number.
When you accept an unknown certificate, you're communicating with whoever is on the other side regardless of their identity.
You have to settle the identity of the other side at least once when you stablish communication[1]. Actually, you're not settling the identity, just a public key with which you encrypt the communication (which in turn is settling the identity as a desirable side-effect). You still need their public key because, well, that's how encryption works: you send a message encrypted with a certain public key, which can only be decrypted with the corresponding private key.
Fortunately, web browsers alert you not to do this because it's pointless. You see both encryption and authentication as a single step because web browsers abstract the process for you. Otherwise, why am I encrypting the connection in the first place? If someone's listening and you're not checking certificates, sending plaintext or encrypted is actually the same thing and offer ZERO encryption. I'd be able to read anything you say without effort.
[1] http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...
The analogy for the first case is more like "The postal service guarantees that it won't be opened before whoever is reading your mail opens it", which is clearly a pretty meaningless guarantee.
Another difference: The Internet as a whole routes packets mostly concerned with reliability, not trustworthiness of the ISPs in the middle, so a trusted Postal Service doesn't work on the Internet either.
I pay less for SSL certificates per year than I do for the domains I use them on. You can get a free certificate from StartSSL if you're just playing, or an $8 certificate from Comodo if you're more serious. Some registrars (cough Gandi cough) even include a free SSL certificate with every domain.
So the "total ripoff" thing has been all but solved by market competition (unless you prefer to splurge on a $800 certificate that doesn't do anything a $8 certificate can't do). It's really just the "insecure" part that needs to be addressed.
In practice I feel like the whole CA system is flawed because you're trusting the CA based on the authority assigned to it by a higher governing body, a governing body you can't necessarily be sure isn't getting some blank-check signing superpowers from the CA and doing man-in-the-middle attacks on persons of interest with bogus certs. I can't necessarily trust that the authorities have my best interests in mind so I can't trust the CA signing system.
I look forward to the author's proposed solution(s) to this problem.
I'm OK with showing IE6/7 users a polite suggestion to upgrade, but a certificate error looks unprofessional. In addition, Chrome on XP is also affected (if the user has missed the CA update) because Chrome doesn't carry its own list of trusted CAs.
Unless you need *.domain.tld certificates.
You can get a free Lamborghini for an inexpensive $400,000 one-time fee!
Edit: also, if I can get an unlimited number of Lamborghinis for just 400k, where do I sign up??
Thanks for the info but I just tried to refute the fact that free/$8 certificates do the same as $800, which they clearly don't.
Don't get me wrong: it's great! But completely irrelevant for the argument.
> if I can get an unlimited number of Lamborghinis for just 400k, where do I sign up??
You only get a single certificate for $60, not an unlimited number of them.
EDIT: see child comment, I'm wrong and you do get unlimited certificates.
See https://www.startssl.com/?app=25#27
"The fees for Class 2 (60$) and higher are applied to the verification and not for the certificate(s), i.e. you pay for the validations we perform. Once validated there is no limit placed on the amount of certificates one can receive (This depends on other limitations such as uniqueness of the subject line for example)."
Edit: They cover exactly their costs. The cost is at validating your persona (they call you, you fax them scans of your passport/drivers license/etc, they need to check that etc.). Issuing a certificate is fully automatic so there are no costs associated with that, so they don't charge for that.
Domains are not free. Servers are not free. Bandwidth is not free. Time spent confirming a domain's ownership is not free. Would you rather get free certificates from a CA whose website is littered with gaudy ads?
Because that's what we were talking about: free certificates from StartSSL (or $8 from Comodo) which did everything that $800 certificates do.
I just meant to refute it.
Might be thinking of that.
Pinning certificates or using something like Namecoin to maintain a key to human identifier mapping seems like a better idea.
The beauty of the Idea is that it democratizes the trust domain. It creates a web where ordinary people decide whom they trust simply by putting down httpsy-Links.