Alphabet Soup Security

(First published NCSA news, 1996)

by Chey Cobb, CISSP

In my last article I introduced you to the uneasy world of "cookies." Since then I've noticed that a number of industry trade magazines took up the same issue. Great minds... as the saying goes.

I'm going to stay in the kitchen for this article, but I'll move from the oven and the cookies to the stovetop and explain the recipes for the alphabet soup of security protocols and the Web: S-HTTP and SSL.

Online Commerce

Currently, online spending on the Internet is about $518 million a year, give or take a million or two. The forecasters predict spending will jump to (and take this with a grain of salt) - $6.6 billion in four more years! Hundred of companies are jumping on the bandwagon. What will probably make or break these sites is whether or not they handle secure transactions and how their security is handled. That is where S-HTTP and SSL come in.

Security and Standards

Secure HyperText Transfer Protocol (S-HTTP) was one of the first of the proposed security standards for the Web. The IETF (Internet Engineering Task Force) and the W3 Consortium are trying hard to establish standards for the Internet and the Web, but that doesn't mean that developers have to play by those rules - nooooo, this is the new frontier, remember?? That means that users have to wade through thousands of URLs worth of seemingly conflicting information only to discover that THERE ARE NO STANDARDS!

S-HTTP

Secure HyperText Transfer Protocol runs on the Web server as an application. S-HTTP attempts to "fix" the protocol (HTTP) that is used to transfer the information between the Web server and the Web client (your browser). S-HTTP encrypts certain pages that flow between the Web server and the client. This encryption is usually only done to pages that contain sensitive information, such as your credit card number. That means if anyone (read: unauthorized being) is sniffing the packets or eavesdropping in any way, all that person will get is a garbled mess. The encryption method is sometimes like the "red phones" seen in espionage movies: the info is encrypted with one key going out and decrypted with another key as it comes in.

There's only one itty-bitty, teeny-weenie problem with S-HTTP. In order for it to work on the client's end, he/she needs to have a browser that supports the same scheme. (There go those standards again!) At present there are only a few browsers that support S-HTTP.

Say you decide to go this route and use S-HTTP on your web server. What do you do? Be prepared to spend a lot of time researching and talking to people because finding the right hardware/software solution is a confusing mess at the moment. You can buy secure commerce servers with the software pre-installed or you can buy the individual software packages and certificates and licenses and support and then have your techies put it all together. Be prepared to pay anything between $450 an $5,000. The price range represents the difference between an "a la carte" menu and a "price fixe" menu. Making the sense of it all may require the services of a trusted consultant.

SSL

Secure Sockets Layer is another answer to the issue of Web security. SSL works by using a "secure socket" or port for transferring the information between the server and the client. The default port for web servers is Port 80. SSL uses Port 443. This is not a physical port in the back of your machine, so don't go looking for it! The port used in these transactions is a protocol - a set of instructions - which controls how communications are handled. SSL is not restricted to just Web servers, either. It can be used for other communications such as FTP for example.

SSL sits "between" the web browser and the http program on the Web server. First, SSL exchanges verification - you are you and they are they. Then, all information that flows in and out of this port is encrypted and is checked to see that the information has not been changed en route. Again, this is not normally used for the transference of every page on the Web server, but is normally used when you are preparing to send sensitive information such as credit card data. Again, you'll need to have a browser that is capable of handling SSL. You'll get an error message if you are using a "non-SSL compliant" browser.

If you want to have a look at SSL in action, go to any shopping site that supports "secure server" transactions. When you get to the page where you enter your credit card number, you'll notice that the URL has changed from "http://" to "https://". A small key or lock will also appear in one of the bottom corners of your web browser. This indicates that SSL is now encrypting all information that passes from your machine to the Web server.

The Netscape browser uses a key instead of a lock icon and the number of "teeth" in the key indicate the level of encryption that is being used. One tool signifies 40-bit encryption and two teeth means 128-bit encryption is being used. For more information on the level of security, go to the File menu and choose Properties. Click on the Advanced button and you'll get your security information.

Encryption

Both of these methods of securing your information between the Web server and the browser require that you use some sort of encryption or verification scheme. You have to purchase encryption separately from a trusted third party such as RSA or VeriSign. They, in turn, will send you a "certificate." This certificate is not a pretty piece of paper to post on your home page, but is actually a file with some pretty weird ASCII characters in it. This file sites in a secure area of your server or network and is a major part of the secure transaction process. And, yes, it costs money to get this.

Encryption presently comes in two flavors: 40-bits and 128-bits. There are also public "keys" and private "keys". I don't want to get too deeply into this right now because that's a whole 'nother subject!

In Conclusion

S-HTTP works at the application level - in effect it changes the transfer protocol that Web servers use to make pages appear on your browser. SSL attempts to create a secure transference point without changing the transfer protocol. The two can be used together as they do not conflicts with one another - but they do complement each other.

There are other Web security and payment schemes being developed as well. There is SET - Secure Electronic Transactions - which is a set of proposed protocols put together by MasterCard and VISA; Microsoft has their own plan called PCT - Private Communications Technology; IBM has iKP - internet Keyed Payment; there's CyberCash and DigiCash and First virtual, etc. For me, I still do my shopping the old fashioned way; I go to the store with my credit card and let the hackers browse through the dumpsters for my torn carbon-copies. Encryption through destruction is good enough for me!

Cheerz! Spiderwoman