The gnutls and gcrypt packages were updated for Ubuntu 8.04, but they are still not right for mod_gnutls.

• libgnutls-dev (2.0.4-1ubuntu2.5)
• libgnutls13 (2.0.4-1ubuntu2.5)
• gnutls-bin (2.0.4-1ubuntu2.5)
• libgcrypt11-dev (1.2.4-2ubuntu7)
• libgcrypt11 (1.2.4-2ubuntu7)

Introduction

Normally having multiple virtual hosts on Apache with HTTPS is not possible. HTTPS is short for HTTP/SSL which means HTTP encapsulated by SSL (Secure Socket Layer). This means the HTTP traffic sent to the Apache webserver is encrypted using SSL.

The VirtualHost definitions in the Apache configuration are used to specify the SSL options. To know what VirtualHost Apache should use, Apache sneak previews the HTTP header to look for the “HOST” field. With HTTPS the HTTP header can only be previewed after the SSL connection has been established, so technically Apache cannot know what VirtualHost definition to use to set up the SSL connection.

Apache could use the correct SSL options if it knew what VirtualHost definition it should use and luckily that is possible. SSL supports several encryption protocols, the newest being TLS (Transport Layer Security). Technically this is a replacement for SSL and would result in HTTP/TLS instead of HTTP/SSL. TLS has a feature called SNI (Server Name Indication) which is the equivalent of HTTP’s “HOST” field.

There are a few problems with SNI though.The standard SSL/TLS module that comes with Apache is mod_ssl, which is based on OpenSSL. Unfortunately OpenSSL does not support SNI in it’s TLS implementation yet. It has been added to OpenSSL 0.99 and backported to 0.98, but mod_ssl doesn’t support it. GnuTLS is an alternative to OpenSSL and it does support the SNI feature in TLS. A GnuTLS based module for Apache is mod_gnutls, but this is not available as a Ubuntu binary. Internet Explorer 7 only supports SNI on Windows Vista, thus causing the same problem as SSL on Windows XP.

Adding mod_gnutls to Apache

There is no package for mod_gnutls available for Ubuntu so it has to be built from source. mod_gnutls has a few prerequisites that make it tricky to build on Ubuntu:

• GnuTLS (>= 2.4.0)
  • libgcrypt (>= 1.4.0)
  • libtasn1 (included in GnuTLS source package)
  • libgpgerror (>= 1.4.0)

The libgcrypt version available for Ubuntu 8.04 is 1.4.1, but unfortunately that doesn’t seem to work. that means we’ll need to build libgcrypt from source too. The standard libgcrypt11 and libgcrypt11-dev packages are hard to remove and the lib-gpgerror that comes with it is fine, so you might want to leave the old libgcrypt in place and just overwrite them. (The standard libgcrypt is installed in /lib)

~% mkdir gnutls
~% cd gnutls
~/gnutls% sudo apt-get install libgcrypt11 libgcrypt-dev
~/gnutls% sudo rm /lib/libgcrypt*
~/gnutls% wget "ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.gz"
~/gnutls% tar -xvzf libgcrypt-1.4.4.tar.gz
~/gnutls% cd libgcrypt-1.4.4
~/gnutls/libgcrypt-1.4.4% ./configure --prefix=/usr
~/gnutls/libgcrypt-1.4.4% make
~/gnutls/libgcrypt-1.4.4% sudo make install
~/gnutls/libgcrypt-1.4.4% sudo ldconfig
~/gnutls/libgcrypt-1.4.4% cd ..
~/gnutls% rm -Rf libgcrypt-1.4.4

It should be no problem to build GnuTLS now.

~/gnutls% wget "ftp://ftp.gnupg.org/gcrypt/gnutls/gnutls-2.8.1.tar.bz2"
~/gnutls% tar -xvjf gnutls-2.8.1
~/gnutls% cd gnutls-2.8.1
~/gnutls/gnutls-2.8.1% ./configure --prefix=/usr
~/gnutls/gnutls-2.8.1% make
~/gnutls/gnutls-2.8.1% sudo make install
~/gnutls/gnutls-2.8.1% sudo ldconfig
~/gnutls/gnutls-2.8.1% cd ..
~/gnutls% rm -Rf gnutls-2.8.1

With all the prerequisites in place it’s time to build mod_gnutls. The configure probably will not be able to find Apache’s apxs2, so find that first.

