The CA is supposed to verify and say "hey this certificate belongs to this company".
What we need is for anyone to setup their cert without a CA (self-signed) and then the CA provides the verification is companies really want it.
This is what happens when you try and dual purpose something. If the certificate was just about encryption then my assumption is that you wouldn't really need CAs.
It's worthless in the face on an active adversary, but it works very well as a countermeasure for passive mass surveillance.
I do think it's a dangerous idea, though. The difference between 'secure' and 'insecure' is (at least partially) understood by most technical and non-technical people, and sometimes they can make a good decision on their requirements. The difference between passive and active adversaries is much more subtle, and I doubt people can think this through with as much clarity.
No, it's not worthless. It /raises the cost/ of an attack, by forcing an adversary to implement a more complicated, expensive MitM attack, instead of simply using passive eavesdropping/packet-sniffing.
And to those bringing up the tired, old rebuttal of this providing "worse" security due to a false sense of protection: that's only relevant if the browser is written idiotically and suggests this is in some way the same security as the fully-authenticated version. They should not be showing a "closed padlock" and changing the address bar color for self-signed SSL!
If enrolling your key in a PKI controlled by world governments seems like a good replacement for a bad private PKI, yes, by all means, pursue DNSSEC as an alternative.
> Only if the middle man was already doing the attack on your first visit to the website.
Keep in mind certificate pinning is a fairly (very!) recent addition to the internet security landscape. Before then MITM more or less completely broke encryption.
> Keep in mind certificate pinning is a fairly (very!) recent
> addition to the internet security landscape
As with much technology it is a re-invention of how we used to do things.
Many corporate websites still use client-side certificates to ensure that the client is talking to the correct server.
In the early days of Internet banking, some bank sites used to do the same; I received a cert from my bank on a shiny 'CD-ROM'. Sadly they discontinued that validation along with publishing their PGP key for secure e-mail. A step backwards.
Like I said, it offers no protection against man in the middle attacks. It doesn’t matter whether it protects against some other techniques because you know, the attacker will just simply use the technique it doesn’t protect against. It is really simple as that.
Encryption without verification only protects you from passive attackers, though. Frankly I fail to see the point, since it's not secure enough for sensitive data, but still has the disadvantages (performance, cache busting) of SSL.
This. It's worse then useless because it's the illusion of security.
It's too bad, because some type of web-of-trust mechanism for HTTP would be an incredible idea - it doesn't solve the trust problem entirely, but it would enable users to share their trust profiles amongst or against trusted individuals.
- Verification - Encryption
The CA is supposed to verify and say "hey this certificate belongs to this company".
What we need is for anyone to setup their cert without a CA (self-signed) and then the CA provides the verification is companies really want it.
This is what happens when you try and dual purpose something. If the certificate was just about encryption then my assumption is that you wouldn't really need CAs.