<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride All
    ...
  </Directory>
  ...
</VirtualHost>

In order to prevent the htaccess lookups on the filesystem without losing the htaccess functionality – at least at the DocumentRoot level- I transformed the configuration to the following:

<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride None
    Include /home/example.org/public_html/.htaccess
    ...
  </Directory>
  ...
</VirtualHost>

Let’s see what we have accomplished with this:

1. httpd does not waste any time looking for and parsing htaccess files resulting in faster request processing,
2. the virtual host administrator can still override the configuration options of the document root manually or through the web interface of the web application.

Seems like a win-win situation performance and functionality wise.

But, as usual, there is no win-win situation without a downside. In this case, the above trick weakens the server’s security. Let’s see how.

Although the configuration of a directory can be set in both httpd.conf and the directory’s htaccess file, not all directives can be used in both contexts. htaccess files support a subset of the directives that can be used in the Directory context within httpd.conf. By including the htaccess file in httpd’s configuration the vhost admin is no longer restricted to that subset of directives.

This means that by implementing the above configuration the virtual host administrator is granted more privileges regarding the configuration of the virtual host. This also means that a potential attacker, that would exploit a vulnerability of the web application, would be granted the same privileges once he got write access to that htaccess file.

So, although this trick may seem like a good idea at first, it is in fact a rather bad idea and should never be used in production, unless you trust the virtual host administrator and the web application. I do not intend to use such a configuration and I do not recommend it. There are by far better ways to speed up Apache.

Your comments and suggestions are welcome.

Related Articles

• .htaccess Cheat Sheet
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Use mod_deflate to Compress Web Content delivered by Apache
• Script for Apache Error Report
• Using the mod_dav_svn SVNParentPath directive with multiple authz files

The problem lies in the way that block ciphers are used in SSL/TLS. Block ciphers are generally operated in one of several modes that define how encrypted blocks are manipulated to ensure complete confidentiality. Cipher Block Chaining, or CBC mode, is used in SSL for all block ciphers, including AES and Triple-DES. The BEAST attack relies on a weakness in the way CBC mode is used in SSL and TLS. Non-CBC cipher suites, such as those using the RC4 stream encryption algorithm, are not vulnerable.

There have been several suggested mitigations that can be put into play from the perspective of the client, such as reorganizing the way the data is sent in the encrypted stream. Servers can protect themselves by requiring a non-CBC cipher suite. One such cipher suite is rc4-sha, which is widely supported by clients and servers.

Researchers have concluded that the RC4 (Alleged RC4) based cipher suites are not vulnerable to the BEAST attack, while CBC (Cipher Block Chaining mode) based cipher suites are. This involves both the TLS 1.0 and the SSL 3.0 protocols. On the contrary, TLS 1.1 and 1.2 have not been found to be vulnerable, but their use is very limited since they haven’t been adopted by the majority of HTTP clients and servers yet.

So, the use of RC4 based ciphers is all that is left for the moment. The security experts have released a list of cipher suites that is suitable for use in the configuration of the mod_ssl module for httpd:

SSLHonorCipherOrder on
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL

They have also released a one-liner list of ciphers suitable for use in the relevant fields of the Local Group Policy Editor in Windows Server boxes.

However, there is no info about configuring the mod_gnutls module for apache to use RC4 based ciphers, so, as a dedicated user of mod_gnutls, I decided to release this tip. All you have to do is set the preferred ciphers in the GnuTLSPriorities directive. In this example we use the TLS 1.0 protocol:

GnuTLSPriorities NONE:+VERS-TLS1.0:+ARCFOUR-128:+RSA:+SHA1:+COMP-NULL

Visiting a secure web site that has been configured using any of the methods described above and by checking the information of the secure connection to that website, you should see the following message:

Firefox message about using RC4 encryption cipher

This means that everything is working correctly.

As always, comments and suggestions are welcome and appreciated.

Related Articles

