What are asymmetric encryption keys?
Two passwords, rather than just one, are created to secure a message. If I encrypt the message with password A, it can only be decrypted using password B. If I encrypt the message with password B, it can only be decrypted using password A. One of these is the public key, which you can give out to everyone, and one is the private key, which you keep to yourself.
How are public and private keys used?
When you send a message to someone, you can encrypt it with your private key, and they can decrypt it with the public key they received earlier; the advantage here is that they're sure you generated the message (as you're the only one holding the private key;) the disadvantage is that anyone with the public key can read what you've sent. So instead, you exchange keys with everyone you communicate with; you get their public key, they get yours. Now when they send you a message, they encrypt it with your public key, not their private key; you have the private key, so you can open it, but nobody else can. The advantage is that only the intended recipient can read the message, but now they're not sure it really came from the right person, unless some other signature is appended; the sender will also encrypt a known signature (another topic) with their private key, which nobody else could do, and send that in the message. Now you know it came from the right person, and you know nobody else read the message.
What's a man-in-the-middle attack?
Think of it this way: you pick up your phone and call a business to order some flowers; unbeknownst to you, your neighbor has your phone line routed through his house -- every time you call someone, you may or may not wind up calling him, and he'll turn around and call the person you were trying to reach. Your information might be passed along accurately, but recorded for later use, or it might even be changed along the way. Encryption is great, but it requires the two sides to agree on passwords; if you've never done business with them before, how do you go about it?
The problem is that you don't have public keys from everyone you expect to communicate with, and the very act of exchanging those keys could be susceptible to man-in-the-middle attacks. To pick up the earlier analogy, when the business picks up, they would give you their public key; you would use their public key to encrypt a response that included your public key; after that, they would use your public key to encrypt messages to you, and you would use theirs to encrypt messages back to them. Your communication would be secure. But if your neighbor is relaying messages (by muting one line while talking on the other) he could very well give you his public key, instead of the business', then decrypt your response to get your key, re-encrypt it, and give it to the business; he can now understand everything either of you are saying, even though your messages are encrypted -- encrypted, but not end-to-end.
What are trusted/root Certificate Authorities?
The supposed solution to this problem is a solution to the problem of trust in general: to prove you can be trusted, you prove that you've been vouched for by someone the other party trusts. This may take several jumps: the business may provide me with a statement signed by my uncle, vouching for them; they also provide me with a document signed by my father, vouching for my uncle, and guaranteeing that my uncle's signature really is what it says it is; I then check the signature reportedly from my father, and check it against what I know to be his signature. If it checks out, then I know that my uncle's signature is also correct, and that the chain of trust is unbroken.
Your browser comes equipped with a somewhat long list of trusted root authorities; as long as a website can prove that their public key was certified by one of those authorities (directly or indirectly,) you should be able to trust that the public key you're receiving is really coming from the entity you think it is. A man in the middle shouldn't be able to generate his own keys and have them certified by a trusted authority as coming from the business.
What could possibly go wrong?
It only takes one shady intermediary to throw the whole thing off; if you trust an authority that will, for the highest bidder, sign every and any public key as really coming from various well-known businesses, someone out there will happily set up man-in-the-middle attacks and be able to prove to your satisfaction that they are someone they are not.
You may have heard of some of the companies listed in your trusted root list -- Verisign, for example, or even Thawte. There are many more in that list, though, that you've never heard of. Have you ever checked up on the trustworthiness of those you do recognize? If you check out Verisign's website, how easily can you find proof that they're as careful as they claim -- that for every certification request, they're painstakingly researching the request, making sure the request is coming from the right person, that they own the domain name of the website you're trying to access, etc.? Could they sometimes be rubberstamping requests? For example, you could access a site not intended to be secured, and a man in the middle could get keys certified as coming from that domain name; if all the Certificate Authority is bothering to do is make sure only one request per domain is approved, this will be the first -- and your trust will be broken.
Certificates cost a hugely variable amount of money, though they're rarely cheap; the person getting certified is paying for it, not you. You are, for free, expecting a Certificate Authority to do its job, and they are, in turn, performing a service for a paying client -- there's an issue of conflict of interest here.
Don't expect that a Certificate Authority-approved site is necessarily a reputable business; the job of the CA extends only so far as making sure that the domain name you accessed is owned by the company that requested that their public keys be signed. They may very well be crooks, but at least they're jumping through the hoops to hoodwink you.
Also don't expect that the site you're accessing, even if secured, is really the one you meant to access. For example, you get an ad in the paper about a flower shop with a creative name; you assume they must have a website, so you type in the name of the shop into your favorite search engine, and presto -- you've arrived at their site, which is secured, and you buy some flowers. Are you sure that website, even if it shares a name with the flowershop advertising in the paper, is really owned by the same people? If the ad in the paper gives you a website address, that's slightly comforting -- but are you sure the newspaper verified that the information in the ad was accurate, and really coming from the owners of the shop? Can a crook post an ad in the paper?
As I said earlier, there's a very long list of trusted root authorities in your browser, many of which you've never heard of. In the end, it all comes down to trusting the browser manufacturer, who provided you with that initial list -- is it their job to know how to run a Certificate Authority? Do you know that they did a background check on each and every one of those authorities, to make sure they were properly doing background checks for every request they received? Are they continuing to check up on these authorities, over the years, to make sure they still earn their trust? Do you trust your software vendor?
How much does it cost to get a certificate?
Cost varies; although any of the Certificate Authorities in the default list of trusted roots would be good enough, businesses fall into the trap of buying from the well-known Authorities, such as Verisign of Thawte, even though customers' browsers make no distinction. The famous Authorities cost more, of course -- well over a thousand dollars for a single certificate, which expires after one to three years. If you run several websites, you'll pay for each one, even though they've already done the legwork of checking up on you and subsequent requests (for other domain names, or for renewals) should, physically, be less expensive. (But we all know that retail prices have very little to do with wholesale costs, in any business.)
Why do businesses buy certificates?
It all comes down to fear. There's a legitimate reason for certificates, of course -- but for the business, the main justification is that customers are afraid of the warnings they see when they visit a website whose keys weren't signed by one of their trusted roots. Customers don't typically understand what's going on, but they do understand the exclamation marks, the words "trust" and "encryption", and will refuse to do business with websites not signed by a trusted CA. Customers have every reason to want signed certificates, of course, as they solve the man-in-the-middle problem; but the shift in responsibilities means customers pay businesses to pay certificate authorities to certify them; I haven't found evidence for or against this (I've found very little on how the default list is compiled by any software vendor,) but in turn certificate authorities could be paying software vendors to include them in the default list of trusted authorities, which customers are also paying them for (double profit?) The software vendor who built the browser controls two things: the default list of trusted root authorities, and the way in which warnings about the lack of trusted certification is presented to the end-user; the warning will be as scary (and mysterious) as possible both for the customer's "protection" and for the benefit of the trusted root CA's, who stand to profit from customer fear; in turn, software vendors may also benefit if they're paid to include CA's in their list. The barrier to entry for a new root CA is enormous -- how do you build trust with customers who have no way of trusting you but by trusting other authorities to vouch for you, considering those authorities have an interest in not vouching for you to protect their own business? A single warning that a connection may not be secure, which most users don't really fully understand, and a well-intended attempt at solving the problem of trust, have now turned into a whole industry worth billions of dollars, at high risk of anti-competitive behavior and conflict of interest.
Can't we self-sign certificates?
A site owner can self-sign certificates, certainly, but customers will most likely get a warning about it. There's nothing inherently insecure in this, except that the customer still has no way to make sure that the certificate they're accepting is really from the site owner, not from a man in the middle. If customers get used to accepting non-trusted certificates from a particular site (or from any and all sites), it makes it that much easier for an attacker to fake a certificate and fool the customer into accepting it. Site owners who provide instructions on accepting such certificates are helping users access their site -- but they're also undermining that customer's ability to secure their own transmissions by breaking them of the habit of being mistrustful.
Who can you trust?
Ultimately, you have to trust someone; if browsers came with no trusted root authorities, you would have no mechanism to verify that the first CA key you downloaded was really from that CA -- the process of establishing a trust chain could be under attack from the get-go. If, as a software vendor, you're going to include one trusted root, you might as well include several (hundred) and make life easier for the customers as they browse the wider Internet. But the issue of establishing that trust, and the assumption on the part of customers that their browser trusts all the CA's it should, and none that it shouldn't, is problematic. Considering how blindly most users trust the default list of root authorities, one could wonder if perhaps the entire process of encryption is really nothing but an academic exercise.
