7 ms·

I've been wondering lately why SSL ties both encryption between two parties and the identies of those two parties together. A genuine question borne of genuine

by acabal 13y ago

I've been wondering lately why SSL ties both encryption between two parties and the identies of those two parties together. A genuine question borne of genuine ignorance on my part: why are these two concepts tied to the the same protocol? Why can't we have two separate systems? One to ensure two parties communicate secretly with each other, and another to somehow verify the real-life identities of those two parties? Why did those to seemingly separate concepts evolve as one? If we could separate them, it seems we could solve a lot of low-level security problems online: sites could have cost-free, CA-free self-signed certs to ensure only that packets between the client and server are secure/private; then separately, there could be a different system to ensure that the client is really, truly communicating with the Bank of Their Nation, Inc., and not a scammer from Nigeria. How did identity and privacy become conflated, and how can we separate those to provide monetary-cost-free eavesdropping protection in the future?

kaoD 13y ago
Because encryption's purpose is completely defeated if you don't know who you are talking to. 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 A -(encrypted)-> B and not A -(encrypted)-> MITM -(encrypted)-> B ? 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.
- pyre 13y ago
  | They look the same Unless you have a known, valid signature.
  - kaoD 13y ago
    Did you read the rest of the comment? Specially the part below: > 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. How could you update your certificate list over the wire making sure you're getting the correct certificates? Talking with a known authority, i.e. the CAs. 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.
- 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.
andrewflnr 13y ago
I never got that deep into SSL, but I seem to recall there are cipher suites that allow unauthenticated encryption. I could be wrong. Also, what everyone else said.

by acabal 13y ago

kaoD 13y ago

Because encryption's purpose is completely defeated if you don't know who you are talking to. 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 A -(encrypted)-> B and not A -(encrypted)-> MITM -(encrypted)-> B ? 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.

pyre 13y ago
| They look the same Unless you have a known, valid signature.
- kaoD 13y ago
  Did you read the rest of the comment? Specially the part below: > 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. How could you update your certificate list over the wire making sure you're getting the correct certificates? Talking with a known authority, i.e. the CAs. 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.
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.

andrewflnr 13y ago

I never got that deep into SSL, but I seem to recall there are cipher suites that allow unauthenticated encryption. I could be wrong. Also, what everyone else said.