TLS-Handshake (TLS 1.2)
A TLS-Handshake gets used to exchange keys to setup an encrypted communication.
Client Server
|<--- TCP-Handshake --->|
| |
(1) |----- ClientHello ---->|
| |
|<---- ServerHello -----| (2)
|<-- ServerHelloDone ---|
| |
(3) | |
| |
(4) |-- ClientKeyExchange ->|
| |
(5) | | (5)
| |
(6) |-- ChangeCipherSpec -->|
|------ Finished ------>|
| |
|<-- ChangeCipherSpec --| (6)
|<------ Finished ------|
| |
|<-- e.g. HTTP / FTP -->|
The following steps show the behavior if RSA key exchanges gets chosen (via the cipher suite), but there are also other methods for key exchange like Diffie-Hellman.
(1) Sends supported TLS versions, supported cipher suites and client random
(2) Sends chosen TLS version, chosen cipher suite, server certificate and server random
(3) Verifies the server certificate via the mentioned issuer CA
(4) Sends the encrypted (with public key of server) pre-master secret
(5) Generates symmetric session key based on client random, server random and pre-master secret
(6) Switches to communication specified via chosen cipher suite
CA (Certification Authority)
Instead of just exchanging raw keys, certificates are getting used to validate the opponent.
To find out if a received certificate is trustworthy we have to go down the chain of trust. The server will actual not only send us the leaf certificate, but also all intermediate certificates. The root certificates to validate the path are stored on the local machine.
An X.509 certificate contains e.g.:
– subject name
– subject public key (used to decrypt the hash of the following certificate in the chain)
– issuer name
– issuer signature / fingerprint (encrypted hash of certificate with issuer private key)
– expiration date
Example: www.google.com
Goole Trust Services - GlobalSign Root CA-R2 (root certificate, on local machine)
|--> GTS CA 101 (intermediate certificate, send by server)
|--> www.google.com (leaf certificate, send by server)
Path validation: To check if ‘GTS CA 101’ is trustworthy we have to take the public key of its issuer ‘GlobalSign Root CA-R2’ and check if that decrypts the fingerprint to the hash of the certificate. We do this until we reach the leaf certificate and just if the whole path is right we should trust the opponent.
FAQ
– Why can a MITM not just sniff the traffic and generate the symmetric session key by its own?
The MITM doesn’t know the private key of the server to be able to decrypt the pre-master secret send by the client and therefore isn’t able to generate the symmetric key.
– Why can a MITM not just replace the public key from the server on the certificate with its own?
When the client verifies the fingerprint of that certificate, with the public key of the certificate one level higher in the chain, the decrypted hash won’t match the hash of the modified certificate.