Sybren Stuvel wrote:
I'm curious. Can you give me an example? AFAIK you need to know who
you're talking to before transmitting sensitive information, otherwise
you could be talking to anybody - and that's just what you wanted to
prevent with the encryption, right?
Encryption has multiple meanings. In the general sense, it encompasses all
of cryptography and the information security properties crypto provides.
This meaning is rather imprecise and you run into problems using it to
answer questions like yours. I won't encryption this way again in this
post.
In a more specific/technical sense, encryption protects the privacy of
transmitted information, preventing third-party eavesdropping. It makes no
guarantees who's on the other end of your encrypted pipe. Block cipher
modes (CBC-DES, CTR-Rijndael/AES, etc) and asymmetric cipher modes
(RSA-OAEP) are examples.
Integrity guarantees that the data sent is the same as the data received.
Authentication verifies the party on the other end of your pipe. This is
the primary purpose of SSL certs, authenticating web sites to browsers (you
get data encryption too, but that's somewhat less important). Note that it
doesn't verify the party's identity or trustworthiness, only that they know
a particular secret. The assumption is that if the certificate system is
setup correctly, possession of that secret makes them trustworthy (or
rather, you can trust the site because their secret proves that a cert
authority somewhere trusts them in some fashion). Trustworthy for what is
never defined.
If that sounds convoluted or illogical, it is. "Ten Risk of PKI" is a good
intro to why this chain of trust isn't all it's cracked up to be. It's
good reading to understand exactly what you benefits you get from an SSL
connection.
http://www.schneier.com/paper-pki.html
So in a long-winded way, I've answered your question. The short and sweet
of it is, yes, SSL is meant to prevent you from "talking to anybody". In
that it succeeds* -- but only so far as making sure the site you're talking
to paid some money to one of the dozens of cert authorities for a minimal
background check. You've gone from "anybody" to "anybody with a couple
hundred bucks and spare time to blow".
*at least, until the end user completely ignores the warning dialogs and
accepts whatever invalid cert he's presented with.
Of course if you control the server and serve a small clientele who already
trust you, you can have clients import your own cert so they really can be
sure who they're talking to -- as long as your master key remains secret.
Watch out for hackers and disgruntled employees.
The moral of this story is: computer security is an ugly, complex business.
