SSL And The Future Of Authenticity(thoughtcrime.org)
thoughtcrime.org
SSL And The Future Of Authenticity
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
48 comments
Fuck yeah, I wasn't aware of these projects. I thought the article was exceptionally good and I'm very pleased that there are people taking the initiative to actually do the hard work in search of resolution for the problems detailed. Thank you.
It's pretty clear and well-written, so I think its going to be worth reading to explain why the system is wrong for as long as our system is a list of permanently trusted CA's. There's no reason I should be trusting all those CA's to sign for anything on the internet forever.
No CA is permanently trusted. CA certificates expire like any other SSL certificate, and most of the CA certificates that my browser trusts will expire in about 10 years. In addition, browser vendors like Mozilla routinely make decisions to add and delete CA certificates.
I think literally forever is an exaggeration (as it pretty much always is). But the point is that you have to trust them for longer than you would like to, because once they've signed the certificates for a huge chunk of the internet, you can't take them back out without breaking a ton of stuff. Meanwhile as long as they remain trusted they can keep signing new certificates and making it that much harder to ever remove them.
The ones that get permanently removed are generally because they've already gone out of business.
The ones that get permanently removed are generally because they've already gone out of business.
I've been wondering lately why SSL ties both encryption between two parties and the identies of those two parties together. A genuine question borne of genuine ignorance on my part: why are these two concepts tied to the the same protocol?
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?
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?
Because encryption's purpose is completely defeated if you don't know who you are talking to.
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
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.
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.
So forgive my denseness here, but that can still be broken down into two separate protocols, right? 1) I wish to communicate with foo.com privately, regardless of whether foo.com is really who foo.com claims to be; that is, one time foo.com might be 192.168.0.0, and the next time it might be 192.168.0.1; but either way, regardless of who I'm truly communicating with, I can at least be sure that nobody but the recipient can decode the packets. Then, 2) I can guarantee everything in (1), plus that my the packets I exchange with foo.com are truly the foo.com that resides at 123 Main St., USA.
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.
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.
It's already separate (check the bottom part of my parent comment).
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...
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 statement "nobody but the recipient can decode the packets" is meaningless if there are no bounds on who "the recipient" is.
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.
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.
The physical analogy falls apart because generally envelopes are tamper-evident against most attackers (i.e. it's hard for a malicious postal worker to take your envelope, open it, read what's there, then repackage it without it being detectable that something fishy happened). With communication protocols over the Internet, the tamper-evidence falls apart. All packets look alike.
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.
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.
| They look the same
Did you read the rest of the comment? Specially the part below:
> 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?
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.
> 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.
I never got that deep into SSL, but I seem to recall there are cipher suites that allow unauthenticated encryption. I could be wrong. Also, what everyone else said.
> total ripoff and also insecure
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.
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.
> on a $800 certificate that doesn't do anything a $8 certificate can't do
Unless you need *.domain.tld certificates.
Unless you need *.domain.tld certificates.
You can get unlimited *.domain.tld certificates from StartSSL after inexpensive verfication step. But don't tell anyone.
AFAIK those are $60, not free.
Why does it have to be free?
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?
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?
> Why does it have to be free?
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.
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.
That's payment for green icon in the address bar, nothing more. Monopolized market of green icons.
The $60 were meant with the inexpensive verification step. Then the number of wildcard certificates is not limited.
You pay that fee, and then can generate unlimited wildcard certificates for a year.
Which is > $8... and specially > free.
You can get a free Lamborghini for an inexpensive $400,000 one-time fee!
You can get a free Lamborghini for an inexpensive $400,000 one-time fee!
If you have >7 domains and want wildcard certificates, it is the cheapest option.
Edit: also, if I can get an unlimited number of Lamborghinis for just 400k, where do I sign up??
Edit: also, if I can get an unlimited number of Lamborghinis for just 400k, where do I sign up??
> If you have >7 domains and want wildcard certificates, it is the cheapest option.
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.
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.
You are wrong. At StartSSL, you can get an unlimited number once they validated your person, which costs 60$. That validation lasts for a year. During that year you can generate as many wildcard certificates as you want.
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.
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.
But why do wildcard certificates need more validation in the first place?
Thanks! That's good to know! (But irrelevant to the discussion anyways.) Edited the info in the parent comment for further readers.
It makes sense that the more CA's you allow into the market the less of a "total ripoff" you'd have due to competition, but intuitively there would be more of a problem on the "insecure" side due to fly-by-night companies with weak security. I don't see this as the main problem though.
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.
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.
In what way is a StartSSL certificate any different from a Comodo certificate? What makes StartSSL only usable for "playing"?
StartSSL is recognized by OS X 10.5 or later, and Windows 7 or later. Older OSes might not recognize it if the user has missed any updates.
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.
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.
Free StartSSL are for non commercial usage. This is, I guess, what he means by "for playing", I don't know for comodo, if their certificates can be use for commercial applications.
Where can I find those $8 certificate? https://www.positivessl.com/ only shows me "from €49.00/ year".
Name cheap has them. http://www.namecheap.com/ssl-certificates/comodo/positivessl...
Might be thinking of that.
Might be thinking of that.
Trust authority only works if users are willing to actually make trust decisions. Since they are not, whatever trust authorities chrome, firefox, and IE ship with will end up being a default single point of failure, target for compromise, and point of corruption.
Pinning certificates or using something like Namecoin to maintain a key to human identifier mapping seems like a better idea.
Pinning certificates or using something like Namecoin to maintain a key to human identifier mapping seems like a better idea.
Seems to me like Namecoin is a practical, secure method of distributed identification and verification. It's basically a secure P2P key:value store based off of Bitcoin's method of operation. Its original intent was to replace DNS (the website name is the key, the IP address is the value), but I see no reason why we couldn't also use it to host public keys.
How does it stop me from saying "Bank of America's public key is <my public key>"?
Nothing. The same way you can go buy iamthebankofamerica.com for a couple bucks and put all the keys you like on it. But once you go to the actual Bank of America domain record you'll get back the real certificates.
BoA would have to buy the rights to that name from whoever got it before them.
A great time to raise these questions. What reason have we ever had to trust any of these "authorities" (let alone the deteriorating state of the field, e.g. the recent Turkish fiasco)? Without a firm answer for that question, SSL is reduced to magic thinking.
I'm no expert at cryptography and all that stuff, but i find the model of the httpsy link quite interesting. You include the identity of the site you're linking to in an extended httpsy address, so that you can be sure that you land on the site you linked to.
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.
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.
Because there's no alternative. Either you trust the authorities or live in a constant fear that the other parties' certificates are hacker-crafted.
Require people to submit a public key and two factor serial number during domain purchase, then use that key to sign individual server certificates. If you loose the key or two factor device you loose SSL on the domain, no exceptions. When I go to google.com all I really care is that it is the same site that I visited yesterday. The current SSL scheme gives no such assurance.
What if confidentiality and authenticity would be handled by IPSec/DNSSEC instead of using solutions at the transport layer? This is not my idea, or new, but it makes more sense to me. Why do we move towards implementing security measures higher up in the abstraction layers when it should be a core part in any system?
It's too bad you didn't read the article. He answers your exact question.
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)