Apache 2 with SSL/TLS: Step-by-Step, Part 1



Apache 2 with SSL/TLS: Step-by-Step, 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. |

|[pic] |

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

|[pic] |

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

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

| |

|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@seccure.lab |

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

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

| |

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

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

| (in our case, ) |

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

|[pic] |

|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. seccure.lab) |

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

|[pic] |

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

|[pic] |

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

|[pic] |

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

Apache 2 with SSL/TLS: Step-by-Step, Part 2

|In the first article of this three part series, the reader was shown how to install, configure, and troubleshoot Apache 2.0 with SSL/TLS |

|support. Part two now discusses the recommended settings for the mod_ssl module that lets us achieve maximum security and optimal |

|performance. The reader will also see how to create a local Certification Authority and a SSL certificate based on the free and |

|open-source OpenSSL library. |

|Recommended settings for mod_ssl |

|In Apache 2.0.52, there are more than 30 directives that can be used to configure mod_ssl. The detailed description of all of them can be|

|found in Apache's mod_ssl documentation. This section focuses only on the recommended settings which can improve the security or |

|performance of SSL/TLS connections. |

|The list of these mod_ssl settings is shown below in Table 1. |

|Directive(s) |

|Recommended setting or comment |

| |

|SSLEngine |

|Must be enabled, otherwise the main server (or virtual host) will not be using SSL/TLS |

| |

|SSLRequireSSL |

|Must be enabled, otherwise users may be able to access the web content via regular HTTP requests, without using SSL/TLS, at all. |

| |

|SSLProtocol |

|SSLProxyProtocol |

|Should be set to use only TLS v1.0 and SSL v3.0. Most of current web browsers support both of them, so we can safely disable SSL v2.0. |

| |

|SSLCipherSuite |

|SSLProxyCipherSuite |

