As you learned in the previous chapter, SSL encrypts data to ensure communication is secure. Learn the basics of SSL benefits before moving forward. SSL certificates can be purchased from the website of DigiCert SSL.
SSL operates according to these concepts:
- Cryptography with asymmetrical keys
- The Cryptography that is symmetric
Cryptography that is asymmetric
Asymmetric cryptography (also called Asymmetric Encryption or Public Key Cryptography) uses a mathematically-related pair of keys to encrypt and decrypt data. A person with access to a key pair can communicate with you. We call these public keys. In addition to the Public Key, a key pair includes a Private Key.
This is important to understand as keys refer to mathematical values and were created using an algorithm that encrypts or decrypts data.
It is only possible to decrypt the asymmetric cryptographic key with the public key in the pair that generated it.
SSL handshakes are symmetric methods used to initiate communication. Asymmetric key algorithms commonly used include elliptic curves, RSA, DSA, EIGamal, and PKCS.
The symmetric algorithm encrypts and decrypts data using the same key. There should only be two parties who know this key. Initiating a communication through an SSL handshake is asymmetric cryptographic in nature. Among the most popular asymmetric key encryption algorithms are elliptic curve techniques, EIGamal, RSA, DSA, and PKCS.
When symmetric cryptography is used, a symmetric key encrypts and decrypts data. There should only be two parties who know this key.
The SSL handshake between the browser and the web server (or any other two systems) can be seen in the above figure as being divided mainly into two steps: the transmission itself and the SSL handshake.
The SSL handshake is always the first step in communication over SSL. An SSL handshake establishes a secure connection before any data transfer begins, verifying the web server and retrieving the public key of the web server.
Voici How the SSL Handshake Looks:
Understanding each step is as follows:
- The client sends a “hello” message. A server needs to use SSL to communicate with a client, depending on the SSL version, cipher settings, client-specific data, and other factors.
- The server responds with a “server hello” message. Part of this data is an SSL certificate that includes a public key, a version number from the server, cipher settings, and other details that make SSL communications with the server possible.
- The client verifies SSL certificates with the CA (Certificate Authority) and authenticates the server. The client will not open an SSL connection if it is unable to authenticate. Assuming authentication is successful, move onto step 4.
- With the server’s public keys, the client encrypts session keys, which are transmitted to the server. When a server requests authentication from a client (mostly in server-to-server communications), the client sends his own certificate to the server.
- By using the private key of the server, the server encrypts client acknowledgement and sends it to the client.
Thus, both clients and servers need a session key to encrypt or decrypt data sent between them during a SSL handshake. Neither public nor private keys are required at this point.