SSL in a nutshell

  • When Alice first contacts Bob in clear text, Bob returns his public (encoding) key.
  • Alice generates a one off symmetric key (a session key),
  • Alice then encrypts her one off symmetric key using Bob’s public asymmetric public encryption key, and sends the encoded message back to him.
  • Note that once she’s encrypted the message with Bob’s public key, neither she, nor anybody who intercepts it along the way, can decrypt it with the publicly available decryption key.
  • Bob uses his very safely kept private key to decrypt Alice’s messages, extracts the one-off/session symmetric cipher key,
  • From there on Alice and Bob can communicate using the session key he just received.

That’s all good and fine – we’ve covered how Asymmetric Encryption can help with communicating between a client and server in a secure way – but we’ve sort of digressed. What’s this got to do with Certificates? The answer is…a lot.

Asymmetric algorithm takes care of one part – the actual communication – but it doesn’t guarantee whom Alice is communicating with. There’s nothing in the above system that would stop Alice from setting up an encrypted communication conduit with her bank (Bob), give them all her information encrypted with a session key of her choosing – only to find out that all this time she was communicating (securely) with…someone else (Eve).

In other words, encryption is not enough: Alice needs some kind of guarantee from a 3rd party authority – some kind of authority that will check Bob’s claims to to being who they say they are, and issue them with an untamperable certificate guaranteeing Bob as being on the level.

That’s where certificates come in.