SSL Gently

A lot of people find SSL (and TLS) confusing; hopefully this will help clarify how it works. Before we get started, let's define some terms.

Symmetric Key Encryption

This is what you probably think of when you think of encryption. It's the oldest form of encryption and relies on a shared secret. Basically, if two parties have the shared key and no one else does, they can use that key to communicate without anyone else being able to read what they're saying. This has the benefit of being relatively fast, with the obvious downside of requiring a way to securely share a secret.

Asymmetric Key Encryption

Also known as public key encryption and PKI (though PKI is more than just asymmetric key encryption), asymmetric key encryption uses a pair of keys instead of a single key known by both sides. Of the pair of keys, one is called the public key and the other the private key. As the name suggests, you share the public key with the parties with whom you're communicating, but keep the private key private. Asymmetric key encryption uses math concepts like exponentiation, modular arithmetic and elliptic curves to allow you to encode information with one key and decode it with the other, but not allow anyone who doesn't have the other key to decode it. Don't worry too much if you don't understand modular arithmetic or elliptic curves; crypto libraries will take care of the math for you (while also protecting from vulnerabilities that could be introduced by coding errors). People who want to send information to you that only you can read would encrypt it with your public key and you would then decrypt it with your private key. On the other hand, you can encrypt something with your private key and then people can see that it really is from you by checking it against your public key.

Cipher Suite Basically

just a kind of encryption that you support, similar to announcing protocols that you understand. An example would be AES256, which just says that you're willing to use 256-bit AES (Advanced Encryption Standard)

Digital Signature

A digital signature is a way to prove that something came from you. The basic way that they work is you use a secure hashing algorithm to take a digest of the message that you want to send and then encrypt that digest with your private key. If you're not familiar with digests & secure hashing, all that it means is that you use a function that maps a stream of information of arbitrary length into a sequence of bytes of (frequently shorter) fixed size; the most important features of the function are that given any two messages, it is highly unlikely that they'll map to the same sequence of bytes and, if you make any change to a message, even if it's a single bit, the output value will be vastly different (the goal is for ~50% of the bits to change and for the changed bits to be spread throughout the result)

X.509 Certificate

Often just called a certificate, an x.509 certificate is a way to assert your identity by pairing some information about you (frequently a name, an organization with which you're affiliated, and a location), along with the public key of your public/private key pair. To keep people from messing with the name/key pair in transit, the certificate gets signed. It can either be signed by you, in which case it's called a self-signed certificate, or it can be signed by a certificate authority

Certificate Authority

Frequently abbreviated as CA, a certificate authority is a trusted third party; specifically, you trust the CA when it tells you that a certificate is owned by the entity that claims to own it. Technically anyone can be a CA if they set up a key with which to sign certificates, but that doesn't mean you have to trust them. As an example, if you have a friend named Bill, who tells you that the person you just met is Jill, then Bill is basically taking the same role as a CA.

Trust Chain

A trust chain is basically transitive trust. Basically, a CA doesn't necessarily just assert that a person is why they say they are, they can also assert that that person is trustworthy to identify other people for you. Continuing our example, if Bill tells you that he trusts Jill to identify people, and Jill tells you that a person you're meeting is Steve, then that's a trust chain. You trust Steve's identity because you trust Bill who trusts Jill who asserted that the person is Steve.

Trust Store

I'm not sure how widely this term is used outside of Java, but pretty much everything that does asymmetric key encryption has a similar concept. The trust store is just a central place to store the certificates (and public keys) of the CAs that you trust

Key Store

This stores your certificate and private key and, thus, needs to be protected. This & the trust store cause quite a bit of confusion for folks since, with Java, they're both implemented as keystores.

Ok, I admit, that may have been a fire hose of information, but hopefully you're still with me, because armed with that information the next bit is a fair bit simpler. I'm going to leave out a lot of details (like exchanging pre-master secret information) that's essential to implementing TLS, but just muddies the waters when you're trying to understand how it works at a high level. If you're looking for all of the nitty-gritty details, they're laid out in the TLS RFC.

1. Client Hello - The client sends a message asking to start the TLS handshake, announcing various bits of information like whether it supports compression and what cipher suites it supports
2. Server Hello - The server responds, confirming the use of compression and the cipher suite that'll be used
3. Server Certificate - The server presents its certificate (from its key store) to the client
4. The server asks the client for its certificate if it's doing mutual authentication
5. The server then sends a message that it's finished saying Hello
6. If the server requested the client's certificate, the client provides it
7. The server looks in its trust store for the CA that signed the client's certificate; if it doesn't trust the CA that signed the client's cert, it won't accept that certificate as valid
8. The client generates a message including a random number and encrypts it with the server's public key and then sends it to the server (basically everything sent to the server from this point until the end of the handshake will be encrypted using the server's public key)
9. The client then takes a digital signature of everything that has transpired so far (including the random numbers that have been passed back and forth) using the client's private key, and sends that to the server
10. The server then checks the digital signature provided by the client and, if it matches, then it knows that the client is in possession of the private key associated with the certificate
11. The client & server exchange ChangeCipherSpec messages that basically say that everything from this point will be encrypted with the symmetric key that they agreed upon during the handshake (they switch to symmetric key encryption because it's much faster)
12. The client & server exchange messages to say that they're finished with the handshake; periodically they'll re-send ChangeCipherSpec messages to change the symmetric key that they're using because reusing a symmetric key has a certain amount of risk and the more messages you send with it, the greater the risk