Server authentication protects clients as they access Web applications because server authentication verifies the identity of the owner of the Web application. That means that if clients are sending information such as name , age, Social Security number, credit-card information, and so on, they will have the confidence that they know who the owner of the Web application is because this has been verified . Now this doesn't eliminate the possibility of some sort of misuse of the client information. It simply identifies the party to whom the information is going. If this party elects to misuse this information, server authentication can do nothing to prevent this. The only role of server authentication is to verify the identity of the destination party.
The topics we'll cover include those that you need to know to understand the broad security issues. They include
When developing a site that is either going to collect or provide other confidential information, you must keep your customer's protection in mind. That usually means some form of encryption.
To prevent data theft, you need to apply a special encryption mechanism to your Web site. Users access your Web site, and the information that they send is not encrypted by default. If someone intercepts and deciphers the data sent from the user to your Web site, the data can be used for an entire range of things that neither you nor your client would want. The mechanism you should use to prevent this misuse is the Secured Socket Layer (SSL). Web sites that use SSL look different from regular sites. A normal Web site might be http://www.microsoft.com
If a Web site is using SSL, the HTTP protocol token becomes https , as in https://www.microsoft.com
When using SSL, first you must create keys. A key is a special type of encryption encoding that is applied to the data. Both the user browser and the Web site must have keys to open and read transmitted data. The program that enables the Web site administrator to create keys is the key manager .
The two types of keys used are public and private keys. The public key is available to anyone who wants to exchange data, whereas the private key is held by the owner. The keys package data into digital envelopes that have digital signatures.
Senders use the recipient's public key to encrypt the information into a digital envelope when sending data. The sender then transmits the digital envelope to the recipient. Although the packet can be stolen, only the recipient's private key decodes the digital envelope, making the envelope unreadable to anyone who lacks the private key. Only the official recipient has the private key.
So that the recipient can know that it was indeed the correct sender that sent the data, the sender adds a digital signature as proof of its credentials. The sender uses its private key to sign the digital envelope. The recipient need only use the sender's public key to verify the signature. Because the sender's public key verifies the signature, the recipient can be assured that the digital envelope came from the official sender.
One problem that does occur with creating public/private keys and using SSL is that they can deceive users into a false sense of security. Just because a Web site is secure does not mean that the site is a legitimate site. A rogue site could establish an SSL Web site, create keys, and collect credit card numbers for a bogus product. To protect from this scam, a certificate authority can certify the site. A certificate authority must certify the site before any encryption keys may be installed on it.
A certificate authority (CA) ensures that your Web site is a legitimate place of business. There are hundreds of CAs, which you can find with a quick search of the Internet, that can certify your keys. You must have a CA certification and assign your site a certificate before you can use SSL. These certificates continue to be valid until expiration or revocation. Something to keep in mind as well is that the CA maintains a list of invalid certificates in a special list called the certificate revocation list (CRL).
You can find details on SSL, encryption, cryptography, and public/private keys at www.rsa.com.
Why Not Use SSL for Everything?
Although SSL makes it easy to secure data, you might not get the best performance using SSL. SSL slows your applications way down because huge amounts of data processing are required to encrypt and decrypt all the data. The best time to use SSL is when you're sending confidential information over the Internet. Confidential information should be protected whether your Web site or the user sends it.
Creating a Secure Site
Creating your own secure Web site with SSL is not as difficult as it might initially seem. Follow these steps:
To find the best tech support in this area you need to contact Thawte. Initially I had some difficulty with the installation; I forgot to set the SSL port to 443. I read some of the FAQs on the Thawte Web site. When I wasn't able to define my problem exactly I decided to use their 24- hour 5-day tech support chat client. It was an easy way to talk to their tech support people in real time and figure my problem out quickly.
If you are going to have commerce on your server or confidential information is transferred, you need to have SSL. To use SSL, you must obtain and install a digital certificate.
Adding SSL is a relatively easy process but is a mystery to many developers. Use the instructions in this section, and you should have no trouble implementing SSL certificates on your IIS server. For more information go to www.Thawte.com.