~/gnutls% which apxs2
/usr/bin/apxs2
~/gnutls% wget "http://www.outoforder.cc/downloads/mod_gnutls/mod_gnutls-0.5.5.tar.bz2"
~/gnutls% tar -xvjf mod_gnutls-0.5.5.tar.bz2
~/gnutls% cd mod_gnutls-0.5.5
~/gnutls/mod_gnutls-0.5.5% ./configure --prefix=/usr --with-apxs=/usr/bin/apxs2
~/gnutls/mod_gnutls-0.5.5% make
~/gnutls/mod_gnutls-0.5.5% sudo make install
~/gnutls/mod_gnutls-0.5.5% cd ..
~/gnutls% rm -Rf mod_gnutls-0.5.5

Depending on your Apache configuration practice, the module might be loaded differently. Here’s my way.

LoadModule gnutls_module /usr/lib/apache2/modules/mod_gnutls.so

GnuTLSCache dbm /var/cache/apache2/gnutls_cache

~/gnutls% cd /etc/apache2/mods-enabled
/etc/apache2/mods-enabled% sudo ln -s ../mods-available/gnutls.load
/etc/apache2/mods-enabled% sudo ln -s ../mods-available/gnutls.conf
/etc/apache2/mods-enabled% sudo touch /var/cache/apache2/gnutls_cache
/etc/apache2/mods-enabled% sudo chown www-data:www-data /var/cache/apache2/gnutls_cache

That should be it, your mod_gnutls should be functional after restarting Apache.

Creating certificates for GnuTLS

Creating certificates is quite easy, as explained in the articles below. For GnuTLS to accept the certificates however, no MD5 may be used since it’s considered unsecure. Using SHA256 or SHA512 instead is much more secure. The examples below use OpenSSL, but

...
[ CA_default ]
...
default_md				= sha256
...

Setting up OpenSSL to Create Certificates
Setting up SSL Certificates on Apache
Creating PKCS12 Certificates

Creating name based Virtual Hosts with HTTPS

With mod_gnutls in place and the certificates ready name based Virtual Hosts can be added to Apache.

<VirtualHost *:443>
    ServerAdmin admin@example.org
    ServerName vhost1.example.org:443
    DocumentRoot /var/vhosts/vhost1.example.org/public_html

    # Configure TLS
    GnuTLSEnable On
    GnuTLSPriorities NORMAL
    GnuTLSCertificateFile /var/vhosts/vhost1.example.org/ssl.crt/vhost1.example.org-cert.pem
    GnuTLSKeyFile /var/vhosts/vhost1.example.org/ssl.key/vhost1.example.org-key.pem
</VirtualHost>

<VirtualHost *:443>
    ServerAdmin admin@example.org
    ServerName vhost2.example.org:443
    DocumentRoot /var/vhosts/vhost2.example.org/public_html

    # Configure TLS
    GnuTLSEnable On
    GnuTLSPriorities NORMAL
    GnuTLSCertificateFile /var/vhosts/vhost2.example.org/ssl.crt/vhost2.example.org-cert.pem
    GnuTLSKeyFile /var/vhosts/vhost2.example.org/ssl.key/vhost2.example.org-key.pem
</VirtualHost>

Access vhost1.example.ogr and vhost2.example.org and examine the certificates, unless you used the same certificate files, they should be different.

Conclusion

Until OpenSSL and mod_ssl start supporting TLS’ SNI and everyone stops using IE7 (please do!), or until mod_gnutls becomes available for Ubuntu through apt, this procedure should keep your Virtual Hosts secure.

To be able to create a Document Management System in Word using WebDAV on Apache webserver, I did some research on mod_dav, an Apache module to provide WebDAV support. It appears that the authaurisation part of mod_dav is limited to “allow all” / “deny all”, which did not quite suite my needs. The solution needed more fine-grained authorisation on a per-directory level. Another problem was that the authentication and authorisation data was in a database.

Issues

1. Mod_dav does not have a fine-grained authorisation system on a per-directory level.
2. Directory structure is known but unstable.
3. Authorisation data is held in a database and requires complex SQL.

Solution

Fine-grained authorisation

I started by looking at mod_auth and mod_auth_dbd (in combination with mod_dbd), but the SQL useable by mod_dbd only received the username and password as parameters, not the requested URI. What mod_auth module could possibly be used? The solution to this was quite unexpected: mod_auth_script.

Mod_auth_script allows CGI or PHP scripts to handle the authorisation. By looking at the REQUEST_URI the script can easily decide to simulate authorisation by invalidating the authorisation.

I created a PHP script that at first would log the REQUEST_URI and allow access for any username and password. All that is left now is to handle authorisation based on the directory structure and fetch the real authorisation from the database.

<Location /dav>
	Options			+Indexes
	Dav				On
	AuthType		Basic
	AuthName		"PHP based authentication for mod_dav"
	AuthScriptFile	/any_full_path_your_apache_can_get_to/.auth.php
	Require			valid-user
