Escolar Documentos
Profissional Documentos
Cultura Documentos
Page 1 of 14
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 SSL SSL SSL Handshake Protocol Change Cipher Spec Protocol Alert Protocol Record Layer
The position of the above protocols according to the TCP/IP model has been illustrated on the following diagram in Figure 1.
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 2 of 14
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).
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 3 of 14
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
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 4 of 14
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.
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 5 of 14
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).
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 6 of 14
--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
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 7 of 14
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>
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 8 of 14
AddEncoding x-compress AddEncoding x-gzip AddType application/x-compress AddType application/x-gzip AddType application/x-tar AddType application/x-x509-ca-cert AddType application/x-pkcs7-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
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 9 of 14
SSLVerifyClient none SSLProxyEngine off <IfModule mime.c> AddType application/x-x509-ca-cert AddType application/x-pkcs7-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 mkdir mkdir mkdir 022 /usr/local/apache2/conf/ssl.key /usr/local/apache2/conf/ssl.crt /usr/local/apache2/conf/ssl.crl
.crt .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'
/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:*************
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 10 of 14
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.
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.
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 11 of 14
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.
Troubleshooting
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 12 of 14
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
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 13 of 14
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.
http://www.securityfocus.com/print/infocus/1818
12/10/2008
Page 14 of 14
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.
http://www.securityfocus.com/print/infocus/1818
12/10/2008