what is https stands for, what  the handshaking that goes on behind the scenes.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

http is hyper text transfer protocol.  The "s" simply indicates that it has been secured with SSL encryption.

Just google ssl encryption and you'll find many many articles.  
Here is handshaking that goes behind the scenes as you asked:
On Client Side.
1-Browser checks the certificate to make sure that the site you are connecting to is the real site and not someone intercepting.
2-Determine encryption types that the browser and web site server can both use to understand each other.
3-Browser and Server send each other unique codes to use when scrambling (or encrypting) the information that will be sent.
4-The browser and Server start talking using the encryption, the web browser shows the encrypting icon, and web pages are processed secured.

Hope that helps
A bit more detailed than syedasimmeesaq:

- The user types in an https-url instructing the webbrowser to connect to the webserver
- The browser will connect to the requested webserver on port 443 (HTTPS) instead of port 80 (HTTP) and asks for a session-setup. The browser will provide a list of which encryption-methods are supported.
- The webserver will choose one of the encryption-methods and confirms the session.
- The webbrowser now generates a session-key and encrypt it with his own key using a reversible encryption and sends it to the webserver.
- The webserver is unable to read the session-key, but he is able to encrypt everything using it's own key and sends it back to the webbrowser.
- The webbrowser gets the double-encrypted session-key and removes it's own encryption, sending the single-encrypted data back to the webserver.
- The webserver now receives the encrypted session-key which it can decrypt and read. The session-key is used by both parties to encrypt the traffic.
- The webbrowser will now request the certificate. It *might* present it's own certificate, but that's only if the server needs to verify the clients identity and is rarely used.
- The webserver now sends the certificate. The certificate is signed by an CA (Certificate Authority).
- The webbrowser will check whether the CA that signed the certificate is in it's own CA-database. If it isn't it will present a message to the user that the identity of the webserver could not be verrified.
- If the CA is in the database, it will check if the signature of the certificate matches the one of the CA that the browser has on file.  If it does not match, the user is informed.
- For very important communications, the browser may also elect to check the CRL's (Certificate Revocation Lists) to see if the certificate is still trustworthy. (A certificate can be revoked if is stolen or otherwise compromised)
- Upon a matching signature and when the certificate is NOT listed in a CRL, the webserver is trusted. The webbrowser assumes that webservers that are beeing trusted by a CA the browser trusts, are trustworthy. A so called chain of trust.
- From this moment on, the 'tunnel' is established and everything continues just like an ordinary HTTP connection. All the commands and replies are the same, except that they are encrypted on transit.

Looks complicated, but it isn't.

Imagine, you need to send something secret to someone, but you are unable to bring it yourself. So you take an toolkit, you put an combinationlock plus the a note with the correct combination inside and lock it with an ordinary key-lock. You give the toolkit to the courier and some time later you receive the same toolkit back. But now locked with two-keylocks instead of one. You remove your lock and give it back to the courier. The other side is now able to remove their own lock and open the toolbox.

They put in their ID and lock the box, this time with the combination-lock and send it back to you. Since you know the combination, you are able to open the box and find the ID. Because the ID is provided by the authorities, and you trust the authorities that they only provide the ID to the correct person, you trust that the person you're dealing with, is the right one.

From this moment on, you can put anything in the toolbox and send it savely. You can even put in a note saying that the other end should change the combination to a certain number to minimize the chanche that a couriers guesses the combination.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.