Till this point, communication between Alice's server and Bob's client took place in clear-text format. Which, if intercepted by any party could expose information flowing between the two. While working for the government project (which involved authentication and flow of sensitive information), Alice realized the short comings of clear-text flow of traffic. Though the government system was in their local network and an outsider couldn't simply intercept the traffic, which wasn't the case with Alice's website. Thus Alice thought of transmitting data in encrypted format and implemented Secure Socket Layer (SSL). SSL, predecessor to TLS, was an encryption protocol on top of HTTP, together they are called HTTPS (or HTTP over SSL/ TLS).
As SSL was implemented on top of HTTP, it is possible to encrypt the entire data exposed by HTTP. However, TCP uses the IP address and Port number to make a connection thus IP and Port can't be encrypted. A common practice is to leave domain (or IP address, if used) and port out of encryption scope. On the other hand, rest of the data including URL (baring domain and port), Query string, Path, Headers, and Body are encrypted in transit.
For using encryption in transit, the data should be encrypted and decrypt at both ends of communication. And keeping in mind the intention (integrity and confidentiality of the data) Alice came up with a combination of Symmetric and Asymmetric encryption. Asymmetric encryption is used initially for authentication, further symmetric encryption is used for data transfer (We will look at this in details in the "Handshake" section).
Asymmetric encryption means that encryption and decryption of data needs two different keys. In case of HTTPS, the server keeps one of the keys "the private key" with itself and shares the other one with everyone visiting the website "the public key". This allows only the server to decrypt data sent from the client. As asymmetric encryption is only used in initial authentication process, the client doesn't need to have/ share keys for asymmetric encryption (there are use cases where the client also shares their keys). Though the server shares its public keys, this can in no way authenticates the server, as anybody on the internet can create a set of public/ private keys. The server has to share more information which is then verified by the client with a independent third party.
The server shares all the necessary information in its SSL/ TLS certificate, and the third party to verify the authenticity of the server is called a Certificate Authority. Lets look at these and related terms in brief.
An SSL/ TLS certificate is standard defined (x.509) collection of data which is used for verification of identity, ownership of the public key, and encryption/ decryption of data. Among other things, a certificate contains the Public Key of the server and the Distinguished Name for the parent entity (an organization, an individual) of the server. It also contains information about the the issuer of the certificate.
All this information combined together is used for authentication of server and client in the initial phase (aka SSL Handshake) SSL/ TLS communication.
A trusted third party entity which is responsible for issuing and verifying certificates. During a SSL handshake, a browser ask CAs from a list of CAs to verify the validity and authenticity of a certificate. Only after the verification from a CA, the browser moves ahead with the handshake and further communication.
SSL Handshake
Now that we have a familiarity with CA and Certificates, let's look at the SSL Handshake. An SSL handshake is dependent on the key exchange algorithm used and cipher suite supported by the client and server, the exact steps involved thus changes on the basis of algorithm and cipher suite. Let's look at the steps for RSA key exchange.
We will just look at the SSL handshake and ignore the TLS messages.
- The 'client hello' message: The client sends a "hello" message to the server. The message includes the TLS version supported by the client, the cipher suites supported, and a string of random bytes known as the "client random."
- The 'server hello' message: In reply, the server sends the server's SSL certificate (including the public key), the server's chosen cipher suite, and the "server random," another random string of bytes that's generated by the server. The server keeps the private key with itself.
- Authentication: The client verifies the server's SSL certificate with the CA who issued it. This confirms that the server is who it says it is.
- The premaster secret: The client sends one more random string of bytes, the "premaster secret." The premaster secret is encrypted with the public key and can only be decrypted with the private key by the server.
- Private key used: The server decrypts the premaster secret.
- Session keys created: Both client and server generate session keys from the client random, the server random, and the premaster secret. They should arrive at the same results.
- Client is ready: The client sends a "finished" message that is encrypted with a session key.
- Server is ready: The server sends a "finished" message encrypted with a session key.
- Secure symmetric encryption achieved: The handshake is completed.
Till this point the server and client uses asymmetric encryption, beyond this point the client and server uses symmetric key (session key) for encryption and decryption