1

As I understand it, if Alice and Bob wants to communicate securely, they must first agree on the protocols that will be used. Then they must confirm that they are indeed communicating with each other. This is done via certificates signed by some trusted third party. The public key and hashing algorithm used by the third party are already stored on your computer. Alice then sends Bob her certificate and Bob sends Alice his certificate. They both verify the certificate's signature using the third party's public key. If it's valid, they start their key exchange and such. However, what is in those certificates that confirms their identity? I imagine it can't just be "Hi, this is totally Bob/Alice, trust me." I would imagine that Bob's certificate must contain Bob's public key, but wouldn't it be unsafe if Bob used the same public key everytime? Wouldn't it be better if he could use a different public key for every client?

Also, does a website (such as Amazon) have only one certificate that it sends to all clients, or is a new certificate signed by the third party for every client that connects to the website?

I would also appreciate some sources on the basics of the application of asymmetric cryptography if anyone has some simple sources (I'm still a dummy though).

  • I am not asking how the key exchange protocol works, but rather how the verification of identities works. – Dasherman Jan 5 '15 at 16:13
  • Nevertheless, the answer you seek is right there. The mathematical intertwining of the public and private key, such that the act of decryption using one verifies that the other party is in possession of the other key (which is their identity; they are the key master, so to speak). – gowenfawr Jan 5 '15 at 16:16
  • Does this mean that a server send the same certificate to every client? Or does this mean that mean that the CA must sign a new certificate containing a new public key for every new client connecting to the server? – Dasherman Jan 5 '15 at 16:22
  • Server sends same public key to everyone. Public key is useless except when applied to data paired with private key, so access to public key does not allow anyone to MITM. Server keeps private key... private. – gowenfawr Jan 5 '15 at 16:25
0

the wikipedia article especially the svg image is a good base to start with,

1 fundamental thing you have to understand is that for PKI, it does not matter if everyone has the Public key since you can only use it to ENCRYPT inormation intended for ME with it (its like I give everybody a lockbox only I have the key of)

and the private key can not be deduced from the public key. (cryptographic 'law')

  • You can also use the public key to verify a signature right? And if I understand correctly, that's what is stored about every CA on the computer right? – Dasherman Jan 5 '15 at 16:18
  • @Dasherman Normally, a different public key (RSA signatures and RSA encryption happen to be similar, but they aren't the same, you shouldn't use the same key for them, and in general signature and encryption algorithms need not be related at all), but yes, a signature algorithm public key can verify things signed with the corresponding private key. In general, the whole point of a public key is that it's public; the distinguishing feature is that the whole world can know it and it's still perfectly secure. – cpast Jan 5 '15 at 17:21
  • What is the private key used for then? (The server's private key that is associated with the public key that is part of the certificate) I imagine it would not actually be used for the key exchange then (I'm thinking elliptic curve diffie hellman), but only for signing the message used for the key exchange – Dasherman Jan 5 '15 at 17:33
0

There are root Certificate Authority (CA) servers that your browser uses. It goes a little like this.

Site: Hi I'm BOB!

Browser: Mr. Root CA server signed this certificate that Bob gave me. I fully trust the CA's signature, and I checked that it's a valid signature. Therefore, you are Bob. Hi Bob!

Two pitfalls:

  1. Compromise of root CA signatures, which are then used to produce bogus certs. I.E. Leaking of keys, broken encryption. A mitigating factor: browser manufacturers will blacklist compromised root CAs.

  2. Rogue root CAs. There are CAs owned by governments, and other companies. If they decided to violate the user's trust by assigning the certificate to their own MITM website, no one would really notice. A mitigating factor: SSL observatory, by the EFF.

This is a pretty simplistic view of things, but I hope this helps.

  • What is in that certificate that ensures the browser that Bob sent it? Anyone could just copy the certificate and send it. – Dasherman Jan 5 '15 at 16:30
  • Because SSL certs are bound to hostnames. You need the hostname + signed certificate. It's like your driver's license. Anyone can steal it, but they'd have to look like you for it to be actually useful. – Ohnana Jan 5 '15 at 16:55
  • How do hostnames work then? Can't a server just pretend to have a different address then it really does and steal the certificate of the server that actually belongs to that hostname? I imagine it being the same as a letter: I put my address on the envelope and send it, but that doesn't mean I actually live there. – Dasherman Jan 5 '15 at 17:10
  • @Dasherman Names and addresses are different. You can put someone else's return address on a letter you send, but you won't get the replies sent to that address unless you live there, or at least spend your days on the street in front of their house (and the police will see that). Similarly, only a machine on the same network segment can spoof TCP. However there are attacks on DNS than might deceive a client into connecting to your address instead of the proper one; then if you have a copy of the cert but not the privatekey you can't validly sign and can't complete the handshake. – dave_thompson_085 Jan 5 '15 at 18:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.