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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online