Netscape’s Secure Sockets Layer (SSL), created as a security protocol to accommodate emerging e-commerce applications, soon gave rise to the open protocol Transport Layer Security (TLS). Now we have a booming e-commerce presence on the Internet, accounting for billions of dollars worth of transactions every year. This protocol is a must for any Web application that involves transfer of funds, messages that need to be secure, or any other sensitive data transfer.
In a Web application environment, SSL/TLS sits between the application layer (HTTP) and TCP/IP. It enables the encryption of network sessions and the validation of server and client identity; it also permits legitimate third parties access to network traffic. Configuring SSL/TLS and the OpenSSL encryption libraries for use under Apache was covered in a previous article, “Web Development: Use SSL to secure your Apache-based e-commerce transactions.” Now, after a quick word on SSL’s performance issues, we’ll discuss the protocol’s authentication features and techniques.
Consider SSL hardware acceleration
Validation and encryption are effective but costly techniques, adding processing cycles and chewing up bandwidth. You may find it desirable—or even essential—to accelerate SSL via hardware acceleration. SSL accelerator cards, available for the past five years or so, offload the protocol processing to conserve your server’s CPU resources. This may or may not be important from a throughput standpoint, depending on your traffic and applications. But you should know that SSL accelerator cards make SSL easier to implement in the long run, especially when you are implementing SSL in a multiserver environment.
The advantages of SSL hardware acceleration also include scalability (it’s easy to add encryption resources as traffic increases) and isolation of security keys from unprotected server memory, reducing the risk of key theft in the event that a server is compromised.
When you pull out your credit card and type in the number during an Internet e-commerce transaction, you should feel secure that the Web site that is about to receive that credit card number is in fact the site it is claiming to be. Though you’re probably unaware of it, this feeling of security is enabled by the behind-the-scenes use of certificate authorities. Certificate authorities authenticate Web site identity, while SSL encrypts the actual data in transit that includes your credit card number. You should feel secure because fraud seldom occurs within this framework; its performance history in recent years has been exemplary.
Here’s how the Web server identity verification works: The server sends a certificate out with the session key (discussed in the previous article), along with some random data. The receiving browser verifies the certificate before the session is established. This verification includes the decryption of the random data sent with the certificate (the server’s private key will have been used to encrypt it) and the matching of the name on the certificate to the server’s host name. A third party sending a certificate must be an acknowledged certificate authority, and the certificate must not have expired.
How can certificate authority be created and issued? You can do this locally or through a service (such as VeriSign). If you’re issuing certificates locally, you can do it directly with OpenSSL or through a locally installed product such as Certificate Server from Microsoft. However, if your server is going to do financial transactions with the general public, you should seriously consider VeriSign.
The components of a certificate include its X.509 version number and serial number, the name of the signature algorithm, the name of the issuer, the period of its validity (including expiration date), the name of the owner, the public key algorithm, and the subject key identifier.
Generating certificates locally
It’s easy to generate certificates out of OpenSSL. You must create a public key pair, and to do this, you need the private key from the server. Then you need to create a certificate request, which will be digitally signed by a certificate authority (CA). Once this is generated, it will be found in server.csr, and you can e-mail it to the CA that needs to sign it. Here are the commands:
# openssl genrsa –des3 –out server.key 1024
# openssl req –new –key server.key –out server.csr
You’ll be asked to respond to some prompts and provide location information and a certificate-specific password. Once you have your key and the document for acquiring a CA’s digital signature, you can generate the certificate itself. There’s a script for this in OpenSSL apps. When it’s created, you put your own server’s signature on it. Here are the commands:
# ./CA.pl –newca
# ./CA.pl –sign
This process will generate the keys for the CA: a public key and a private key. It will create a temporary directory to store them in (demoCA), and it should go without saying that you guard that private key with your very life.
Also, between generating the new CA and signing it, you must rename the certificate request to newreq.pem. As you run the signing command, you’ll be asked to respond to a commit prompt. The signed certificate is called newcert.pem. Rename it to server.crt.
Authenticating clients with CA
Be aware that you can use CAs for client authentication. If you’re going to try this, there are some things to consider, such as how you’ll get certificates to clients. Obviously, you must verify client identity when a certificate is distributed. Procedures must be in place (for the client) to ensure correct handling. Users should be warned that a certificate stored on a desktop or laptop is subject to theft, and that the certificate is more powerful than a password. You should have a suggested PC/laptop security procedure available to the user in order to ensure the certificate’s protection.
To enable Apache for client authentication, you must modify the ssl.conf file (or the httpd.conf file if you’re using something earlier than Apache 2.0). The modification should read as follows:
# lists of accepted CAs
# says we require client authentication
# Will search up to 10 CA signatures
Restart Apache, browse the site, and then test the certificate authentication. The module mod_ssl in Apache 2.0 offers a number of powerful commands that give you options in key handling and encryption.
Securing the whole process
While SSL technology ensures that e-commerce transactions are encrypted and safe from outside influences, it’s ultimately the ability to certify and authenticate the participants in the transaction that makes the whole process secure.