3 ms·

So forgive my denseness here, but that can still be broken down into two separate protocols, right? 1) I wish to communicate with foo.com privately, regardless

by acabal 13y ago

So forgive my denseness here, but that can still be broken down into two separate protocols, right? 1) I wish to communicate with foo.com privately, regardless of whether foo.com is really who foo.com claims to be; that is, one time foo.com might be 192.168.0.0, and the next time it might be 192.168.0.1; but either way, regardless of who I'm truly communicating with, I can at least be sure that nobody but the recipient can decode the packets. Then, 2) I can guarantee everything in (1), plus that my the packets I exchange with foo.com are truly the foo.com that resides at 123 Main St., USA. 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.

kaoD 13y ago
It's already separate (check the bottom part of my parent comment). 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_exchange http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...
caf 13y ago
The statement "nobody but the recipient can decode the packets" is meaningless if there are no bounds on who "the recipient" is. 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.
yuliyp 13y ago
The physical analogy falls apart because generally envelopes are tamper-evident against most attackers (i.e. it's hard for a malicious postal worker to take your envelope, open it, read what's there, then repackage it without it being detectable that something fishy happened). With communication protocols over the Internet, the tamper-evidence falls apart. All packets look alike. 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.

by acabal 13y ago

kaoD 13y ago

It's already separate (check the bottom part of my parent comment). 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_exchange http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...

caf 13y ago

The statement "nobody but the recipient can decode the packets" is meaningless if there are no bounds on who "the recipient" is. 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.

yuliyp 13y ago

The physical analogy falls apart because generally envelopes are tamper-evident against most attackers (i.e. it's hard for a malicious postal worker to take your envelope, open it, read what's there, then repackage it without it being detectable that something fishy happened). With communication protocols over the Internet, the tamper-evidence falls apart. All packets look alike. 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.