2005-01-18
For more than 10 years the SSL protocol has been widely used for the purpose of securing web transactions over the Internet. One can only guess how many millions or billions of dollars in transactions are processed per a day using SSL. Unfortunately, the simple fact we use SSL does not necessarily mean that the information sent over this protocol is secure. The use of weak encryption, the impossibility of verifying web servers' certificates, security vulnerabilities in web servers or the SSL libraries, as well as other attacks, may each let intruders access sensitive information -- regardless of the fact that it is being sent through the SSL.
This article begins a series of three articles dedicated to configuring Apache 2.0 with SSL/TLS support in order to ensure maximum security and optimal performance of the SSL communication. This article, part one, introduces key aspects of SSL/TLS and then shows how to install and configure Apache 2.0 with support for these protocols. The second part discusses the configuration of mod_ssl, and then addresses issues with web server authentication. The second article also shows how to create web server's SSL certificate. The third and final article in this series discusses client authentication and some typical configuration mistakes made by administrators that may decrease the security level of any SSL communication. Introduction to SSLSecure Sockets Layer (SSL) is the most widely known protocol that offers privacy and good reliability for client-server communication over the Internet. SSL itself is conceptually quite simple: it negotiates the cryptography algorithms and keys between two sides of a communication, and establishes an encrypted tunnel through which other protocols (like HTTP) can be transported. Optionally, SSL can also authenticate both sides of communication through the use of certificates.SSL is a layered protocol and consists of four sub-protocols:
The position of the above protocols according to the TCP/IP model has been illustrated on the following diagram in Figure 1.
Figure 1. SSL sub-protocols in the TCP/IP model As the above diagrams shows, SSL is found in the application layer of the TCP/IP model. By dint of this feature, SSL can be implemented on almost every operating system that supports TCP/IP, without the need to modify the system kernel or the TCP/IP stack. This gives SSL a very strong advantage over other protocols like IPSec (IP Security Protocol), which requires kernel support and a modified TCP/IP stack. SSL can also be easily passed through firewalls and proxies, as well as through NAT (Network Address Translation) without issues. How does SSL work? The diagram below, Figure 2, shows the simplified, step-by-step process of establishing each new SSL connection between the client (usually a web browser) and the server (usually an SSL web server).
Figure 2. How SSL established connections, step-by-step. As you can see from Figure 2, the process of establishing each new SSL connection starts with exchanging encryption parameters and then optionally authenticating the servers (using the SSL Handshake Protocol). If the handshake is successful and both sides agree on a common cipher suite and encryption keys, the application data (usually HTTP, but it can be another protocol) can be sent through encrypted tunnel (using the SSL Record Layer). In reality, the above process is in fact a little bit more complicated. To avoid unnecessary handshakes, some of the encryption parameters are being cached. Alert messages may be sent. Ciphers suites can be changed as well. However, regardless of the SSL specification details, the most common way this process actually works is very similar to the above. SSL, PCT, TLS and WTLS (but not SSH)Although SSL is the most known and the most popular, it is not the only protocol that has been used for the purpose of securing web transactions. It is important to know that since invention of SSL v1.0 (which has never been released, by the way) there have been at least five protocols that have played a more-or-less important role in securing access to World Wide Web, as we see below:
Why has the SSH (Secure Shell) protocol not been used for the purpose of providing secure access to World Wide Web? There are few reasons why not. First of all, from the very beginning TLS and SSL were designed for securing web (HTTP) sessions, whereas SSH was indented to replace Telnet and FTP. SSL does nothing more than handshake and establishing encryption tunnel, and at the same time SSH offers console login, secure file transfer, and support for multiple authentication schemes (including passwords, public keys, Kerberos, and more). On the other hand, SSL/TLS is based on X.509v3 certificates and PKI, which makes the distribution and management of authentication credentials much easier to perform. Hence, these and other reasons make SSL/TLS more suitable for securing WWW access and similar forms of communication, including SMTP, LDAP and others -- whereas SSH is more convenient for remote system management. To summarize, although several "secure" protocols do indeed exist, only two of them should be used for the purpose of securing web transactions (at least at the moment): TLS v1.0 and SSL v3.0. Both of them are further referred in this article series as simply SSL/TLS. Because of known weaknesses of SSL v2.0, and the famous "WAP gap" in case of WTLS, the use of these other protocols should be avoided or at least minimized. Software requirementsThis next part of the article shows how to configure Apache 2.0 with SSL/TLS support, using the mod_ssl module. Therefore, before going further, readers are encouraged to download the latest version of Apache's 2.0 source code from Apache's web site. Most of the examples should also work for Apache 1.3.x - in that case, however, mod_ssl need to be downloaded separately from Apache's source code, from the mod_ssl website.The practical examples presented in the article should work on most Linux, Linux-like and BSD-based operating systems. The only requirement for the operating system is to have both GCC and the OpenSSL library installed. As a default web browser, MS Internet Explorer has been chosen for our testing, mainly because of ubiquitous popularity of that browser. However, any modern web browser can be used, including FireFox, Mozilla, Netscape, Safari, Opera and others). Installing Apache with SSL/TLS supportThe first step in order to install Apache with SSL/TLS support is to configure and install the Apache 2 web server, and create a user and group named "apache". A secure way of installing Apache's 2.0 has already been published on SecurityFocus in the article Securing Apache 2.0: Step-by-Step. The only difference to that process is to enable mod_ssl and mod_setenvif, which is required to provide compatibility with some versions of MS Internet Explorer, as follows (changes shown in bold):
After configuring, we can install Apache into the destination directory:
Configuring SSL/TLSBefore running Apache for a first time, we need also to provide an initial configuration and prepare some sample web content. As a minimum, we need to go through the following steps (as root):
Testing the installationAt this point we can start Apache with SSL/TLS support, as follows:
After the server starts, we can try to connect to it by pointing the web browser to the URL of the form: https://name.of.the.web.server (in our case, https://www.seccure.lab) In few moments, we should see a warning message saying that there is problem with verifying the authentication of the web server we want to access. Below in Figure 3 we will see an example from MS Internet Explorer 6.0.
Figure 3. Anticipated IE 6 certificate warning.
The occurrence of the above warning is perfectly correct. We should receive this message because of two reasons:
After proceeding with Internet Explorer, we should see the following web content as shown below in Figure 4.
Figure 4. Sample working SSL web page. As one may notice, there is a yellow lock at the bottom of the web browsers, which means that the SSL connection has been successfully established. The value "128-bit" says that the symmetric key that that is being used to encrypt the communication has the length of 128 bits, which is strong enough (at least for the moment) to protect the traffic from unauthorized access. If we double click the lock icon, we will see the properties of website's certificate, as shown below in Figure 5.
TroubleshootingIf for some reasons we could not access the website, there is a very useful diagnostic tool known as "s_client" that comes with the OpenSSL library. It can be used to troubleshoot TLS/SSL connections. An example of how to use this tool has been shown below:
The s_client tool has many useful options, such as switching on/off a particular protocol (-ssl2, -ssl3, -tls1), choosing a certain cipher suite (-cipher), enabling debug mode (-debug), watching SSL/TLS states and messages (-state, -msg), and some other options which can help us find the source of the problems. If s_client does not lead us to the source of problem, we should change LogLevel value (in httpd.conf) to "debug", then restart Apache and check its log files (/usr/local/apache2/logs/) for more information. We can also try to use Ethereal or ssldump. Thanks to these tools, we can passively watch the SSL Handshake messages, and try to find the reason for the failure. A screenshot of doing this using Ethereal is shown below in Figure 6.
Concluding part oneWith our secure Apache 2 server up and running with SSL and a sample certificate, this concludes part one of the article series. Next in part two, the reader will see the recommended security and performance settings for mod_ssl, as well as the process for creating a valid web server certificate. |
||||||||
About the author
Artur Maj works as a Principal Software Engineer for Oracle Corporation, in the EMEA Mobile, Wireless & Voice Center of Expertise. He is experienced in designing computer systems, performing security audits as well as providing security training. He is also author of many articles and publications devoted to securing computer systems and software against intruders.
View more articles by Artur Maj on SecurityFocus.
|