|To provide strong cryptography, this parameter should be set to use HIGH (>168 bits) and MEDIUM (128 bits) cipher suites. LOW ( $SSLDIR/serial |

|chmod 700 $SSLDIR |

| |

|Create the main OpenSSL configuration file - $SSLDIR/f, with the following content (optimized for the use with SSL web |

|servers): |

|# ================================================= |

|# OpenSSL configuration file |

|# ================================================= |

| |

|RANDFILE = $ENV::SSLDIR/.rnd |

| |

|[ ca ] |

|default_ca = CA_default |

| |

|[ CA_default ] |

|dir = $ENV::SSLDIR |

|certs = $dir/certs |

|new_certs_dir = $dir/newcerts |

|crl_dir = $dir/crl |

|database = $dir/index.txt |

|private_key = $dir/private/ca.key |

|certificate = $dir/ca.crt |

|serial = $dir/serial |

|crl = $dir/crl.pem |

|RANDFILE = $dir/private/.rand |

|default_days = 365 |

|default_crl_days = 30 |

|default_md = sha1 |

|preserve = no |

|policy = policy_anything |

|name_opt = ca_default |

|cert_opt = ca_default |

| |

|[ policy_anything ] |

|countryName = optional |

|stateOrProvinceName = optional |

|localityName = optional |

|organizationName = optional |

|organizationalUnitName = optional |

|commonName = supplied |

|emailAddress = optional |

| |

|[ req ] |

|default_bits = 1024 |

|default_md = sha1 |

|default_keyfile = privkey.pem |

|distinguished_name = req_distinguished_name |

|x509_extensions = v3_ca |

|string_mask = nombstr |

| |

|[ req_distinguished_name ] |

|countryName = Country Name (2 letter code) |

|countryName_min = 2 |

|countryName_max = 2 |

|stateOrProvinceName = State or Province Name (full name) |

|localityName = Locality Name (eg, city) |

|anizationName = Organization Name (eg, company) |

|organizationalUnitName = Organizational Unit Name (eg, section) |

|commonName = Common Name (eg, YOUR name) |

|commonName_max = 64 |

|emailAddress = Email Address |

|emailAddress_max = 64 |

| |

|[ usr_cert ] |

|basicConstraints = CA:FALSE |

|# nsCaRevocationUrl = |

| |

|[ ssl_server ] |

|basicConstraints = CA:FALSE |

|nsCertType = server |

|keyUsage = digitalSignature, keyEncipherment |

|extendedKeyUsage = serverAuth, nsSGC, msSGC |

|nsComment = "OpenSSL Certificate for SSL Web Server" |

| |

|[ ssl_client ] |

|basicConstraints = CA:FALSE |

|nsCertType = client |

|keyUsage = digitalSignature, keyEncipherment |

|extendedKeyUsage = clientAuth |

|nsComment = "OpenSSL Certificate for SSL Client" |

| |

|[ v3_req ] |

|basicConstraints = CA:FALSE |

|keyUsage = nonRepudiation, digitalSignature, keyEncipherment |

| |

|[ v3_ca ] |

|basicConstraints = critical, CA:true, pathlen:0 |

|nsCertType = sslCA |

|keyUsage = cRLSign, keyCertSign |

|extendedKeyUsage = serverAuth, clientAuth |

|nsComment = "OpenSSL CA Certificate" |

| |

|[ crl_ext ] |

|basicConstraints = CA:FALSE |

|keyUsage = digitalSignature, keyEncipherment |

|nsComment = "OpenSSL generated CRL" |

| |

|Now create the CA's private/public key pair, and the self-signed CA's certificate: |

|openssl req \ |

|-config $SSLDIR/f \ |

|-new \ |

|-x509 \ |

|-days 3652 \ |

|-sha1 \ |

|-newkey rsa:1024 \ |

|-keyout $SSLDIR/private/ca.key \ |

|-out $SSLDIR/ca.crt \ |

|-subj '/O=Seccure/OU=Seccure Root CA' |

| |

|It should be emphasized that the CA's private key (ca.key) should be protected by a hard to guess passphrase, and it should be valid for |

|a much longer period of time than regular certificates (typically, 10-30 years, or more). |

|The CA's certificate "ca.crt" should be published on Intranet web pages and installed in every web browser that may possibly need to use |

|it. A sample root CA certificate installed in Internet Explorer is shown below in Figure 2. |

|[pic] |

|Figure 2. Sample root CA certificate installed in Internet Explorer. |

|From this point we can now use our local CA for signing/revoking certificates. In order to create the web server certificate, we should |

|follow the below steps: |

|Create the web server's private/public key pair (server.key), and the certificate request (request.pem). This instruction needs to be |

|executed on the web server. |

|openssl req \ |

|-new \ |

|-sha1 \ |

|-newkey rsa:1024 \ |

|-nodes \ |

|-keyout server.key \ |

|-out request.pem \ |

|-subj '/O=Seccure/OU=Seccure Labs/CN=seccure.lab' |

| |

|Copy the above certificate request (request.pem) into the $SSLDIR/requests directory on the CA host (using removable media, such as a |

|USB-Drive). |

|Sign the certificate request as follows (to be executed on the CA host only): |

|openssl ca \ |

|-config $SSLDIR/f \ |

|-policy policy_anything \ |

|-extensions ssl_server \ |

|-out $SSLDIR/requests/signed.pem \ |

|-infiles $SSLDIR/requests/request.pem |

| |

|The result of the above command is a signed certificate (signed.pem) that is placed in the $SSLDIR/newcerts directory, and in the file |

|$SSLDIR/signed.pem. It consists of both a TXT and PEM representation of the certificate. Because Apache expects a pure PEM format, we |

|need to convert it, as follows: |

|openssl x509 \ |

|-in $SSLDIR/requests/signed.pem \ |

|-out $SSLDIR/requests/server.crt |

| |

|Copy the signed, PEM-encoded certificate (server.crt) back to the web server machine. |

|At this point web server's certificate is ready to use. |

|For local Certificate Authorities, if the web server's certificate is compromised it is CA responsibility to revoke the certificate, and |

|to inform users and applications that this certificate is no longer valid. |

|To revoke a certificate, we need to find the serial number of the certificate we want to revoke in the $SSLDIR/index.txt file. Then, we |

|can revoke the certificate as follows: |

|openssl ca \ |

|-config $SSLDIR/f \ |

|-revoke $SSLDIR/newcerts/.pem |

| |

|To create a CRL (Certificate Revocation List) file, we can use the following commands: |

|openssl ca -config $SSLDIR/f -gencrl -crlexts crl_ext -md sha1 -out $SSLDIR/crl.pem |

| |

|The above file should be published on the CA's website, and/or distributed to users. When distributing CRLs it is also recommended that |

|one use the Online Certificate Status Protocol (OCSP). More information about OCSP can be found in RFC 2560 . |

|Note that some browsers (including Firefox) accept only DER-encoded CRLs, so prior to installing crl.pem in such browsers, the file must |

|be converted as follows: |

|openssl crl \ |

|-in $SSLDIR/crl.pem \ |

|-out $SSLDIR/revoke_certs.crl \ |

|-outform DER |

| |

|Also note that in order for the web browser to check if the web server's certificate is revoked, the option "Check for server certificate|

|revocation" should be checked in MS Internet Explorer's Advanced Settings. This is shown below in Figures 3 and 4. |

|[pic] |

|Figure 3. Configuring Internet Explorer to check for certificate revocation. |

| |

|[pic] |

|Figure 4. Internet Explorer's response to a revoked certificate. |

|Installing the certificate |

|At this point we can proceed with installing the web server's private key (server.key) and certificate (server.crt) into the Apache |

|environment: |

|install -m 600 -o root -g sys server.key /usr/local/apache2/conf/ssl.key/ |

|install -m 644 -o root -g sys server.crt /usr/local/apache2/conf/ssl.crt/ |

| |

|We should also make sure that the directives in Apache's configuration file are pointing to the above files (in httpd.conf): |

|SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt |

|SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key |

| |

|The final step is to restart Apache for the changes to take an effect: |

|/usr/local/apache2/bin/apachectl stop |

|/usr/local/apache2/bin/apachectl startssl |

| |

|At this point we can check to see if the SSL website is accessible from the web browsers, and if the web browsers can successfully |

|authenticate with the web server. This time, there should be no warning messages displayed, as shown below in Figure 5. |

|[pic] |

|Figure 5. Secure connection with a valid certificate. |

|Concluding part two |

|It has been shown how to configure mod_ssl, and how to create and use a web server's X.509v3 certificates. Next, in the third and final |

|part of this article series, we will discuss client authentication via certificates, as well as common mistakes and known attacks that |

|can threaten the security of SSL communication. |

Apache 2 with SSL/TLS: Step-by-Step, Part 3

|Introducing part three |

|This article concludes our three part series dedicated to configuring Apache 2.0 with SSL/TLS support -- for maximum security and optimal |

|performance of SSL based e-commerce transactions. |

|Part one introduced key aspects of SSL/TLS and then showed how to compile, install and configure Apache 2.0. The second part discussed the |

|configuration of mod_ssl and authentication issues, and then showed how to create web server's SSL certificate. |

|Now, in the third and final article, we will take a look at client authentication using client certificates, show how to chroot a secure Apache,|

|discuss common attack vectors, and then describe some typical configuration mistakes made by administrators that will decrease the security |

|level of SSL communications. |

|Client authentication |

|One of the most popular methods for authenticating users in web applications is a password, passphrase or PIN, in other words, "something you |

|know." The greatest advantage of such a method is its simplicity. For an administrator, it is enough to add few directives to httpd.conf and |

|create a passwd file to implement such a schema. |

|Unfortunately, because of their simplicity passwords are vulnerable to a number of attacks. They can be guessed, sniffed over the wire, |

|brute-forced, stolen (such as when a user writes them down on sticky notes) or coaxed out (through social engineering or some kind of "phishing"|

|method). This is why standard password authentication is considered to be weaker than using one-time passwords, hardware tokens or others forms |

|of authentication. |

|Few people realize that when using a SSL web server there is an stronger method of authenticating users: client SSL certificates, or "personal" |

|certificates for each user. In this method, we can authenticate web users based on "something you have," using a certificate and a private key |

|corresponding to the client certificate, as well as "something you know," which would be a passphrase to the private key. Thus, using |

|certificates is more secure than using standard password solutions, mainly because besides an intruder would need to get both pieces of |

|authentication -- the private key that corresponds to the user's certificate, as well as the passphrase -- to gain access. Moreover, unlike a |

|standard password, the certificate's passphrase is not actually sent over the network at all, it is used only locally to decrypt the private |

|key. |

|As will be shown, the implementation of this method of authentication is not complicated and it can be performed in few steps, which |

|administrators will find to be almost as easy as the more popular Basic Authentication password method. |

|Configuring Apache to use client certificates |

|In order to configure Apache to support client authentication via X.509v3 certificates, we need to perform four actions: |

|Enable client authentication in the Apache's web server |

|To enable the use of client certificates, we need to add the following directives to httpd.conf: |

| |

|SSLVerifyClient require |

|SSLVerifyDepth 1 |

| |

|Thanks to the SSLVerifyClient directive, the access to the web server will now be limited only to the web browsers that present a valid |

|certificate, one which is signed by our local CA. Note that the process of creating local CA has been described in the previous article. The |

|"SSLVerifyDepth" value specifies the maximum depth of the intermediate certificate issuers in the chain of certificates. In our case, we will |

|set this value to "1," because all client certificates must be signed by our local CA -- we are not using intermediate CAs. |

|Install the local CA's certificate into the Apache directory structure. |

| |

|install -m 644 -o root -g sys ca.crt /usr/local/apache2/conf/ssl.crt/ |

| |

|Set the SSLCACertificateFile directive (in httpd.conf) to point to the CA certificate we just installed. |

| |

|SSLCACertificateFile /usr/local/apache2/conf/ssl.crt/ca.crt |

| |

|Now restart Apache. |

| |

|/usr/local/apache2/bin/apachectl stop |

|/usr/local/apache2/bin/apachectl startssl |

| |

|From now on, access to the web server via SSL will be granted only to the web browsers that present a valid client certificate, signed by our |

|local CA. To test it, we can try to access the URL of the website. After establishing SSL connection, MS Internet Explorer will ask us to choose|

|the client certificate we want to use, as shown below in Figure 1. |

|[pic] |

|Figure 1. Internet Explorer asking for a client certificate. |

|Since we do not yet have any client certificate installed, access to the web server will simply be denied. |

|Creating a client certificate |

|In general, creating an individual client certificate is very similar to creating a web server certificate. The only difference is that we will |

|use different X.509v3 extensions (the "ssl_client" section from f) and we will store both the private key and certificate in PKCS#12 |

|format (also referred as PFX). |

|For the sake of simplicity, please follow the steps below using OpenSSL to produce the client certificate. Note that it is highly recommended |

|that any actions that are to be performed by users (numbers 1, 2, 7, 8 in the steps below) should be as automated and simplified as possible to |

|minimize user interaction and user error. To that end, additional technology such as Java Applets could be used. Alternatively, a dedicated host|

|can also be used for the purpose of creating client certificates. In this latter case, users would need to visit the server in-person and enter |

|their passphrase on the dedicated host to encrypt their own private key. Although this option might seem a bit inconvenient, it is the most |

|secure method, as a user's identity can be verified and both the certificate and the private key can be passed to the user without sending it |

|over the network. |

|The steps to create and install a client certificate are exactly as follows: |

|Create a private/public key pair for the user, together with a certificate request. If a dedicated host is not being used to serve the |

|certificate, this should be executed on the user's host: |

| |

|openssl req \ |

|-new \ |

|-sha1 \ |

|-newkey rsa:1024 \ |

|-nodes \ |

|-keyout client.key \ |

|-out request.pem \ |

|-subj '/O=Seccure/OU=Seccure Labs/CN=Frodo Baggins' |

| |

|The user sends the certificate request (request.pem) to the local CA, to be signed. |

|The local CA's task is to verify that the information from the client certificate request is indeed valid and correct. |

|After verifying, the certificate request (request.pem) should be copied into the $SSLDIR/requests directory on the local CA host using removable|

|media, such as a USB drive. |

|The local CA should sign the certificate request as follows. This should be executed on the CA's host. |

| |

|openssl ca \ |

|-config $SSLDIR/f \ |

|-policy policy_anything \ |

|-extensions ssl_client \ |

|-out $SSLDIR/requests/signed.pem \ |

|-infiles $SSLDIR/requests/request.pem |

| |

|The local CA should send the certificate (signed.pem) to the user. |

|After receiving the signed certificate, users need to store their private key together with their certificate into PKCS#12 format. |

| |

|openssl pkcs12 \ |

|-export \ |

|-clcerts \ |

|-in signed.pem \ |

|-inkey client.key \ |

|-out client.p12 |

| |

|The newly created client.p12 file should be protected with a hard-to-guess passphrase. All other files (including the unencrypted private key, |

|the signed certificate and the certificate request) should be securely erased from the user's disk space using a wipe utility. |

| |

|wipe client.key signed.pem request.pem |

| |

|The client certificate, together with the private key, should be installed in the user's web browser. An example of this for Microsoft Internet |

|Explorer is shown below in Figure 2. |

|[pic] |

|Figure 2. Installing a certificate in Internet Explorer. |

|To protect the private key against accidental or unauthorized use, the option "Enable strong private key protection" should be checked. Also, to|

|protect the certificate from being stolen, it should be not be possible to export the certificate -- the option "Mark this key as exportable" |

|should be disabled. Both these browser configuration options are shown below in Figure 3. |

|[pic] |

|Figure 3. Protecting the client certificate in Internet Explorer. |

|In addition, the security level of the browser should be changed to "High." We see this during the next step of the Import Wizard, as |

|illustrated below in Figure 4. Thanks to this option, a user will be asked to enter his password every time the web browser wants to use that |

|client certificate. |

|[pic] |

|Figure 4. Security level should be set to "High" in IE. |

|That's all there is to it. The certificate can now be found under the "Personal" tab in the certificate view (in MS Internet Explorer's menu -> |

|tab "Content" -> "Certificates"). If we double click the certificate we should see some properties similar to Figure 5, below. |

