Apache 2 with SSL/TLS: Part 1

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 SSL

Secure 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:

  • SSL Handshake Protocol
  • SSL Change Cipher Spec Protocol
  • SSL Alert Protocol
  • SSL Record Layer

The position of the above protocols according to the TCP/IP model has been illustrated on the following diagram in Figure 1.

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.
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:

  • SSL v2.0
    Released by Netscape Communications in 1994. The main goal of this protocol was to provide security for transactions over the World Wide Web. Unfortunately, very quickly a number of security weaknesses were found in this initial version of the SSL protocol, thus making it less reliable for commercial use:
    • weak MAC construction
    • possibility of forcing parties to use weaker encryption
    • no protection for handshakes
    • possibility of an attacker performing truncation attacks
  • PCT v1.0
    Developed in 1995 by Microsoft. Privacy Communication Technology (PCT) v1.0 addressed some weaknesses of SSL v2.0, and was aimed to replace SSL. However, this protocol has never gained as much popularity as SSL v3.0.
  • SSL v3.0
    Released in 1996 by Netscape Communications. SSL v3.0 solved most of the SSL v2.0 problems, and incorporated many of the features of PCT. Pretty quickly become the most popular protocol for securing communication over WWW.
  • TLS v1.0 (also known as SSL v3.1)
    Published by IETF in 1999 (RFC 2246). This protocol is based on SSL v3.0 and PCT and harmonizes both Netscape's and Microsoft's approaches. It is important to note that although TLS is based on SSL, it is not a 100% backward compatible with its predecessor. IETF did some security improvements, such as using HMAC instead of MAC, using a different calculation of the master secret and key material, adding additional alert codes, no support for Fortezza cipher suites, and so on. The end result of these improvements is that these protocols don't fully interoperate. Fortunately enough, TLS has also got a mode to fall back to SSL v3.0.
  • WTLS
    "Mobile and wireless" version of the TLS protocol that uses the UDP protocol as a carrier. It is designed and optimized for the lower bandwidth and smaller processing capabilities of WAP-enabled mobile devices. WTLS was introduced with the WAP 1.1 protocol, and was released by the WAP Forum. However, after the introduction of the WAP 2.0 protocol, WTLS has been replaced by a profiled version of the TLS protocol, which is much more secure -- mainly because there is no need for decryption and re-encryption of the traffic at the WAP gateway.

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 requirements

This 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 support

The 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):

./configure \

--prefix=/usr/local/apache2 \
--with-mpm=prefork \
--enable-ssl \
--disable-charset-lite \
--disable-include \
--disable-env \
--enable-setenvif \
--disable-status \
--disable-autoindex \
--disable-asis \
--disable-cgi \
--disable-negotiation \
--disable-imap \
--disable-actions \
--disable-userdir \
--disable-alias \
--disable-so

After configuring, we can install Apache into the destination directory:

make

su
umask 022
make install
chown -R root:sys /usr/local/apache2

Configuring SSL/TLS