</Location>

<?php
/**
 * PHP based authentication for mod_dav
 * @author Jeffrey Ridout
 * @link http://blog.itwarlocks.com
 * @license http://creativecommons.org/licenses/by-sa/3.0
 * @date 2009-04-27
 * @version 0.0.1
 */

/**
 * $_SERVER['REQUEST_URI'] contains the location accessed by the WebDAV client.
 * Using parse_url enables easy access to all URL parts.
 */
$requestURI = parse_url($_SERVER['REQUEST_URI']);

/**
 * Accessing some pages directly, like a page containing phpinfo(), will result in several
 * calls to .auth.php. These do not need to be logged.
 */
if ($requestURI['path'] != $_SERVER['SCRIPT_NAME']) {
	$logFile = fopen('auth.log', 'a');
	fwrite($logFile, "${_SERVER['PHP_AUTH_USER']}:${_SERVER['PHP_AUTH_PW']}@${requestURI['path']}\n");
	fclose($logFile);
}

/**
 * At this stage we always allow access.
 * mod_auth_script catches custom headers to define the result to mod_auth.
 * auth-script:allow|deny|prompt Defines the authentication result.
 */
header('auth-script:allow');

/* EOF */
?>

Directory structure

The sub-directories are named according to a strict rule, but they are unknown to exist at design-time. Therefore the script needs to analyse the destination location and extract the key to be used for authorisation.¹

/<Day>/<Month>/<Year>/<MemberID>
	<Day>:		00 - 31
	<Month>:		00 - 12
	<Year>:		00 - 99
	<MemberID>:	DDMMYY#####

Directory structure

This directory structure allows for a quite straight forward check to get the MemberID.²

<?php
/**
 * PHP based authentication for mod_dav
 * @author Jeffrey Ridout
 * @link http://blog.itwarlocks.com
 * @license http://creativecommons.org/licenses/by-sa/3.0
 * @date 2009-04-27
 * @version 0.0.2
 */

/**
 * $_SERVER['REQUEST_URI'] contains the location accessed by the WebDAV client.
 * Using parse_url enables easy access to all URL parts.
 */
$requestURI = parse_url($_SERVER['REQUEST_URI']);

/**
 * Accessing some pages directly, like a page containing phpinfo(), will result in several
 * calls to .auth.php. These do not need to be logged.
 */
if ($requestURI['path'] != $_SERVER['SCRIPT_NAME']) {
	$logFile = fopen('auth.log', 'a');
	fwrite($logFile, "${_SERVER['PHP_AUTH_USER']}:${_SERVER['PHP_AUTH_PW']}@${requestURI['path']}\n");
	fclose($logFile);
}

/**
 * At stage 2 we can simulate a real authorisation lookup by using a simple array.
 * mod_auth_script catches custom headers to define the result to mod_auth.
 * auth-script:allow|deny|prompt Defines the authentication result.
 */
$blocked = array (
	'01010154321',
	'31037912345'
);

/**
 * The directory name to search for might be in the path or destination filename.
 * .../blocked-dir
 * or
 * .../blocked-dir/
 * or
 * .../blocked-dir/...
 */
$path = dirname($requestURI['path']);
$dir = basename($path);
$match = basename($rURL['path']);
if (preg_match('#$\d{11}^#', $dir)) {
	$match = $dir;
}
if (!in_array($match, $blocked)) {
	header('auth-script:allow');
} else {
	/* Simulate authorisation by denying access.
	 * Normal authentication would return auth-script:prompt
	 */
	header('auth-script:deny');
}

/* EOF */
?>

Authorisation data

The data that determines the authorisation can come from different sources; files, LDAP, RADIUS, database, …

In my case the authorisation result was retrieved from complex SQL using a stored procedure in a Sybase Database.

Whatever you use as your source of authentication/authorisation, remember that request can be asynchrounous and parallel. For a file base method that means never locking the file and opening it as “read-only”, for an external connection based method, it means using persistent connections.

Conclusion

Just because mod-dav and mod_auth don’t support your exact needs, doesn’t mean there is no solution. Using mod_auth_script to create your own tailored flexible solution works perfectly. As an added bonus this adds a new processing layer to PHP by allowing PHP to be executed at a much earlier stage. Using a PHP script to authorise also allows authorisation of non-existing destination URLs or destinations which access is based on complex business logic.

All code in this post is licensed under Creative Commons Attribution Share Alike.

1. You may notice that year only has 2 digits. so no, it’s not Y2K safe…
2. MemberID in this case is the Norwegian version of a social security number.