http vs https:


 http is application layer protocol in OSI model used for data communication over world wide web.

category	HTTP	HTTPS
port:	80	443
Data Encryption:	no,just sends plain text	yes,encrypts the data
safer?	NO	YES.

Hypertext Transfer Protocol Secure(HTTPS) is a communication protocol for secure communication over a computer network, with especially wide deployment on the Internet.

How https provides secured communication?

Normal HTTP traffic is unencrypted and travels over TCP port 80 (by convention). Because it is "sent in the clear," it is vulnerable to what are called "man in the middle" attacks. Using our favorite cryptographic personas (Alice, Bob and Chuck), we can see how that would work.

                                    Alice is a user, and Bob runs a website. Chuck runs an Internet cafe. Alice goes to the cafe, and uses the free Wi-Fi Chuck provides. What Alice doesn't know is that Chuck is sniffing all the network traffic that goes through his Wi-Fi router. When Alice sends credit cards, usernames, passwords, and other sensitive information to Bob's site, Chuck sees them too, and he can use them for his own fiendish purposes. Or Chuck can even set up his router to send Alice to a fake site Chuck runs, that spoofs Bob's site.

               HTTP, Chuck (center) can potentially extract sensitive information.

 HTTPS solves these problems by offering encryption to prevent sniffing and authentication to prevent spoofing. To understand how, you need to understand how public key encryption (PKE) works at a basic level.

                                In PKE, an entity (a company, individual, etc.) creates a public and a private key that are linked to each other. Using the public and private key, you can do a number of interesting things. Let's suppose that Bob has generated a public and private key, and given the public key to Alice.

• Alice can use the public key to encrypt a message, and only Bob can successfully decrypt it.
• Bob can take a message, "sign" it with his private key, and Alice can use the public key to ensure that it came from Bob, and the contents haven't been altered.

When Alice connects to Bob's site using an HTTPS connection (traditionally port 443), the first thing Bob's site does is to send down the public key for the site. In most cases, Bob got his key (wrapped in something called a certificate) from a vendor such as VeriSign or Thwate. These firms made sure Bob is who he said he is, and signed his public key with their private key.

When Bob's server sends his certificate to Alice's browser during the first stage on an HTTPS connection, Alice's browser does a few things:

• It makes sure that the certificate is for the site that Alice tried to connect to. If there's a mismatch, Alice will see one those error messages that warns a site isn't what the certificate says it is (more on certificates below).
• It makes sure that the certificate hasn't expired (most certificates are issued for a period of a year.)
• It makes sure that the certificate was signed by a "trusted" authority like VeriSign.

Browsers ship with a set of public keys for the major certificate authorities. If a certificate is received that wasn't signed by one of the big players (such as in so-called "self-signed" certificates), you'll get a different warning message from your browser.

Now that Alice's browser has Bob's certificate, which includes Bob's public key, it generates a unique cryptographic key (in encryption jargon, a one-time pad) and encrypts it with Bob's public key. The browser sends the encrypted key back to Bob's server, which uses Bob's private key to decrypt it. From then on, all the traffic back and forth is encrypted using this one-time key.

HTTPS keeps Alice's information secure.

This neatly solves all the problems that let Chuck make mischief. If Chuck intercepts the first return message from Bob's server, all he gets is Bob's HTTPS certificate, which he can get himself by making a connection. If Chuck intercepts Alice's response with the one-time key in it, he can't decrypt it because he doesn't have Bob's private key. All the traffic after that is encrypted with that one-time key, so Chuck can't read that either.

If Chuck tries to spoof Bob's server, he won't have a certificate signed by a trusted authority that matches the site's web address. If Chuck sends back a bogus certificate, it won't be signed correctly and the browser will put up a warning. Chuck can't use Bob's certificate, because he won't be able to decrypt the one-time key coming back to him.

By offering (or forcing) users to use HTTPS, sites like Twitter are making sure that the connections are safe from eavesdropping and the users can be assured they're actually talking to who they think they are. HTTPS has been a mainstay of financial websites for years, especially any site that takes credit cards. By adding it, Twitter is recognizing that a Twitter username and password, in the wrong hands, can be damaging (if only to someone's reputation, as opposed to their wallet.)

SSL handshake:

A HTTP-based SSL connection is always initiated by the client using a URL starting with https:// instead of with http://. At the beginning of an SSL session, an SSL handshake is performed. 

This handshake produces the cryptographic parameters of the session. A simplified overview of how the SSL handshake is processed is shown in the diagram below.

Note: while using https, If at anytime any validation fails or messages are out of order or doesn't contain correct data SSL connection terminated and the browser shows an error.

ex: when we are doing online purchase, payment gateway will be loaded with https. By mistake if we enter wrong data, payment session will be terminated immediately and browser show an error.