• Critical vulnerability in Adobe Reader
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• mod_gnutls binary for Apache
• Using SSH for networking
• How to configure and use LIRC

#################################################################################
# mod_python and mod_wsgi compatibility note
#################################################################################
# mod_wsgi will deadlock if run in daemon mode while mod_python is enabled
# do not enable both mod_python and mod_wsgi if you are going to use the
# WSGIDaemonProcess directive
# In previous version of mod_wsgi, apache would segfault when both mod_wsgi
# and mod_python were enabled.  This update does not guarantee that will not
# happen.
#################################################################################
# Do not enable mod_python and mod_wsgi in the same apache process.
#################################################################################

Keep this in mind if you plan to mix both modules under the same Apache instance.

Update: As Graham pointed out in this comment, there is no issue if mod_python 3.3.1 is used. That’s great news because I would miss the flexibility of mod_python when it comes to request processing.

Related Articles

• My running dog
• Spamassassin FH_DATE_PAST_20XX test buggy in 2010
• Making a directory writable by the webserver
• SELinux audit reports script
• Beagle Part II

#! /usr/bin/env bash
#
# Error Report for httpd
#
# Requires:
#   - scanerrlog - http://www.librelogiciel.com/software/ScanErrLog/action_Presentation
#   - jaxml - http://www.librelogiciel.com/software/jaxml/action_Presentation
#
 
