Browser and HTTPS

• HTTP — uses port 80
• HTTPS — uses port 443
• HTTPS pages typically use one of two secure protocols to encrypt communications — SSL (Secure Sockets Layer) or TLS (Transport Layer Security).

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.

• Digital signatures
  A digital signature is a mathematical technique used to validate the authenticity and integrity of a message, software or digital document.
  It is based on public key cryptography, also known as asymmetric cryptography.Using a public key algorithm such as RSA, one can generate two keys that are mathematically linked: one private and one public.

To create a digital signature, signing software (such as an email program) creates a one-way hash of the electronic data using private key. The client that receives this message verifies the integrity by running the algorithm using the public key.

Today there are three types of certificates that offer 3 levels of user trust for SSL/TLS negotiations:

1)Domain Validated certificates (DV) — Less trusted

Domain Validated certificates are certificates that are checked against domain registry. There is no identifying organizational information for these certificates and thus should never be used for commercial purposes. Visitors to a website with DV certificates cannot validate, via the certificate, if the business on the site is legitimate and thus often DO NOT trust this type of certificate. It is recommended using these types of certificates where security is not a concern, such as protected internal systems.

2)Organization Validated certificate (OV) — Trusted

The CA checks the right of the applicant to use a specific domain name PLUS it conducts some verification of the organization. This is the standard type of certificate required on a commercial or public facing website. OV certificates conform to the X.509 RFC standards and thus contain all the necessary information to validate the organization.

3)Extended Validation certificates (EV) — Most trusted

The Certificate Authority (CA) checks the right of the applicant to use a specific domain name PLUS it conducts a THOROUGH verification of the organization. The Green Bar on Browser cannot be triggered without a trusted EV certificate.

How client verifies the SSL certificate?

• Client must have the SSL certificate of CA(Certificate Authority).
• Using that public key the client verifies whether the signature in the certificate provided by the requested domain.

For example:

http://www.google.com has acquired a SSL Certificate from Symantec.
When Browser running on my machine request data from google.com, my browser asks for the SSL certificate.
Google will send the certificate to my browser as response. The browser now needs to verify the signature inside the
certificate. For that it requires Symantec’s public key. Browser search for Symantec’s certificate in its local repository or tries to download it if

it is not present. Once it gets the Public key of Symantec, it checks the signature in the certificate and verifies it.

SSL Handshake

1)The client sends the server the client’s SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.

2)The server sends the client the server’s SSL version number, cipher settings, session-specific data, andother information that the client needs to communicate with the server over SSL.The server also sends its own certificate. But if the client is requesting a server resource that requires client authentication, the server requests the client’s certificate.

3)The client uses the information sent by the server to authenticate the server. It verifies the SSL certificate using the public key of CA. If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to step 4.

4) Using all data generated in the handshake thus far, the client creates the pre-master secret for the session, encrypts it with the server’s public key (obtained from the server’s certificate), and then sends the encrypted pre-master secret to the server.
If the server has requested client authentication (an optional step in the handshake),the client also signs another piece of data that is unique to this handshake and known by both the client and server.
In this case, the client sends both the signed data and the client’s own certificate to the server along with the encrypted pre-master secret.

5)If the server has requested client authentication, the server attempts to authenticate the client.
If the client cannot be authenticated, the session ends.If the client can be successfully authenticated, the server uses its private keyto decrypt the pre-master secret, and then performs a series of steps to generate the master secret.

6) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.

7) The client sends a message to the server informing it that future messages from the client will be encrypted with the session key.It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.

8) The server sends a message to the client informing it that future messages from the server will be encrypted with the session key.It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.

How browser verifies the Server certificate?

1) Your web browser downloads the web server’s certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.

2) Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server’s certificate was indeed signed by the trusted certificate authority.

3) The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.

4) Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key