본문 바로가기
조회 수 16850 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

+ - Up Down Comment Print
?

단축키

Prev이전 문서

Next다음 문서

+ - Up Down Comment Print
Apache 2 with SSL/TLS: Step-by-Step, Part 1
Apache 2 with SSL/TLS: Step-by-Step, Part 1
Artur Maj 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 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 "<html><head><title>Test</title></head><body> \  
    Test works.</body></html>" > /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
    <IfModule mod_dir.c>
        DirectoryIndex index.html
    </IfModule>
    
    # =================================================
    # HTTP and performance settings
    # =================================================
    Timeout 300
    KeepAlive On
    MaxKeepAliveRequests 100
    KeepAliveTimeout 30
    <IfModule prefork.c>
        MinSpareServers 5
        MaxSpareServers 10
        StartServers 5
        MaxClients 150
        MaxRequestsPerChild 0
    </IfModule>
    
    # =================================================
    # Access control
    # =================================================
    <Directory />
        Options None
        AllowOverride None
        Order deny,allow
        Deny from all
    </Directory>
    <Directory "/www">
        Order allow,deny
        Allow from all
    </Directory>
    
    # =================================================
    # MIME encoding
    # =================================================
    <IfModule mod_mime.c>
        TypesConfig /usr/local/apache2/conf/mime.types
    </IfModule>
    DefaultType text/plain
    <IfModule mod_mime.c>
        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
    </IfModule>
    
    # =================================================
    # 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
    
    <Directory />
        SSLRequireSSL
    </Directory>
    
    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
    
    <IfModule mime.c>
        AddType application/x-x509-ca-cert      .crt
        AddType application/x-pkcs7-crl         .crl
    
    </IfModule>
    
    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):

    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

  <html><head><title>Test</title></head><body>Test works.</body></html>
  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.

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.


Privacy Statement
Copyright 2006, SecurityFocus


Title
List of Articles
번호 제목 글쓴이 날짜 조회 수
448 /boot 파티션 손상시 복구 방법 Hojung 2011.01.07 27908
447 /proc/meminfo 내용 설명 Hojung 2011.01.07 21979
446 1.txt ~ 999.txt 파일명을 001.txt ~ 999.txt 로 변경하기 Hojung 2010.12.31 17294
445 10 Ways to Generate a Random Password from the Command Line Hojung 2014.11.16 6064
444 18 commands to monitor network bandwidth on Linux server file Hojung 2014.04.13 10070
443 20 Linux System Monitoring Tools Every SysAdmin Should Know (Cool!) Hojung 2009.10.20 12423
442 59 Open Source Tools That Can Replace Popular Security Software Hojung 2011.06.16 22372
441 A simple Linux backup method Hojung 2010.11.25 21296
440 About initrd from Wikipedia Hojung 2008.01.06 17264
439 Add arguments from previous command Hojung 2011.08.22 16806
438 Advanced SSH security tips and tricks Hojung 2011.08.18 14347
437 Apaceh2 + SSL on Fedora Core Hojung 2007.12.14 46670
436 Apache 2 with SSL/TLS (https) Hojung 2012.07.20 9737
» Apache 2 with SSL/TLS: Step-by-Step, Part 1 Hojung 2007.12.14 16850
434 Apache2 + MongoDB + ElasticSearch + Kibana file Hojung 2014.03.16 13304
433 APM (Apache + PHP + MySQL) with phpmyadmin in CentOS VM Hojung 2014.11.16 7040
432 ARP Spoofing 감지하기 (arpwatch) Hojung 2011.01.14 25854
431 arping Hojung 2007.11.18 25784
430 ATI x1300 on Fedora Core 10 Hojung 2009.04.20 22297
429 awk 명령어 간단 사용법 Hojung 2009.03.11 17799
Board Pagination ‹ Prev 1 2 3 4 5 6 7 8 9 10 ... 23 Next ›
/ 23

Designed by sketchbooks.co.kr / sketchbook5 board skin

나눔글꼴 설치 안내


이 PC에는 나눔글꼴이 설치되어 있지 않습니다.

이 사이트를 나눔글꼴로 보기 위해서는
나눔글꼴을 설치해야 합니다.

설치 취소

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5