|[pic] |

|Figure 5. Client certificate details in IE. |

|Using the client certificate |

|At this point we should try to access the URL of the website again. If the above have been successfully completed, once it is requested we |

|should be able to see and choose the installed certificate from the list, as shown in Figure 6. |

|[pic] |

|Figure 6. Choosing the client certificate when prompted. |

|After choosing the certificate, the user must enter the required passphrase that decrypts the corresponding private key, as shown in Figure 7. |

|[pic] |

|Figure 7. Entering the passphrase for the certficate. |

|Now we will have access to the secure website, illustrated in Figure 8. |

|[pic] |

|Figure 8. Secure access, using certificates, has been granted. |

|Customizing access control |

|With additional server-side directives, we can control which parts of the website particular users or groups of users are granted or denied |

|access. For example, when and organization must deal securely with many different companies, we can restrict access to the website to just one |

|particular company (O=Seccure), by adding the following directives to httpd.conf: |

| |

| |

|SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" |

| |

| |

|Another example shows how to allow access only to a certain department (OU="Seccure Labs") within the company (O="Seccure"): |

| |

|SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \ |

|%{SSL_CLIENT_S_DN_OU } eq "Seccure Labs" |

| |

|Or alternatively, we can provide access to just a few departments (OU="Seccure Labs" or OU="Development") within the same company (O="Seccure"):|

