Securing Your Web Traffic with SSLTLS

Trafficzion Method

Increase Traffic to Your Website

Get Instant Access

You want to add security for your server, including your own certificates. Your data is important, and so is your capability to pass it along your network or the Internet to others. Networks just aren't secure enough by themselves to protect your communications. This section examines ways in which you can help guard your communications.

Electronic commerce applications such as online shopping and banking are generally encrypted using either the Secure Socket Layer (SSL) or Transport Layer Security (TLS) specifications. TLS is based on version 3.0 of the SSL specifications, so they are very similar in nature. Because of this similarity—and because SSL is older—the SSL acronym is often used to refer to either variety. For Web connections, the SSL connection is established first, and then normal HTTP communication is "tunneled" through it.

Note

Because SSL negotiation takes place before any HTTP communication, name-based virtual hosting (which occurs at the HTTP layer) does not work easily with SSL. As a consequence, every SSL virtual host you configure should have a unique IP address. You can use some tricks to get name-based virtual hosting to work with apache2, but they are outside the scope of this procedure. (See the Apache site for more information:

httpd.apache.org/docs/vhosts/name-based.html.) ■

During connection establishment between an SSL client and an SSL server, asymmetric (public key) cryptography is used to verify identities and establish the session parameters and the session key. A symmetric encryption algorithm such as DES or RC4 is then used with the negotiated key to encrypt the data that are transmitted during the session. The use of asymmetric encryption during the handshaking phase allows safe communication without the use of a preshared key, and the symmetric encryption is faster and more practical for use on the session data.

For the client to verify the identity of the server, the server must have a previously generated private key, as well as a certificate containing the public key and information about the server. This certificate must be verifiable using a public key that is known to the client.

Certificates are generally digitally signed by a third-party certificate authority (CA) that has verified the identity of the requester and the validity of the request to have the certificate signed. In most cases, the CA is a company that has made arrangements with the Web browser vendor to have its own certificate installed and trusted by default client installations. The CA then charges the server operator for its services.

Commercial certificate authorities vary in price, features, and browser support, but remember that price is not always an indication of quality. Some popular CAs include InstantSSL (www. instantssl.com), Thawte (www.thawte.com), and VeriSign (www.verisign.com).

You also have the option of creating self-signed certificates, although these should be used only for testing or when a very small number of people will be accessing your server and you do not plan to have certificates on multiple machines. Directions for generating a self-signed certificate are included in the following section.

The last option is to run your own certificate authority. This is probably practical only if you have a small number of expected users and the means to distribute your CA certificate to them (including assisting them with installing it in their browsers). The process for creating a CA is too elaborate to cover in this book but is a worthwhile alternative to generating self-signed certificates. You can find guides on running your own CA at http://sial.org/howto/openssl/ca/.

The following procedure describes how to generate and use SSL keys with the LAMP server (running on an Ubuntu system) configured in this chapter. For a general discussion of SSL keys and procedures specific to Fedora and other Red Hat systems, refer to Chapter 12.

Generating your keys

To begin setting up SSL, use the openssl command, which is part of the OpenSSL package, to generate your public and private key:

1. Use APT to verify that OpenSSL is installed. If it is not present, APT downloads and installs it automatically:

$ sudo apt-get install openssl

2. Generate a 1024-bit RSA private key and save it to a file: $ sudo su -

# mkdir /etc/apache2/ssl.key/

# openssl genrsa -out server.key 1024

# chmod 600 server.key

Note

You can use a filename other than server.key and should do so if you plan to have more than one SSL host on your machine (which requires more than one IP address). Just make sure you specify the correct filename in the Apache configuration later. ■

In higher-security environments, encrypting the key by adding the -des3 argument after the genrsa argument on the openssl command line is a good idea:

# openssl genrsa -des3 -out server.key 1024

3. You are asked for a passphrase, which is needed every time you start Apache.

Caution

Do not lose this passphrase because it cannot be easily recovered. ■

4. If you plan to have your certificate signed by a CA (including one that you run yourself), generate a public key and a certificate signing request (CSR):

# openssl req -new -key ../ssl.key/server.key -out server.csr

Country Name (2 letter code) [AU]: US

State or Province Name (full name) [Some-State]:Washington Locality Name (eg, city) []:Bellingham Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Company, LTD.

Organizational Unit Name (eg, section) []:Network Operations

Common Name (eg, YOUR name) []:secure.example.org Email Address []:[email protected]

Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

The Common Name should match the name that clients will use to access your server. Be sure to get the other details right if you plan to have the CSR signed by a third-party CA.

5. When using a third-party CA, submit the CSR to it and then place the certificate it provides you into /etc/apache2/ssl.crt/server.crt (or a different file, as desired).

6. If you don't plan to have your certificate signed, or if you want to test your configuration, generate a self-signed certificate and save it in a file named server.crt:

# openssl req -new -x509 -nodes -sha1 -days 365 -key \ ../ssl.key/server.key -out server.crt

State or Province Name (full name) [Some-State]: .

Organization Name (eg, company) [Internet Widgits Pty Ltd]:TEST USE ONLY

Organizational Unit Name (eg, section) []:TEST USE ONLY Common Name (eg, YOUR name) []:secure.example.org Email Address []:[email protected]

Configuring Apache to support SSL/TLS

After your keys have been generated, you need to enable the mod_ssl Apache module, which adds SSL/TLS support to Apache, and then configure it using the appropriate configuration directives. The mod_ssl module is installed with the basic apache2.2-common package. Here's how to enable it for your virtual hosts:

1. Run the a2enmod command to enable ssl: $ sudo a2enmod ssl

Module ssl installed; run /etc/init.d/apache2 force-reload to enable.

2. Add an SSL-enabled virtual host to your Apache configuration files. Using the earlier virtual host as an example, your configuration will look something like this:

Listen *:443 <VirtualHost *:443>

ServerName secure.exawple.org

ServerAlias web.exawple.org DocumentRoot /home/usernawe/public_html/ DirectoryIndex index.php index.html index.htm SSLEngine On

SSLCertificateKeyFile /etc/apache2/ssl.key/server.key SSLCertificateFile /etc/apache2/ssl.crt/server.crt SSLCACertificateFile /etc/apache2/ssl.crt/ca.crt </VirtualHost>

This example uses a wildcard for the IP address in the VirtualHost declaration, which saves you from having to modify your configuration file in the event that your IP address changes but also prevents you from having multiple SSL virtual hosts. In the event that you do need to support more than one SSL virtual host, replace * with the specific IP address that you assign to that host.

Note

See the "Troubleshooting" section earlier in the chapter for more information about the Listen directive. ■

A CA generally provides you with a certificate file to place in ca.crt and sometimes also provides you with a separate file that you will need to reference using a SSLCertificateChainFile directive.

3. Test the Apache configuration and then perform a full restart:

$ sudo apache2ctl configtest

Syntax OK.

$ sudo apache2ctl stop

$ sudo apache2ctl start

4. Browse to https://serverna.me/ and verify the SSL configuration. When using a self-signed certificate, or one signed by a CA, you are asked whether you want to accept the certificate.

Was this article helpful?

0 0

Post a comment