By Mark Wilcox, Campus Web Administrator

Secure Web Transactions with Secure Socket Layer

We are beginning to replace many of our physical transactions with Web-based transactions. In particular, those transactions that we usually use a telephone for (e.g. ordering flowers for Mom or paying for school via a credit card) are being affected. There is little doubt that these Web-based transaction environments are an improvement over waiting in line or being on hold for an endless amount of time. Of course since you are not dealing with a "person," you may have concerns about providing personal or credit card information to a Web site. I've given some seminars on Internet commerce and when I ask the question "Who's afraid to give their credit card number to a Web site like Amazon.com," the majority of people agree they are afraid. But most of these same people say they don't have a problem giving the same number out to a person on the phone or to a waiter who disappears with their credit card in a restaurant.

I'm going to spend the rest of this article explaining why Web transactions are actually more secure than purchasing over the phone or even in person!

Secure Socket Layer: Encryption for the masses

Right around the release of version 2.0 of Netscape Navigator, Netscape created a new protocol for securing Internet transactions called Secure Socket Layer (SSL). While this protocol has now become an official open standard called Transport Security Layer (TSL), most people still refer to it as simply SSL.

SSL is designed to improve the Internet security model in three ways:

1. Encrypt the data transmitted over the public Internet.
   
   
2. Provide better assurance that a site "really" is who they say they are .
   
   
3. Provide for a more secure mechanism for user authentication (not widely used -- yet).

Data on the Internet (and Intranets or Extranets) are, by default, sent "in the clear". This means that anyone can steal data from the network, read it or even change data in route. It's also fairly easy to have a site "impersonate" a different site.

We solve the first problem by encrypting data so that it makes it very hard for someone who has obtained data in route to read it (but not impossible, if given enough time. Luckily, with the sophisticated encryption algorithms we have today, it would take longer than the known history of the universe to break the code).

We protect ourselves from "man in the middle attacks" by three mechanisms in SSL:

1. We make a digest of our original message and send that to the other machine, who then recomputes the digest. If the message is changed even the slightest (such as by 1 character) the digests will not match, so we assume the message has been tampered with.
   
   
2. We use public/private keys to encrypt/decrypt the message. The server has its private key and it gives the client (e.g. your Web browser) it's corresponding public key. Items encrypted with the private key can only be decrypted with the public key and vice versa.
   
   
3. When we initially connect to the server, we are presented with a certificate. The certificate lists who the server should be be (by it's domain name like www.unt.edu), who the organization is supposed to be, the time the certificate is good for, and who issued the certificate, called the Certificate Authority (CA).

The CA is a third party who can issue the certificates necessary for SSL. Essentially we (clients) must trust the CA to do a good job at verifying who the server is who wants the certificate. This is similar to the trust we have when we fly on a commercial airline. We assume the pilot is good enough to fly us safely because, among other things, he's been issued a pilot's license by the FAA.

Some CA's, such as Verisign, are in the business of issuing certificates, and any certificates issued by Verisign are automatically trusted by Netscape Navigator/Communicator and Internet Explorer. If a CA is not already in the CA database in your browser, you'll be asked if you want to import the CA or not. If you don't trust the CA (and in turn don't believe you can trust the security of the site you are visiting), your browser will not set up a SSL connection.

A trusted certificate virtually guarantees that you are indeed talking to the correct server, as opposed as simply calling a phone number, which may or may not be located at the company you think it is.

Finally, in general, data from Web sites goes straight to a protected database, without having to be reentered by hand. This is much more secure than giving your credit card number to a minimum wage clerk who then disappears to enter the number into the credit card verifier. During the time they are entering the number to be verified they could write it down to use later.

There are things SSL can't solve and these plague any system you use, electronically or in person:

1. The business may only be in business to get your personal information to either rob you or to sell your information to others.
   
   
2. A dishonest employee at the company could break into the user database and steal your information.

In the end, I feel that I'm at least as secure ordering things off the Internet as I am ordering things over the phone. I know the connection is protected from "sniffers" and that, at least, a trusted third party has verified the identity of the organization I'm buying from.