| |

| |

|SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \ |

|%{SSL_CLIENT_S_DN_OU } in {"Seccure Labs", "Development"} |

| |

|Finally, we can even provide access to just one specific user (CN="Frodo Baggins") from a specific company (O="Seccure"): |

| |

|SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \ |

|%{SSL_CLIENT_S_DN_CN} in {"Frodo Baggins"} |

| |

|Note that we can also provide the above environment variables to CGI scripts (including PHP and others), by adding the "+StdEnvVars" parameter |

|to the SSLOptions directive. This features allows us to use DN names inside web applications (PHP and others), to provide more detailed |

|authorization and access control. |

| |

|SSLOptions +StdEnvVars |

| |

|Revoking a client certificate |

|If a client certificate becomes compromised or lost, what do you do? In this case we need to revoke the certificate, as was already described in|

|the previous article. Then, we must copy the CRL file into the Apache directory, as follows: |

| |

|install -m 644 -o root -g sys crl.pem /usr/local/apache2/conf/ssl.crl/ |

| |

|We also need to make sure that the "SSLCARevocationFile" in httpd.conf points to the above file: |

| |

|SSLCARevocationFile /usr/local/apache2/conf/ssl.crl/crl.pem |

| |

|Then, we need to restart Apache for the changes to take an effect. The revoked certificates will not be allowed access to the website, as shown |