cat /var/log/httpd/error_log \
    /var/www/vhosts/*/log/error_log \
    | python /usr/local/bin/scanerrlog.py -f text \
    | /bin/mail -s "`hostname` - Apache Error Report" root@localhost
 
exit 0

Some notes:

1. Make sure that this cronjob runs before log rotation takes place.
2. The above shell script concatenates the error_log files from the main web server and all virtualhosts. Edit the paths to reflect your server configuration and virtualhost layout.
3. Edit the path to scanerrlog.py.

Scanerrlog has some quite nice features that let you further customize the report. Make sure you read the help message.

Related Articles

• SELinux audit reports script
• Strange mod_dav_svn error
• Speed up Apache by including htaccess files into httpd.conf
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• How to integrate seaudit-report in logwatch

I use mod_fcgid to run PHP in fastcgi mode, but I cannot let it run the same amount of Redmine instances as it will bring the server to its knees. Redmine is not a blog. It’s a whole project hosting platform. Each instance will require about 45MB of RAM. I have already experimented with another Apache module that can manage Rails applications, but this will require some extra testing and this is exactly what I am going to do in the following days.

The most unfortunate thing is that I have removed the old platform and, for a couple of weeks now, CodeTRAX serves a 503 Service Unavailable error document, which I consider bad for the website. I hope I find the time to fix this soon.

Related Articles

• Redmine deployment meets social media
• Redmine
• Some Preliminary Redmine Customizations
• delayed-shutdown initscript
• Issues with the feeds are now resolved

LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so

This will resolve the issue.

Related Articles

• Creative Commons v3.0 Licenses Launched
• Using the mod_dav_svn SVNParentPath directive with multiple authz files
• Script for Apache Error Report
• When it comes to error messages…
• Error when using old run/bin installers under Linux

Introducing mod_deflate

Apache prepares the response that will be sent back to the client in several stages. One of those stages involves the modification or conversion of the data using output filters. mod_deflate, once loaded and activated, inserts such a filter, named DEFLATE, in Apache’s chain of output filters, which compresses all data that goes through it according to some rules the web server administator has defined. For instance, one can set the compression level, restrict the compression to particular MIME types or prevent some problematic web browsers or other HTTP clients from receiving compressed data from the server.

mod_deflate also offers an input filter which can be used to decompress compressed HTTP requests, but this feature is outside of the scope of the current document.

Here follow some instructions on how to configure mod_deflate. Most of it can be found inside HTTPd’s official documentation, so you’d better read this resource as well.

Note that all of the following configuration directives can be inserted in Apache’s main server context or can be saved to a file that will be loaded from within the main server or any other virtual host context. If the configuration directives are inserted in the main server context, then they will be inherited by all virtual hosts.

Load mod_deflate

mod_deflate can be loaded like any other Apache module:

LoadModule deflate_module modules/mod_deflate.so

Please note that this directive can only exist in the main server configuration.

Enable Compression

The compression of the data can be enabled for all data that goes through the DEFLATE filter or selectively depending on its MIME type.

To enable the compression for any type of content, insert the following directive:

 SetOutputFilter DEFLATE

Alternatively, to define which filetypes should pass through the DEFLATE output filter use the AddOutputFilterByType directive. The following is an example:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Set the Compression Level

Generally, the deflate compression algorithm is fast enough, so setting the compression level to the maximum (9) will not cause any noticeable trouble, even to relatively old hardware.

DeflateCompressionLevel 9

Custom Rules for problematic browsers

The compression can be turned-off or be restricted to files of type text/html for known problematic web browsers. These are taken from the official documentation.

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Keep track of the compression

Finally you can keep track of the compression in order to evaluate the effectiveness of the use of mod_deflate in your server.

The following directives define some variables, such as:

• instream : the size in bytes of the data as received by the DEFLATE filter.
• outstream : the size in bytes of the compressed data as returned from the DEFLATE filter.
• ratio : the compression ratio, (Output/Input)x100

DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio

Finally, you can define a custom logformat so to be able to record the aforementioned values to a logfile:

LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate

The deflate logformat can be used for the main server’s or for any vhost;s logfile.

Effectiveness of Compression

It is well known that not all document types can benefit the same from compression. Generally, the deflate algorithm can compress text surprisingly fast and with a very high efficiency ratio. On the other hand, it is almost useless when used to compress images which have been prepared for the web such as PNG, JPEG, GIF and generally all other image types in which the data has already been compressed. The same goes for compressed audio files, such as MP3, AAC, OGG, videos, PDF documents and all other already compressed files.

So, the benefits of using mod_deflate to reduce the bandwidth usage and speed up the content delivery are heavily dependent on the type of files your web server delivers.

Browser Support

A web server that sends compressed data to clients would be completely useless if the HTTP clients couldn’t decompress that data. All modern and popular web browsers support accepting content that has been compressed using the gzip or deflate algorithms, so there should be no problem at all.

Appendix I

Here is the complete mod_deflate configuration as described in this article. Save it in a file, named deflate.conf and import it in the main server’s configuration using the Include directive

(Include /path/to/deflate.conf):

#
# mod_deflate configuration
#
LoadModule deflate_module modules/mod_deflate.so
<IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/plain
        AddOutputFilterByType DEFLATE text/html
        AddOutputFilterByType DEFLATE text/xml
        AddOutputFilterByType DEFLATE text/css
        AddOutputFilterByType DEFLATE application/xml
        AddOutputFilterByType DEFLATE application/xhtml+xml
        AddOutputFilterByType DEFLATE application/rss+xml
        AddOutputFilterByType DEFLATE application/javascript
        AddOutputFilterByType DEFLATE application/x-javascript
        DeflateCompressionLevel 9
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
        DeflateFilterNote Input instream
        DeflateFilterNote Output outstream
        DeflateFilterNote Ratio ratio
        LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
</IfModule>

This configuration will be inherited by all virtual hosts.

To disable it just comment out the line that loads the mod_deflate module (#LoadModule ...).

To record mod_deflate‘s specific variable (instream, outstream, ratio) values for a virtual host, just add a new log file of type deflate:

CustomLog /path/to/vhost/logs/deflate_log deflate

This will give you an idea of how efficient is the use of mod_deflate in that particular vhost.

Related Articles

• Optimize and Compress CSS Files
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Script for Apache Error Report
• Speed up Apache by including htaccess files into httpd.conf
• Check Server HTTP Headers with CURL

Related Articles

• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Creative Commons v3.0 Licenses Launched
• How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability
• Forking Apache-licensed software on Github and Bitbucket
• Script for Apache Error Report

Introduction

Searching the web for mod_gnutls binary distribution packages or information on how to set it up returned very few relevant results. This was a surprise, as, at this moment, the only implementation that supports SNI is mod_gnutls. So, I decided to write a tutorial on how to set things up for a test. I hope you find it useful.

The test that is described in this guide includes:

1. The compilation of the mod_gnutls module.
2. The generation of SSL certificates.
3. The configuration of the SSL-enabled name-based virtual hosts.

This test was performed on a server that runs Fedora 7.

Installation

In order to compile mod_gnutls, you will need the development tools for Fedora:

# yum groupinstall "Development Tools"

Install the mod_gnutls dependencies:

# yum install httpd-devel gnutls-devel

As an unprivileged user, download the mod_gnutls distribution and compile it.

$ wget http://www.outoforder.cc/downloads/mod_gnutls/mod_gnutls-0.2.0.tar.bz2
$ tar -xjvf mod_gnutls-0.2.0.tar.bz2
$ cd mod_gnutls-0.2.0
$ ./configure --prefix=/usr
$ make

Do not use the ‘make install‘ script, but perform the installation manually – it is only one library.

As root, copy libmod_gnutls.so to the directory that holds the Apache modules (usually /usr/lib/httpd/modules) and rename it to mod_gnutls.so for consistency:

# cp mod_gnutls-0.2.0/src/.libs/libmod_gnutls.so /usr/lib/httpd/modules/mod_gnutls.so

During the compilation, two keys, dhfile and rsafile, have been generated in the mod_gnutls-0.2.0/data/ directory. It is absolutely important to copy these files in httpd’s configuration directory (usually /etc/httpd/conf/), otherwise mod_gnutls will never work. This is undocumented, and I found out about it after some trial&error.

As root:

# cp mod_gnutls-0.2.0/data/{dh,rsa}file /etc/httpd/conf/

Installation is complete.

SSL certificates

In this test installation, two virtual hosts will be used. Thus, two SSL certificates will be required. Please read my article on how to generate SSL certificates for your servers, as this information is beyond the scope of this document. Alternatively, you may use a ready-made script which will create those certificates for you quickly. Such scripts are shipped will almost all Linux distributions. Please consult your distribution’s documentation for more information.

HTTPd Configuration

The configuration of the Apache web server includes two phases:

1. The configuration of the main server.
2. The configuration of the virtual hosts.

In the following instructions, some brief notes about what each directive does is included. For more detailed information, please consult the mod_gnutls documentation.

Main Server Configuration

This includes setting some general mod_gnutls options, which will be inherited by all virtual hosts.

But, first of all, httpd needs to be set to listen on port 443 (in addition to port 80). Instead of specifying the SSL port only (Listen 443) which will lead httpd to listen to all the available network interfaces, you may specify the exact network interface on which the server will listen. For example:

Listen 192.168.0.1:443

Next, load mod_gnutls:

LoadModule gnutls_module modules/mod_gnutls.so

Add some MIME-types for downloading Certificates and CRLs from your web sites (taken from the mod_ssl configuration):

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

It is suggested that you use a session cache for mod_gnutls. This will increase its performance. In this example, the dbm cache type is used. This cache type requires a directory where mod_gnutls will actually save SSL session data. So, creating a directory for this purpose and giving ownership to the user that runs Apache (usually apache or www-data) is needed. Assuming that the Apache user is apache, as root issue the commands:

# mkdir -m 0700 /var/cache/mod_gnutls_cache
# chown apache:apache /var/cache/mod_gnutls_cache

Now, back to the Apache configuration. The following directive sets the dbm SSL Session Cache for mod_gnutls:

GnuTLSCache dbm "/var/cache/mod_gnutls_cache"

Set a timeout for the SSL Session Cache entries. Usually, this is set to 300 seconds:

GnuTLSCacheTimeout 300

Finally, specify that on the 192.168.0.1:443 interface and port there will be name-based virtual hosts; that is vhosts that share the specified interface and port:

NameVirtualHost 192.168.0.1:443

Virtual Host Configuration

The example virtual hosts are: v1.example.org and v2.example.org. It is assumed that two SSL certificates with the canonical name (CN) correctly set to each of the aforementioned vhost domains have been generated.

In the following vhost configs, only the absolutely required directives have been used. The rest of the options are inherited from the main server.

<VirtualHost 192.168.0.1:443>
    ServerName v1.example.org:443
    GnuTLSEnable on
    GnuTLSCertificateFile /etc/pki_custom/certs/v1.example.org.crt
    GnuTLSKeyFile /etc/pki_custom/private/v1.example.org.key
    DocumentRoot "/var/www/v1/public_html"
</VirtualHost>
<VirtualHost 192.168.0.1:443>
    ServerName v2.example.org:443
    GnuTLSEnable on
    GnuTLSCertificateFile /etc/pki_custom/certs/v2.example.org.crt
    GnuTLSKeyFile /etc/pki_custom/private/v2.example.org.key
    DocumentRoot "/var/www/v2/public_html"
</VirtualHost>

Testing the setup

Having finished with the configuration, review the changes, restart the server and check the error logs for any errors.

Use a web browser to visit each of the virtual hosts by using the HTTPS protocol:

https://v1.example.org/
https://v2.example.org/

Until now, the web server did not support the SNI TLS extension. Therefore, when visiting the v2.example.org virtual host, you would see two warnings in your browser. The first one would be because the vhost’s certificate has not been issued by a trusted Certificate Authority – this is normal as it was you who issued that certificate – and the other one because on a server without SNI support it is actually the V1 vhost’s certificate that is used when visiting V2 vhost over https. Remember the limitation with SSL and name-based virtual hosts?

With mod_gnutls, the server supports the SNI TLS extension. Although the virtual hosts are name-based, no matter which one you visit, the relevant certificate for each vhost is used and the only warning you see is the one about the certificates being self-signed. You can get rid of these by purchasing a certificate that is issued by a trusted Certificate Authority.

Conclusion

mod_gnutls works. Actually, it was a real pleasure to see SNI work!

It is important to note though that mod_gnutls is still in experimental phase. Therefore, performance issues should be considered as normal when using it.

At the moment of writing, my server uses Fedora 7 as an operating system. As I haven’t upgraded my desktop to F7 yet and my server does not have any development tools installed, I compiled mod_gnutls on a Fedora 6 system and used it on Fedora 7. I do not know if that was the reason – and I did not have the necessary free time to investigate – or anything else, but, during the use of mod_gnutls, my server’s load average increased significantly.

I will test mod_gnutls again soon and post the new results, if they are different than the ones I present in this article. I highly recommend that you try it, as it is currently the only way to easily achieve SSL-enabled name-based virtual hosts using the SNI TLS extension. Note, that this extension will be supported by openssl 0.99, so the moment that SNI goes mainstream and such a setup becomes easy and cheap to implement with any Linux distribution is close.

One last thing that has not been mentioned at all is about SNI support in web browsers. Currently, with the exception of Safari (this is unconfirmed, please correct me if I am wrong), the latest versions of all major web browsers, Firefox and other Mozilla-based browsers, Internet Explorer, Opera, support SNI.

Related Articles

• mod_gnutls binary for Apache
• Assign Virtual IPs to your NIC
• Speed up Apache by including htaccess files into httpd.conf
• How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability
• Use mod_deflate to Compress Web Content delivered by Apache

[Update]: Also, another resource of htaccess recipes exists here. I didn’t have the time though to go through all of their sections, but all .htacces rule examples seem very organized and well written too.

Related Articles

• Speed up Apache by including htaccess files into httpd.conf
• ModSecurity Overview
• Awesome AWK Tutorial
• Namespace Declarations With cElementTree
• More Data Recovery Tools