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.
| 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.
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
and not ?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.