|below in Figure 9. |

|[pic] |

|Figure 9. Access attempted with a revoked certificate. |

|Chrooting the server |

|To improve our web server's security and make Apache less vulnerable to buffer overflow attacks, it is recommended that one run Apache in the |

|chrooted environment. Chrooting the web server isolates the process to a new root directory so that it cannot see the rest of the server's |

|files. |

|The process of chrooting Apache has been already described in "Securing Apache 2.0: Step-by-Step," so readers are encouraged to follow steps |

|that were shown there. With the added support for SSL/TLS, we will need to install some additional libraries and create a few new |

|subdirectories. In the case of FreeBSD 5.1, the list of these libraries and directories are as follows: |

| |

|cp /usr/lib/libssl.so.3 /chroot/httpd/usr/lib/ |

|cp /usr/lib/libcrypto.so.3 /chroot/httpd/usr/lib/ |

|cp -R /usr/local/apache2/conf/ssl.key /chroot/httpd/usr/local/apache2/conf/ |

|cp -R /usr/local/apache2/conf/ssl.crt /chroot/httpd/usr/local/apache2/conf/ |

|cp -R /usr/local/apache2/conf/ssl.crl /chroot/httpd/usr/local/apache2/conf/ |

| |

|We also need to add urandom device as follows. Once again, the example below is taken from FreeBSD 5.1: |

