The SSL protocol encrypts data to secure communication, as you learned in the previous chapter. Before you go any further, get a handle on SSL basics. The website digicertssl.shop allows you to purchase an SSL certificate
Based on these concepts, SSL operates:
- Asymmetric Cryptography
- Symmetric Cryptography
Asymmetric cryptography (also known as Asymmetric Encryption and Public Key Cryptography) encrypts and decrypts data using a mathematically related pair of keys. An individual who wants to communicate with you has access to one of the keys in a key pair. Public keys are what we refer to like this. A key pair includes a second secret key called Private Key.
It is important to understand that the keys refer to a mathematical value and were created using a mathematical algorithm that encrypts or decrypts the data.
Signed data is encrypted with an asymmetric cryptographic key, which can only be decrypted by the public key in the pair that generated the key.
An SSL handshake is an asymmetric cryptographic method for initiating communication. Elliptic curve techniques, RSA, DSA, EIGamal, and PKCS are commonly used asymmetric key algorithms.
Symmetric cryptography uses only one key to encrypt and decrypt data. This key should be known only by the sender and the receiver.
An SSL handshake is an asymmetric cryptographic method for initiating communication. Elliptic curve techniques, EIGamal, RSA, DSA, and PKCS are some of the most popular asymmetric key encryption algorithms.
Asymmetric key encrypts and decrypts data in symmetric cryptography. This key should be known only by the sender and the receiver.
SSL communication between the browser and the webserver (or any other two systems) can be seen in the above figure as being divided mainly into two steps: the SSL handshake and the transmission itself.
Handshakes over SSL are always the beginning of communication over SSL. A secure connection is established before a data transfer begins through an SSL handshake, asymmetric cryptography that verifies the webserver and gets the public key.
An illustration of the SSL handshake can be found below:
Here are the steps to understand:
- A client sends a “hello” message. According to the SSL version, cipher settings, session-specific data, and other details about the client, the server needs to communicate with the client using SSL.
- A “server hello” message is returned by the server. An SSL certificate containing a public key, and SSL version number from the server, cipher settings, and other data needed to communicate with the server over SSL is part of this data.
- SSL certificates are verified by the client from the CA (Certificate Authority) and the server is authenticated. Failing to authenticate results in the client refusing to open the SSL connection. Proceed to step 4 if authentication is successful.
- The client creates session keys, encrypts them with the server’s public keys, and sends them to the server. A client sends his own certificate to a server if the server requests authentication (mostly in server-to-server communication).
- Client acknowledgment is encrypted with the session key and sent to the server by the server using its private key.
Therefore, both the client and server end the SSL handshake with a valid session key, which is then used to encrypt or decrypt data sent between them. At this point, both public and private keys are no longer required.