Security is an important issue on the internet. When you type something into your computer, it is usually sent across the wireless network and then the internet without any security. This means that anything you type into the internet (e.g. Google searches) is basically public, even if you are typing it into the internet from your own private computer.
For most websites, this relationship to their customers is fine. A local restaurant’s website, for instance, might just display information about the restaurant and maybe a menu. There is no reason this needs to be protected. If the website asks for private information from the user, though, and especially if the website has a concept of “logging in”, then some security is necessary.
Without security, the information being sent over the line is unprotected. Minimally, this means that anyone on the same internet connection can read all the information going back and forth, including the private information and user name and password. This is true even if the password is masked in password fields. In a worst case scenario, though, someone else would be able to hijack the communication between your server and the user, basically taking over the user’s identity.
A naive solution would be to use some simple encryption: the server hands the user a key, the user encrypts messages with the key, and then the user sends the messages to the server. This works out okay, except that someone standing between the server and the user could substitute in a second key, thereby hijacking the conversation. This is called a “Man in the Middle Attack”.
The solution to this is HTTPS. HTTPS, sometimes called “Secure HTTP”, basically creates a network of trust between the server and the user. The server pays to have their identity assured by some known-trustworthy party. The user receives this certification of identity along with the key, so they know they can trust the key. That key then encrypts the information and sends it back. The Man in the Middle Attack doesn’t work because that certification of identity can’t be faked, so any attempt to substitute in a second key is caught right away.
This is why you will have to pay a fee to some trusted party (such as VeriSign) if you want HTTPS set up for your server: that fee goes to verifying your identity and creating the certificate. Once you have that, your users will know that they can trust the communication between themselves and your servers to be safe.
