Comment by zymhan
11 years ago
The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.
11 years ago
The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.
CA-signed certificates don't prove you're talking to who you think you are either as any CA trusted by your browser/OS can sign any certificate.
Yes. That's not perfect. But it raises the bar for forgery to "can sign certificates as a root authority", which is still fairly high. (e.g. I can't do it, and neither can you.) It stops coffee shop/hotel wifi operators and mobile providers from injecting content into your session.
If we encourage users to blindly accept self-signed certificates (giving us end-to-end encryption but sacrificing identification), nothing would stop those actors from altering your HTTPS sessions as easily as they alter your HTTP sessions today. It's throwing the baby out with the bathwater.
You don't need a CA system to solve that problem, though. Take, for example, Convergence[0] which uses a notary system in place of the CA system.
[0] http://convergence.io
This is true for most sites now, but is being solved gradually, with hard-coded certificate pinning already shipping in Firefox and Chrome, and the HTTP Public Key Pinning extension coming soon.
But when you browse over http, you don't know who you're talking to either, so how are self-signed certificates worse than http?
I'm really having trouble figuring out the attack scenario unique to self-signed certificates that you don't have with plain http.
Security-wise, if they are both vulnerable to trivial exploits, how can you say one is "more secure" than another?