Before 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):

  1. Create some sample web content, which will be served up via TLS/SSL:

    umask 022
    
    mkdir /www
    echo "Test \
    Test works." > /www/index.html
    chown -R root:sys /www
  2. Replace the default Apache configuration file (normally found in /usr/local/apache2/conf/httpd.conf) with the new one, using the following content (optimized with respect to security and performance).

    # =================================================
    
    # Basic settings
    # =================================================
    User apache
    Group apache
    ServerAdmin webmaster@www.seccure.lab
    ServerName www.seccure.lab
    UseCanonicalName Off
    ServerSignature Off
    HostnameLookups Off
    ServerTokens Prod
    ServerRoot "/usr/local/apache2"
    DocumentRoot "/www"
    PidFile /usr/local/apache2/logs/httpd.pid
    ScoreBoardFile /usr/local/apache2/logs/httpd.scoreboard

    DirectoryIndex index.html


    # =================================================
    # HTTP and performance settings
    # =================================================
    Timeout 300
    KeepAlive On
    MaxKeepAliveRequests 100
    KeepAliveTimeout 30

    MinSpareServers 5
    MaxSpareServers 10
    StartServers 5
    MaxClients 150
    MaxRequestsPerChild 0


    # =================================================
    # Access control
    # =================================================

    Options None
    AllowOverride None
    Order deny,allow
    Deny from all


    Order allow,deny
    Allow from all


    # =================================================
    # MIME encoding
    # =================================================

    TypesConfig /usr/local/apache2/conf/mime.types

    DefaultType text/plain

    AddEncoding x-compress .Z
    AddEncoding x-gzip .gz .tgz
    AddType application/x-compress .Z
    AddType application/x-gzip .gz .tgz
    AddType application/x-tar .tgz
    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl .crl


    # =================================================
    # Logs
    # =================================================
    LogLevel warn
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
    LogFormat "%{Referer}i -> %U" referer
    LogFormat "%{User-agent}i" agent
    ErrorLog /usr/local/apache2/logs/error_log
    CustomLog /usr/local/apache2/logs/access_log combined
    CustomLog logs/ssl_request_log \
    "%t %h %{HTTPS}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \
    %{SSL_CIPHER_USEKEYSIZE}x %{SSL_CLIENT_VERIFY}x \"%r\" %b"

    # =================================================
    # SSL/TLS settings
    # =================================================
    Listen 0.0.0.0:443

    SSLEngine on
    SSLOptions +StrictRequire


    SSLRequireSSL


    SSLProtocol -all +TLSv1 +SSLv3
    SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

    SSLMutex file:/usr/local/apache2/logs/ssl_mutex

    SSLRandomSeed startup file:/dev/urandom 1024
    SSLRandomSeed connect file:/dev/urandom 1024

    SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm
    SSLSessionCacheTimeout 600

    SSLPassPhraseDialog builtin
    SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt
    SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

    SSLVerifyClient none
    SSLProxyEngine off


    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl .crl


    SetEnvIf User-Agent ".*MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    Note: Readers should change some of the values in the above configuration file such as the name of the web server, the administrator's e-mail address, etc.

  3. Prepare the directory structure for web server's private keys, certificates and certification revocation lists (CRLs):

    umask 022
    
    mkdir /usr/local/apache2/conf/ssl.key
    mkdir /usr/local/apache2/conf/ssl.crt
    mkdir /usr/local/apache2/conf/ssl.crl
  4. Create a self-signed server certificate (it should be used only for test purposes -- your real certificate should come from a valid CA such as Verisign):

    1. openssl req \
      
      -new \
      -x509 \
      -days 30 \
      -keyout /usr/local/apache2/conf/ssl.key/server.key \
      -out /usr/local/apache2/conf/ssl.crt/server.crt \
      -subj '/CN=Test-Only Certificate'

Testing the installation

At this point we can start Apache with SSL/TLS support, as follows:

/usr/local/apache2/bin/apachectl startssl

Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide us with the pass phrases.

Server 127.0.0.1:443 (RSA)
Enter pass phrase:*************

Ok: Pass Phrase Dialog successful.

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.
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:

  • The web browser does not know the Certificate Authority which issued the web server's certificate (and cannot know, because we are using self-signed certificate)
  • The CN (Common Name) attribute of the certificate does not match the name of the website - at the moment it is "Test-Only Certificate", and it should be the fully qualified domain name of the web server (e.g. www.seccure.lab)

After proceeding with Internet Explorer, we should see the following web content as shown below in Figure 4.

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.

Figure 5.
Figure 5. Details of our self-signed certificate.

Troubleshooting

If 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:

/usr/bin/openssl s_client -connect localhost:443

CONNECTED(00000003)
depth=0 /CN=Test-Only Certificate
verify error:num=18:self signed certificate
verify return:1
depth=0 /CN=Test-Only Certificate
verify return:1
---
Certificate chain
0 s:/CN=Test-Only Certificate
i:/CN=Test-Only Certificate
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICLzCCAZigAwIBAgIBADANBgkqhkiG9w0BAQQFADAgMR4wHAYDVQQDExVUZXN0
LU9ubHkgQ2VydGlmaWNhdGUwHhcNMDQxMTIyMTg0ODUxWhcNMDQxMjIyMTg0ODUx
WjAgMR4wHAYDVQQDExVUZXN0LU9ubHkgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMEttnihJ7JpksdToPi5ZVGcssUbHn/G+4G43OiLhP0i
KvYuqNxBkSqqM1AanR0BFVEtVCSuq8KS9LLRdQLJ/B1UTMOGz1Pb14WGsVJS+38D
LdLEFaCyfkjNKnUgeKMyzsdhZ52pF9febB+d8cLmvXFve28sTIxLCUK7l4rjT3Xl

