An essential ingredient in any e-commerce initiative, whether it’s business-to-business or business-to-consumer, is the confidence the customer has in the security and privacy of the information he has supplied to the e-commerce server. The ethics and policies of the organization that owns the server govern the privacy of any bit of data after the server receives it, but, when the padlock or key at the bottom of the browser window closes, the customer is reasonably sure that at least the prying eyes of the Internet aren’t seeing more than they should.

The HTTP Server supplied with the AS/400 has been able to close the padlock or key since V3R7, when support was added for the Secure Sockets Layer (SSL) protocol. SSL provides encryption, the process of transforming information so it can’t be read by anyone except the intended reader, for TCP/IP applications. One of those TCP/IP applications is the HTTP Server. I’m going to go through what you need to do to set up the AS/400 HTTP Server for SSL encryption and take a look at how you might incorporate SSL into an application.

Ciphers Everywhere

SSL works on the premise that both sides of a conversation will exchange keys and then use those keys to encrypt data. In other words, the users will turn the data they exchange into ciphertext before they transfer that key information across a network. Each side of the conversation uses the other’s key to decrypt the ciphertext back into plain text.

Also part of the SSL process is the certification of one or both sides of a conversation by some authority, such as VeriSign (www.verisign.com) or Thawte (www.thawte.com). SSL certification helps to ensure that at least one side of the conversation—the organization or individual—is who it says it is.

Encryption protects against the threat of someone “sniffing” the contents of a conversation between computers. The Internet is primarily a shared-access network, with traffic from any conversation flowing through the same facilities as that of many other conversations. Sniffing software is readily available on the Internet and may be able to single out specific conversations and capture data from them.

Another common attack involves someone taking over an established conversation with a server. Another computer can mimic the server and capture the data being sent to it.

SSL, using its certification component, provides protection against this kind of attack as well. Most Web-browsing software started supporting SSL in various forms and at various levels some time ago. This SSL support takes care of one side of the conversation. The server, of course, is the other side.

When to Close the Lock

Most servers and most browsers now support SSL, and it seems like a good idea. So why isn’t everything on the Web encrypted? Wouldn’t it make sense to establish an encrypted conversation as soon as a server is contacted and keep it up until you move on to the next server? The answer, of course, is no. The overhead associated with SSL is significant, both in setting up the conversation and in encrypting and decrypting the ciphertext. And more overhead generally means lower performance.

It really isn’t necessary to encrypt retail catalog pages or marketing Web pages, but it is necessary to encrypt any part of a conversation that involves sensitive financial information, such as a credit card number in a consumer transaction or a price negotiation in a business transaction. The HTTP implementation of SSL allows a server-and-browser session to switch back and forth between ciphertext and higher-performance clear text as security needs dictate.

More Bits or Less Bits?

How difficult it is to break a current technology encryption scheme depends largely on the length of the key used to create the ciphertext. For a long time, the U.S. government limited the length of keys used by encryption software distributed outside the United States, ostensibly to ensure the government’s ability to decode messages if national security were at stake. Companies inside the United States and Canada could use keys up to 128 bits long, while others were limited to keys of 40 bits or 56 bits.

Bowing to industry and public pressure, the United States recently lifted its export restrictions on key lengths. But some countries still maintain import restrictions, apparently to protect their own national interests. As a rule, the longer the key is, the stronger the encryption will be. The flip side of the issue, though, is that longer keys generally take more processing time and processor capacity to encrypt and decrypt.

Certifying Who You Are

SSL requires that at least the server portion of the conversation identify itself with a digital certificate. A certificate authority (CA) issues digital certificates. With most SSL implementations, including the AS/400, the server can act as its own CA and issue its own certificates. One of these internally issued certificates is fine for use on an intranet and may be fine for use with trading partners on an extranet, but, when using SSL on the broader Internet, you must acquire a certificate from a well-known CA. VeriSign is one of the more popular Internet CAs and provides a broad range of certificate and security products.

All the Pieces

The first requirement for using SSL with the HTTP Server on the AS/400 is the HTTP Server itself. You must have the product Domino Go Webserver for AS/400 (5769-DG1) installed on your AS/400. The second requirement, Digital Certificate Manager (DCM), is option 34 of the base OS/400 operating system (5769-SS1). The final component is one of the three available Cryptographic Access Providers. These are licensed programs 5769- AC1, 5769-AC2, and 5769-AC3, all of which can be ordered from IBM. The three products support maximum key lengths of 40, 56, and 128 bits, respectively. The previously mentioned export and import restrictions require that IBM provide the three different options. Which options are available to you will depend on where your server is located.

Browsers that only support shorter keys will always connect to servers that support longer keys. For example, if your customer is in a country that allows only browsers with 40-bit key support and your server is set up to use 128-bit keys, a secure conversation will occur but will be limited to a 40-bit key.

Getting a certificate from VeriSign or another well-known CA requires filling out a form in DCM. The form generates a text certificate request that you must send to the CA. The CA will return the certificate (after you’ve paid for it). You must receive the certificate, using DCM, and copy it to a text file in the AS/400 Integrated File System (AS/400 IFS). Once that process is complete, you can use the Work with secure applications menu option to associate HTTP Server configurations with the appropriate CA and certificate. My companion article, “Locking Up the AS/400 HTTP Server,” on page 56, walks you through the steps necessary to install the certificate on the AS/400 and get an SSL connection up and running.

Switching Back and Forth

Remember that there is a performance penalty for using SSL. Switching back and forth within a Web application is as simple as specifying https: (Hypertext Transfer Protocol, Secure) for pages that require security and http: (standard HTTP) for those that don’t, assuming you’ve used the well-known ports 443 for secure and 80 for nonsecure. Good candidates for https: include forms that ask for customer data, pages that show financial data, and, of course, pages that ask for or contain a credit card number.

The Responsibility Is Yours

Don’t forget that you have a responsibility to protect sensitive data once it is on your server. Many data security problems on the Internet are not problems with the security of a connection; rather, they are problems with basic security on the server. Hackers have been able to access the information directly from files or databases without involving the HTTP Server. You will want to make sure your security house is in order.

Speaking from experience, setting up SSL is substantially easier in V4R4 than it has been in past releases of OS/400. If you follow the cookbook approach provided by the Create certificate authority option in DCM, you should have no trouble getting a secure connection up and configured to meet your specific security needs.

References and Related Materials

• AS/400 Information Center: publib.boulder.ibm.com/html/as400/infocenter.htm
• HTTP Server for AS/400 Webmaster’s Guide V4R4 (GC41-5434-04, CD-ROM QB3AEO04)

• IBM AS/400 Support Line Technical Document—R440 DCM and SSL Basics: as400service.ibm.com/supporthome.nsf/document/17882711