Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Armoring Apache HTTP Server with SSL

These days, just about every Web site needs security. This simple, step-by-step guide will help you understand the various encryption schemes and show you how to set up SSL encryption on your Apache server.


advertisement
nfortunately, there are individuals in the cyber world who have nefarious plots to use and abuse data that your Web site users might deem private and sensitive. But if you're an Apache user (or are thinking about becoming one), you're in luck. In this article, we'll teach you how to configure the Apache HTTP Server Version 2.0 with SSL so that you can safely transfer encrypted data between your Web server and your Web site users.

SSL in a Nutshell
The Secure Sockets Layer (SSL) protocol and the Transport Layer Security (TLS) protocols are used to provide security for HTTP transactions. Though both protocols are used, SSL and TLS are commonly just referred to as SSL and the term secure HTTP is used to refer to HTTP running over SSL. A client connects to a secure HTTP server by specifying https as opposed to http as the protocol of the URI she is trying to access. By default, secure HTTP uses port 443.

When referring to the subject of secure communications on the Internet, we need to address three major concerns: confidentiality, data integrity, and authentication. Confidentiality refers to making sure that an unintended recipient does not get a hold of sensitive data. Data integrity refers to protecting data from malicious manipulation as it travels from one point to another. Authentication refers to making sure the party you are talking to is a trusted party and that they are who they say they are.



The methods in which you can address these concerns are more easily realized through an analogy. Pretend that you are on an island and that you want to send a bar of gold to a friend on another island. The only means to get the bar of gold to your friend is to pay an untrustworthy deliveryman who owns a boat. You could just hand the man the bar of gold and ask him to deliver it, but your friend would probably never get it.

If you and your friend both have keys to the same lock, you could put the bar of gold in a box, lock it with your key, then give it to the man to deliver it. The man doesn't know what's in the box, and because the box and the lock are impenetrable in our analogy, the box is worthless to him, so he just delivers it and makes his money. We'll call this the "single lock" analogy.

But now let's assume that your friend does not have a key to the lock. You could put the lock on the box and hand the man the box and a spare key, but there is nothing to stop him from opening it with the spare key after he departs. What to do?

Well, there are a couple ways to do it. One way is for your friend to send over a box that resembles a post-office drop box. Anybody can put something into the box using an insertion slot, but the box has a contraption that prevents anybody from removing anything back out from the box. Nobody can get anything out of the box without a private key. Conceptually, the insertion slot is a public key. You can slide the gold bar into the insertion slot of the box and send the box back to your friend. Your friend uses his private key to open the box and get the gold bar out.

In security software lingo, the single lock analogy is called symmetric cryptography and the mailbox analogy is called asymmetric cryptography.
The "no lock" model is analogous to a web transaction with no encryption. In security software lingo, the single lock analogy is called symmetric cryptography and the mailbox analogy is called asymmetric cryptography. Data that is not encrypted is typically called plain text. SSL is used to encrypt or "put a lock" on plain text data, so to speak. This encrypted data is typically called cipher text. To an eavesdropper, cipher text is incomprehensible. When the encrypted message reaches its destination, it can be decrypted back to its original, plain-text format.

In symmetric cryptography, the same key is used to both encrypt and decrypt a message. This seems simple and straightforward; however, the complexity lies in how to transfer a key securely to your recipient. How do you know that someone won't intercept the key while it is being transferred? Common algorithms used for symmetric cryptography include DES, Triple-DES, and the RC2 algorithms.

Asymmetric cryptography, or public key cryptography, involves a pair of keys—a public key and private key. When one transmits data, they use a public key that was given to them by the intended recipient to encrypt the data. When the message is received, only the recipient's private key can open that message. The most common public key algorithm is RSA.

SSL uses a tandem approach of both symmetric and asymmetric cryptography as it facilitates secure communication. Public key cryptography is used at the beginning of the transaction to securely transfer private keys. From there, private keys are used to encrypt communication across the wire.

The job of protecting data integrity is performed by a message digest. Before a message is sent, a message digest is created using a fixed representation of the message that uniquely identifies it. The message digest cannot be used to figure out what the original message was; it can only identify it uniquely. The message digest is used at the receiver's end to make sure the message text was not altered. Because the possibility exists that the message text and the message digest could be hijacked and altered, the SSL protocol uses message authentication codes (MACs) to assure integrity. MACs use shared keys to protect the message and the digest.

As stated earlier, another key concern in the world of security lies in authentication. In the world of SSL, this concern is addressed by certificates. Digital certificates are electronic documents used to ensure that a person is who he says he is. They contain information about the owner of the certificate such as name, address, etc. To ensure this information is true, a trusted third party certificate authority is used as an intermediary. Certificate authorities ensure that a given public key in fact belongs to the claiming individual/organization.

One of the best known certificate authorities is VeriSign (see resources section, left column). By default, your Web browser most likely comes bundled with a set of certificates. These certificates recognize the major certificate authorities. In Microsoft Internet Explorer, you can click on Tools->Internet Options->Content->Certificates to see which certificate authorities are available.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap