Apache and SSL

by Paul Weinstein

First published: April 2002 for O'Reilly's OnLamp.com.
Republished April 19th issue of Apache Week
Republished Apache section of ArticleCentral.com

Paul Weinstein will give a tutorial on Apache and SSL at the upcoming O'Reilly Open Source Convention, this July 22-26, in San Diego.

Secure Sockets Layer (SSL), developed by Netscape Communications, and Transport Layer Security (TLS), the open-standard replacement for SSL from the Internet Engineering Task Force, are the two protocols that add encryption and authentication to TCP/IP. This article summarizes the basic concepts of how the two protocols work and how Apache implements these protocols so that one can transmit information securely over HTTP.

SSL and TLS

SSL and TLS have two main features: ciphers, which enable the encryption of data between the client and server; and digital certificates, which provide a method of authentication of a client and server. SSL uses both symmetric (a.k.a. secret-key) and asymmetric (a.k.a. public-key) ciphers to encrypt information in a secure and efficient manner. Digital certificates, which are based on the public-key encryption technique, provide the method for authentication.

Let's take a look at the SSL handshake for establishing a secure HTTP connection, so we can learn how SSL uses the ciphers and digital certificates to encrypt and authenticate the two parties:

  1. A Web client requests a secure transaction by establishing an HTTP connection to port 443 (https) and sends along information identifying the session and a list of known ciphers and key sizes.

  2. The server uses the session information to determine the session state. If a new SSL session is being established, the server sends back a list of ciphers and key sizes based on a pre-configured priority listing and the client's list. The server also sends along a digital certificate that authenticates the server. If the server is configured to require the client to authenticate itself using a digital certificate, the server also sends the client an authentication request.

  3. The client authenticates the server based on the Certificate Authority that issued and signed the digital certificate. If the client trusts the certificate authority it will trust the information provided within the certificate, and in turn the server that sent the digital certificate.

  4. The client generates a symmetric key using a cipher and key size. The client then encodes the symmetric key using the public, asymmetric key of the server, which was encoded in the server’s digital certificate. If the server has requested a digital certificate for client authentication, the client sends it along with the encoded symmetric key.

  5. If the server has requested a digital certificate from the client, the server attempts to authenticate the certificate based on the Certificate Authority that issued and signed the client’s digital certificate. If the client cannot be authenticated, the session ends. If the client can be successfully authenticated or the server did not require a digital certificate from the client for authentication, the server uses its private key to decrypt the symmetric key.

  6. Both the client and the server use the symmetric key to generate another symmetric key, know as the session key.

  7. The client sends a message to the server stating that all future messages from the client will be encrypted with the session key. It then sends a separate, encrypted message stating that the client portion of the handshake is done.

  8. The server sends a message to the client stating that all future messages from the server will be encrypted with the session key. It then sends a separate, encrypted message indicating that the server portion of the handshake is finished.

  9. The SSL handshake is complete and the session begins. The client and the server use the session key to encrypt and decrypt the data they send to each other and to validate the integrity of the data.

Apache and SSL


O'Reilly Open Source Convention -- July 22-26, San Diego, CA.

From the Frontiers of Research to the Heart of the Enterprise

Paul Weinstein will give a tutorial on Apache and SSL at the upcoming O'Reilly Open Source Convention, this July 22-26, in San Diego.

One implementation of Apache and SSL is Ben Laurie's Apache-SSL, a collection of patches for the Apache code base, which allows the open source public-key toolkit OpenSSL to enable SSL into Apache. The most popular method, however, for implementing SSL is Ralf Engelschal's mod_ssl. The mod_ssl method takes advantage of Apache's modular setup to interface OpenSSL with Apache.

According to E-Soft's Apache Module Report for April, almost a quarter of all Apache installations use mod_ssl. The only Apache module to rate higher is mod_php, with 45 percent. mod_ssl fully integrates into Apache 1.3.x using the extended API (EAPI), and can be loaded as a Dynamic Shared Object (DSO) for memory conservation while inactive. A number of commercial implementations of Apache also rely on mod_ssl for adding SSL.

In addition to the fact that mod_ssl is the most popular method for adding SSL to the default Apache 1.3.x code base, mod_ssl has been selected by the Apache Group as the default method for implementing SSL in Apache 2.0. Moreover, with Apache 1.3.x, mod_ssl has to be downloaded separately and compiled against the Apache 1.3.x code base. With Apache 2.0, mod_ssl is included with the downloadable Apache source code and can be enabled when building Apache 2.0 with the --enable-ssl switch.

With Apache and SSL it is possible to not only deploy a Web site that collects information in a secure manner, such as customer information for an e-commerce site, but also to deploy a Web site that distributes information in a secure manner, such as an intranet for a non-profit organization.

For example, a customer who wishes to purchase some goods from an online store with a credit card knows that when connecting to an SSL enabled server:

  • The communication with the store's server is secure.

  • The store's server that is decrypting the data is in fact the online store as identified by the server’s digital certificate and authenticated by a trusted third party. In other words, the credit card information will be used to process the order for goods the customer is placing.

In another example a volunteer for a non-profit can access the organization's intranet from his or her home or office and know that:

  • The communication with the organization's server is secure.

  • The server on the end of the decryption is, in fact, the organization's server, and the information being accessed from the server is valid.

  • The client on the other end of the decryption is, in fact, a volunteer and has the proper permission from the organization to access the online information.

More Information

For more on Apache and SSL, don't miss my tutorial at this July's O'Reilly Open Source Convention.

Additional information on Apache 1.3.x and 2.0 can be found at the Apache Web site. The OpenSSL toolkit is developed and maintained by open source developers at the Apache-SSL site. Information on commercial implementations of Apache and SSL can be found on Apache's Related Projects page, and E-Soft's various reports on the Web server market can be found at SecuritySpace.

Paul Weinstein is the Chief Consultant for Waubonsie Consulting.