| |

|ls -al /dev/*random |

|crw-rw-rw- 1 root wheel 2, 3 Jan 4 12:10 /dev/random |

|lrwxr-xr-x 1 root wheel 7 Jan 4 12:10 /dev/urandom -> random |

|cd /chroot/httpd/dev |

|mknod ./random c 2 3 |

|ln -s ./random ./urandom |

|chown root:sys ./random |

|chmod 666 ./random |

| |

|In the case of other operating systems, readers can create the list of required files by using commands like truss, strace, ktrace etc., as was |

|described in details in the section "Chrooting the server," from the SecurityFocus article, "Securing Apache: Step-by-Step" |

|Once all these steps have been completed, we can run Apache in the chrooted environment, as follows: |

| |

|chroot /chroot/httpd /usr/local/apache2/bin/httpd |

| |

|Known attacks on SSL/TLS |

|Although SSL/TLS protocols offer a high level of security in theory, its actual implementations may be vulnerable to several types of attacks. |

|Of the many attack vectors, two are worthy of special attention: |

|Man in the middle (MITM) attacks |

|In this type of attack, an intruder intercepts the traffic that is being sent between a client and server, such as by forging DNS replies or by |

|performing ARP redirection. Then, it impersonates the client to the server, and vice-versa. During this attack, the user's web browser does not |

|connect directly to the destination server, but instead to the intruder host, which impersonate the web browser and essentially acts as a proxy.|

| |

|There is good and bad news for an administrator who wishes to defend against such attacks. The good news is that the web browsers warn users |

|when the web server's identity cannot be verified, which may indicate possible man-in-the-middle attack, by displaying a message window with a |

|warning. The bad news is that in real life, users very often ignore such warnings. Hence, if the user's web browser accepts connections to SSL |

|web sites that identities cannot be checked, we can only rely on users' education and trust that they will not press the "proceed" button, if |

|such warning message has been displayed. |

|Brute-force attack on the session key |

|This attacks can be performed when the intruder knows or can assume part of the clear text that was sent during SSL/TLS session, such as (such |

|as "GET / HTTP/1.0"), and the intruder can eavesdrop this session (such by using tcpdump, Ethereal or other tools). Then, intruder can encrypt |

|the assumed part of the text by using every possible key, trying to find its occurrence in the originally encrypted SSL/TLS traffic. Once such |

|an occurrence has been found, the key that was used to encrypt this part of the message can be used to decrypt the rest of originally encrypted |

|SSL/TLS traffic. |

|The good news is that maximum number of keys that must be checked is 2^128 when 128-bit symmetric cryptography has been used. Today this is |

|believed to be strong enough to protect the session for literally dozens of years. However, since CPUs grow in strength every year, we cannot |

|really predict for how long 128-bit symmetric keys will be considered to be secure, particularly for hackers with access to large |

|supercomputers. |

|In case of export-class cipher suites (40-bit, and in some extended 56-bit ciphers) such brute force attacks can be successfully performed in a |

|reasonable amoung of time -- sometimes even in few days, depending on the available number of CPUs. If export regulations in your country allow |

|for the use of strong cryptography, one should definitely use it instead of export-class cipher suites. |

|In addition to the two types of attacks listed above, there are some other potential vulnerabilities, including algorithm rollback attacks, |

|timing attacks, traffic analysis, Bleinchenbacher's attacks, and others. Those interested in understanding them can find more information in |

|Bruce Schneier and David Wagner's document, "Analysis of the SSL 3.0 protocol," (PDF document) as well as in many other documents that can be |

|found on the public Internet. |

|Typical SSL/TLS implementation mistakes |

|Certificates signed by a CA that is not known to the web browser |

|The biggest mistake that can be made when implementing SSL/TLS is with the signing of the web server's certificate by a CA that is not trusted |

|by web browser. In other words, the CA's certificate is not installed in the web browser. This makes Man-In-The-Middle attacks very easy to |

|perform, because users have no way of verifying the identity of the web server. |

|To avoid this problem, it is important to make sure that signer's certificate (usually, a trusted CA) is installed in user's web browser. If a |

|local CA was used for signing the web server's certificate, then we must make sure that all web browsers on all clients requiring access have |

|the local CA's certificate installed. The same rule applies to self-signed certificates. |

|Expired certificates |

|The web browser's certificate should be renewed before the previous one expires. Otherwise it will result in the same problem as above, whereby |

|web clients will not be able to authenticate with the web server -- which once again makes SSL/TLS connections vulnerable to man in the middle |

|attacks. In this case, users may get used to seeing a warning message saying the certificate has expired, and then will probably not notice if |

|it is a bogus certificate. |

|Vulnerable versions of OpenSSL and Apache |

|It is very important to always run the latest versions of OpenSSL and Apache. Programmers writing larger pieces of code such as these without |

|bugs is virtually impossible, so we should always use the latest stable versions of the above software. The latest versions should theoretically|

|contain fewer security vulnerabilities (both discovered and not-yet discovered) than previous versions. |

|Acceptance of SSL v2.0, anonymous authentication (aNULL), and cryptography (NULL) by the web server |

|As was previously discussed, the use of cipher suites that support anonymous authentication or require no encryption should be disabled. |

|Otherwise, there is a risk that client can be tricked into negotiating parameters that can dramatically lower the security level of the |

|connection. For this reason we should disable the use of the SSLv2.0 protocol and use TLSv1.0 or SSLv3.0 instead. |

|Use of weak encryption |

|Early implementations of SSL were only able to use 40-bit keys for symmetric encryption, due to US government restrictions. Unfortunately, the |

|data encrypted by 40-bits symmetric keys can now be decrypted in a relatively short period of time, and for this reason 40-bit and 56-bit keys |

|should no longer be used. Most modern web browsers support 128-bit keys for symmetric encryption, and this is now the minimal recommended length|

|of key for use with SSL/TLS. |

|Improper use of a Network Intruder Detection System (NIDS) |

|It is important to stress that unless a NIDS is capable of decrypting the SSL traffic (such as through the use of the web server's private key) |

|it is simply unable to detect attacks on the web application. To detect eventual break-ins, we must either use either a HIDS (Host-based |

|Intruder Detection System), or put the NIDS in a segment where SSL/TLS traffic is being sent in clear text, such as between a SSL Reverse Proxy |

|and the web server's farm. Otherwise we may not be able to detect any attacks, except denial of service, performed against the web server. |

|Allowing access not only via SSL, but also via non-encrypted protocols (HTTP) |

|Setting up SSL/TLS and opening port 443/tcp to the web server, by itself, means nothing if users can still access website via non-encrypted HTTP|

|on port 80/tcp. Thus, one must double-check that the protected content cannot be accessed via non-encrypted HTTP or other protocols (including |

|FTP, Samba, NFS, and so on). |

|Vulnerable client machines |

|When we focus on securing Apache web servers, we can easily forget about the security of the client machines. If they are compromised, the |

|security of SSL/TLS is compromised as well. In that case, intruders could do as they like with client hosts, such as replace certificates in web|

|browsers, install keyloggers, change /etc/hosts to redirect web requests to bogus web servers, or even steal client certificates if they they |

|have been marked as "exportable." |

|Therefore, if the client machines are under our administrative domain, we need to take great care with their security. Enabling a personal |

|firewall, antivirus/antispyware software, and turning on automatic Windows updates should be the absolute minimum. Most importantly, web browser|

|versions should be always up-to-date. |

|It is also recommended that one apply the following options (related to SSL/TLS) to the web browser configuration: |

|checking for a publisher's certificate revocation should be enabled |

|checking for any server certificate revocation should be enabled |

|encrypted server pages should not be stored in the cache |

|the use of SSLv2.0 should be disabled, and only TLSv1.0 and SSLv3.0 should remain enabled |

|the displaying of warnings about invalid web servers certificates should be enabled |

|Using the same Session IDs / cookies for SSL and HTTP |

|It is possible to have an Apache configuration that accepts both HTTP and HTTPS requests on the same server, such as an information website |

|accessible via HTTP, and a transaction part accessible via HTTPS. In this case, the we must be very careful in our web application not to use |

|the same session IDs / cookies for both protocols. Otherwise, an intruder can sniff the HTTP traffic between web server and victim, and can try |

|to use session IDs to get access to authorized part of web application via SSL. |

|Conclusion |

|This article closes the series of articles devoted to configuring Apache 2.0 with SSL/TLS support. It has been presented how to set up SSL/TLS |

|protocol to achieve maximum security and optimal performance. It has been also shown how to create and revoke certificates, and how to use them |

|in practice. |

|Although the series has covered most important aspects of Public Key Infrastructure for use with SSL web servers, including creating, installing|

|using and revoking certificates, we did not exhaust the subject related to PKI. On the contrary, only the real basics of PKI have been |

|presented. Readers interested in further reading on this topic are encouraged to take a look at the documents created by the PKIX Working Group,|

|or the OpenCA PKI Development Project, where the latter is quite a robust and open-source Certification Authority. |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download