Tag Archives: SSL

How does HTTPS works?

How does HTTPS works?

  1. Client request for secure Https  page.
  2. Web server respond by sending certificate with public key.
  3. Client checks the validity of the certificate and create a symmetric session key using the public key and sends it back to Web serer.
  4. Web server decrypt the symmetric session key using it’s private key and sends page encrypted using the symmetric session key.
  5. Secure session has now been established between Client browser & Web server.


HTTPS pages typically use one of two secure protocols to encrypt communications – SSL (Secure Sockets Layer) or TLS (Transport Layer Security). Both the TLS and SSL protocols use what is known as an ‘asymmetric’ Public Key Infrastructure (PKI) system. An asymmetric system uses two ‘keys’ to encrypt communications, a ‘public’ key and a ‘private’ key. Anything encrypted with the public key can only be decrypted by the private key and vice-versa.

The ‘private’ key should be kept strictly protected and should only be accessible the owner of the private key. In the case of a website, the private key remains securely ensconced on the web server. Conversely, the public key is intended to be distributed to anybody and everybody that needs to be able to decrypt information that was encrypted with the private key.



Leave a comment

Filed under .Net, ASP.Net, C#, WCF

How SSL Works

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)

1 Comment

Filed under .Net