HTTPS - Http using Secure Sockets Layer

HTTP

HTTP is something we use on the www to request and receive content. It stands for HyperText Transfer Protocol. A client, usually a web browser, sends a request to a server for some specific content addressed by a Uniform Resource Locator. The server then sends the client this content. This is fine for most content. This whole process took place when you found this webpage, and all you are reading now, and the coding beneath it, was sent to you, in exactly the format you can see in "View>>Source".

What's wrong with this? Nothing, this webpage is nothing secret, private or confidential. However, imagine you had to pay for this webpage, and the only way to view it was to pass your credit card details. This would be sent plain text, i.e. your Credit Card number would go out of your computer, into the world, and to the server as that number.

What's wrong with that? Alot! Anybody along the way who has access to the network wires, lets say, could read that number and start shopping! Although its unlikely someone is listening to what you are sending, it is possible, and therefore too insecure to just accept. You also have to consider people listening to any point along the way, who would just accumulate data. It's not safe to send such information over insecure protocol.

HTTPS

HTTPS is HTTP over the Secure Sockets Layer. This is a form of network transport which is encrypted. It is much more secure, all your data is encrypted using an encryption algorithm.

People can still listen in, but instead of seeing your CC number, they see it in an ecrypted form, its useless to them! Only the sender(perhaps) and the receiver know how to unencrypt the data.

Some Problems

You may or may not have thought of a few problems here:

• You never met this website before, how do you encrypt something it knows how to decrypt?
• How do you know they are who they say they are, could just be encrypting details and giving to anyone.

The first problem may be confusing. If Alice and Bob are going to talk in code, Alice and Bob both need to know the code they use. But if they've never met before, how do they tell each other the code? Somebody might be listening.

The second is not confusing. You can go to all the effort of encoding the data, only to find out you're actually not talking to Bob!

Public/Private Keys

Feel free to get lost on this paragraph. In many forms of encryption, Alice and Bob have 1 key they both know, this lets them encrypt and decrypt. This is fine if they meet up one day and make up the code in private, for future use when they send emails.

However, what if Alice is in Britain, and Bob is in USA? They've just met, and they want to stop George Bush reading their emails. Meeting up is not feasible, Alice knows if she leaves Britain, her place will be taken. Using computationally expensive, and complicated mathematics, its still possible to achieve the ultimal goal of private conversation. A set of keys are generated for each person, a private key, they keep to themselves, and a public key, the world can have. The way the maths works, is that when data is encrypted using a public key, only the private key can decrypt it, and the other way around. When Alice sends her email, she encrypts it with Bob's public key, nobody now but Bob can decrypt it. (Bob and Alice at this point may end up in guantanamo though).

This works, but is computationally expensive, takes a lot of processing power, due to the complexity of the mathematics involved. But you may say, Alice could dream up a new key. She encrypts the key with Bobs public key. Bob now decrypts it with his private key. Now they both share a key they can use. Using this key, they can use a much less computationally expensive encryption mechanism. For safety, they throw this key away after each session.

Ensuring its Bob

Now we need to make sure Alice is talking to Bob, and nobody else. This is done by Bob having a third party give him a certificate saying, Yes I'm Bob. This is not just any third party, but a third party we trust, like Verisign (who would never corrupt the DNS System). When Bob asks for a certificate, Verisign do some checks to ensure he is Bob. Then they give him an electronic certificate, which says they trust he is Bob. This certificate contains Bob's public key. When Alice wants to talk to Bob, she expects a certificate. No certificate, no conversation. If she receives the certificate, she checks it is Bob. If not, no conversation. How does she know Verisign really issued the certificate though?

When Verisign issue a certificate, they sign the certificate, not with a pen, but using their private key. A digest or signature is created from the content, its then encoded using their private key. This means anybody with verisign's public key an decrypt it, that is, check the signature matches the content of the certificate.

Most trusted certificate issuers will have their public keys distributed already with browsers, such as Internet Explorer. The other option, is if you decide you trust an issuer not already there, is to go to their website and install the key. People are free to sign certificates themselves, when they do so, the browser will warn that it was not issued by a trusted authority, and give you the option to continue, this doesn't mean the data is unecrypted, just the person who runs the site is not verified as being who they say they are.

The whole process

So.
1) You ask for https://www.paypal.com
2) Paypal send you their certificate, signed by Verisign.
3) First browser check the signature is valid by decrypting it using the stored Verisign public key.
4) Now browser check it is paypal on the certificate.
5) Browser decides its OK. Browser and paypal decide on an authentication mechanism.
6) Browser creates a key, encrypts it with paypals public key on certificate, and sends it to paypal.
7) Paypal decrypt the key using their private key.
8) Transmission is now encrypted using the obtained mechanism and the new session key.

Of course this is a basic summary, and even this has become complex. But should give you an overview, of what https is, and how its made more secure.

The Padlock

Your browser will show a closed padlock when communication is secure. Other symbols and warnings may appear if the certificate is:

• Valid but not for the site you're connected to.
• Valid but not issued by a trusted issuer.
• Valid but not in the current day (expired, or issued for future).

Related Items:

• Obtaining Win2K Account Pass
• Wireless Hacking At 30,000 Fe
• "You've Got Junkmail!"
• .:Hacking With Metasploit & Ne
• 3 Pervasive Phishing Scams