AgMBAAGjeTB3MB0GA1UdDgQWBBQ50isUEV6uFPZ0L4RbRm41+i1CpTBIBgNVHSME
QTA/gBQ50isUEV6uFPZ0L4RbRm41+i1CpaEkpCIwIDEeMBwGA1UEAxMVVGVzdC1P
bmx5IENlcnRpZmljYXRlggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQAD
gYEAThyofbK3hg8AJXbAUD6w6+mz6dwsBmcTWLvYtLQUh86B0zWnVxzSLDmwgdUB
NxfJ7yfo0PkqNnjHfvnb5W07GcfGgLx5/U3iUROObYlwKlr6tQzMoysNQ/YtN3pp
52sGsqaOOWpYlAGOaM8j57Nv/eXogQnDRT0txXqoVEbunmM=
-----END CERTIFICATE-----
subject=/CN=Test-Only Certificate
issuer=/CN=Test-Only Certificate
---
No client certificate CA names sent
---
SSL handshake has read 1143 bytes and written 362 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES256-SHA
Session-ID: 56EA68A5750511917CC42A1B134A8F218C27C9C0241C35C53977A2A8BBB9986A
Session-ID-ctx:
Master-Key: 303B60D625B020280F5F346AB00F8A61A7C4BEA707DFA0ED8D2F52371F8C4F087FB6EFFC02CE3B48F912D2C8929DB5BE
Key-Arg : None
Start Time: 1101164382
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 22 Nov 2004 22:59:56 GMT
Server: Apache
Last-Modified: Mon, 22 Nov 2004 17:24:56 GMT
ETag: "5c911-46-229c0a00"
Accept-Ranges: bytes
Content-Length: 70
Connection: close
Content-Type: text/html

TestTest works.
closed

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.

Figure 6.
Figure 6. Ethereal watching SSL Handshake methods.

Concluding part one

With 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.

4 $type={blogger}:

Anonymous said...

first domain flight
[url=http://vimeo.com/user4498961]hotel and prices
[/url]twopenny disney hotels
fiery deals hotels
arcantis caravanserai frochot
[url=http://www.earthday.org/users/48490]hotel louvre
[/url]cheap bangkok hotels
mahabaleshwar motor hotel booking
all inclusive deals
[url=http://www.fairview.org/cty/members/klemot/default.aspx]champerret elysees hotel
[/url]niagra falls bed deals
caravanserai shoddy rates
apartment shelter
[url=http://www.youthcabinet.org/profile/Josh]hotel prices in australia
[/url]for twopence boarding houses
pursuit lido accommodation
airline booking codes
[url=http://www.beautyresearch.com/blogs/alexa/archive/2010/08/15/hotels-and-accomodations.aspx]hotels pensionen
[/url]worthless take in items
case deals
for peanuts american houses
[url=http://www.mazdacommunity.com/profiles/blogs/special-hotel-offers-or]janes hotel
[/url]reduced ways to shape a strain
for a song edifice accessories
direct flights to

Anonymous said...

bet365 casino online secure
who spent lot money gambling
harbor casino jersey city
recensioni dei migliori casino online
www online gambling star
casino backup windsor canada
free slots gambling games
how money spent every year gambling
sahara casino plaque
Instant nodeposit online casinos
bankrupt due gambling
ga drawing
gambling online
gambling internet online
niagra falls casinos
remove toolbar gambling internet
best gambling site
georgia governmental drawing
sport gambling
langley casino online bets
treasure island resort casino minnesota
vhat gambling addiction
free gambling system
sc educational lottery
play casino slot online free
online casino guide credit card
scanner de poker en ligne
internet gambling prohibition
is online gambling legal texas
network blackjack seaport 5000
free online casino game
gambling internet slots casino indian
rfid casino chips stock pick

Anonymous said...

Who can skilled in and tell what goods are sold on this site: [url=http://dergsleepular.chez.com]one klick[/url]
Thanks against waiting!

Anonymous said...

Just popping in to say nice site.