How SSL Works
Secure Sockets Layer (SSL) is the public -key encryption approach. SSL is an Internet security protocol used by Internet browsers and Web servers to transmit sensitive information.
SSL doesn’t authenticate a user.
Look for the “s” after “http” in the address whenever you are about to enter sensitive information & a small padlock in the status bar at the bottom of the browser window.
How SSL handshake works:
Like XYZ Inc., intends to secure their customer transactions
Step 1: Client makes a connection to xyz.com on an SSL port, typically 443. This connection is denoted with https instead of http.
Step 2: xyz.com sends back its public key to the client. Once client receives it, his/her browser decides if it is alright to proceed on the basis of below points:
- the certificate comes from a trusted party (like VeriSign);
- the certificate is currently valid; and
- the certificate has a relationship with the site from which it’s coming.
Step 3: If the client decides to trust the certificate, then the client will be sent to xyz.com his/her public key.
Step 4: xyz.com will next create a unique hash and encrypt it using both the customer’s public key and xyz.com’s private key, and send this back to the client.
Step 5: Customer’s browser will decrypt the hash. This process shows that the xyz.com sent the hash and only the customer is able to read it.
Step 6: Customer and website can now securely exchange information.
Certificates and Public Key Infrastructure
During the handshake, the service also sends its SSL certificate to the client. The certificate contains information, such as its expiration date, issuing authority, and the site’s Uniform Resource Identifier (URI). The client compares the URI to the URI it had originally contacted to ensure a match, and also checks the date and issuing authority.
Every certificate has two keys, a private key and a public key, and the two are known as an exchange key pair. In brief, the private key is known only to the owner of the certificate while the public key is readable from the certificate. Either key can be used to encrypt or decrypt a digest, hash, or other key, but only as contrary operations. For example, if the client encrypts with the public key, only the site can decrypt the message using the private key. Similarly, if the site encrypts with the private key, the client can decrypt with the public key. This provides assurance to the client that the messages are being exchanged only with the possessor of the private key because only messages encrypted with the private key can be decrypted with the public key. The site is assured that it is exchanging messages with a client that has encrypted using the public key. This exchange is secure only for an initial handshake, however, which is why much more is done to create the actual symmetric key. Nevertheless, all communications depend on the service having a valid SSL certificate.
(Refer to here)