Instructions d'installation

Cette page est également disponible au format PDF.

• [1] Prérequis
• [2] Installation de Perl
  • [2.1] Préparation
  • [2.2] Télécharger Perl 5.8
  • [2.3] Sauvegarde
  • [2.4] Configuration de la compilation
  • [2.5] Compilation
  • [2.6] Installation
  • [2.7] Test
• [3] Installation de Apache et mod_perl
  • [3.1] Préparation
  • [3.2] Configuration de la compilation
  • [3.3] Compilation
• [4] Installation de mod_ssl
  • [4.1] Préparation
  • [4.2] Configuration de mod_ssl
  • [4.3] Recompilation de Apache
  • [4.4] Test de fonctionnement
• [5] Installation des modules Perl
  • [5.1] Libapreq
  • [5.2] Expat
  • [5.3] XML::Parser
  • [5.4] LWP
  • [5.5] Crypt::SSLeay
• [6] Configuration de Apache pour ProxyFilter
  • [6.1] Prérequis
  • [6.2] Chargement des modules
  • [6.3] Chargement de ProxyFilter
  • [6.4] Utilisation de HTTPS
• [7] Apache et SSL
  • [7.1] Créer son propre CA
  • [7.2] Générer et signer le certificat du serveur Web
  • [7.3] Installer le certificat sur le serveur Web
  • [7.4] Configurer Apache pour SSL
  • [7.5] Ajouter un certificat CA au navigateur Web
  • [7.6] Forcer l'utilisation de HTTPS
• [8] Références

ProxyFilter requiert une installation fonctionnelle de Apache, Perl et mod_perl. Ceux-ci sont préinstallés avec de nombreuses distributions de Unix (Linux, Mac OS X, Solaris), mais souvent il ne s'agit pas des dernières versions et elles ne sont pas compilées de façon optimale pour ProxyFilter. Dans de nombreux cas, il faudra donc compiler soi-même Perl, mod_perl et Apache depuis les sources, opérations que nous détaillons ici.

L'installation de quelques modules Perl provenant du CPAN (LWP, XML::Parser, Apache::Request) est également requise par ProxyFilter. Les modules sont un moyen pour les développeurs Perl de ne pas systématiquement "réinventer la roue" mais d'utiliser autant que possible du code existant. Il ne faut pas confondre les modules Perl, qui sont des bibliothèques d'extension au langage Perl et les modules Apache qui servent à personnaliser le fonctionnement du serveur Apache, gérer de nouveaux protocoles, etc...

Pour le développement de ProxyFilter, nous avons utilisé les versions suivantes :

• Mac OS X 10.2.8
• Apache 1.3.29
• Perl 5.8
• mod_perl 1.29
• libwww-perl 5.76
• Expat 1.95.2
• XML::Parser 2.34
• libapreq 1.3
• GDBM 1.8.3
• MM 1.3.0
• OpenSSL 0.9.7c
• mod_ssl 2.8.16-1.3.29
• Crypt::SSLeay 0.51
• HTML::Parser 3.35
• HTML::Tagset 3.03
• MIME::Base64 2.21
• URI 1.28
• Digest::MD5 2.32
• Apache::Test 1.07

Les instructions qui suivent s'appliquent à ces versions des logiciels. Cela ne signifie pas que ProxyFilter ne puisse pas être utilisé avec d'autres versions (plus récentes), mais simplement que ProxyFilter n'a été testé et certifié qu'avec ces versions. En cas de problème d'installation ou de fonctionnement, tentez d'utiliser ces versions avant de chercher plus loin.

À l'exception de Mac OS X (qui est payant), les sources de tous ces logiciels, bibliothèques ou modules figurent sur le CD-Rom remis avec ProxyFilter, et la plupart d'entre-eux sont inclus dans l'archive tarball qui peut être téléchargée à partir du site de ProxyFilter.
 

Perl 5.6 est inclus dans Mac OS X 10.2 "Jaguar", mais comme nous devons recompiler Apache (voir plus bas), il est également utile sinon nécessaire d'installer la dernière version 5.8 de Perl, plus robuste.

Pour connaître la version de Perl actuellement installée, ouvrir le terminal et taper :

On voit donc qu'il s'agit de la version 5.6 d'origine compilée par Apple et prévue pour fonctionner avec le Apache et mod_perl 1.3.27 livrés avec le système. Nous allons maintenant expliquer les étapes nécessaires à l'installation de Perl 5.8 sous Jaguar.

Le chapitre qui suit est une adaptation française du tutoriel de Apple "Installing Perl 5.8 on Jaguar" modifié sur la base de mes propres expériences. En cas de besoin, on pourra se reporter au document original.

2.1 Préparation

L'installation de Perl n'est pas fondamentalement différente des autres applications Unix : télécharger les sources, les compiler et les installer, mais elle demandera un peu de patience : en fonction de la puissance de la machine, l'installation pourra réclamer une heure ou plus.

On s'assurera tout d'abord de disposer des derniers Apple Developer Tools, livrés sur un CD-Rom séparé avec Jaguar ou téléchargeables gratuitement moyennant un raccordement haut débit sur le site de Apple Developer Connection.

Les utilisateurs de Fink peuvent rencontrer des problèmes avec la procédure ci-après (messages d'erreurs de symbole lors de l'exécution de certains programmes Perl) : il est recommandé de désinstaller Fink avant de continuer ou de consulter les archives de macosx@perl.org pour plus de détails. Après avoir installé Perl 5.8, la version de mod_perl livrée avec le système ne fonctionnera plus : il sera nécessaire de recompiler mod_perl (voir chapitre 3).

2.2 Télécharger Perl 5.8

Les sources de Perl peuvent être téléchargées sur les divers serveurs miroirs du CPAN. Remplacer dans les commandes ci-dessous l'adresse du miroir le plus proche :

Ces commandes ont pour effet de créer le dossier /usr/local/src, de lui donner les bonnes permissions et d'y télécharger et décompresser les sources de Perl 5.8. On se déplace ensuite à l'intérieur du dossier contenant les sources.

2.3 Sauvegarde

Cette étape est facultative. Sachant que Perl 5.8 va écraser la version de Perl 5.6 actuellement installée, vous pouvez souhaiter effectuer une sauvegarde des dossiers dans lesquels Perl 5.6 réside afin de pouvoir revenir en arrière si l'installation se passe mal. Il faut sauvegarder les dossier suivants :

Ainsi que quelques fichiers binaires (perl, pod2html, h2xs, etc...) dans /usr/bin.

2.4 Configuration de la compilation

La distribution des sources de Perl est la même pour toutes les plateformes Unix supportées. C'est pourquoi il est nécessaire de lancer un script configure qui teste les propriétés de la plateforme et prépare un MakeFile en conséquence.

Le paramètre /usr indique d'installer Perl 5.8 à la place de l'actuelle version 5.6 livrée par Apple (ce qui permet de reconnaître les modules existants situés dans /System/Library/Perl). Si tout s'est bien passé, le script doit se terminer ainsi après quelques minutes :

Nous sommes maintenant prêts à compiler Perl

2.5 Compilation

La compilation se lance au moyen de la commande make et peut durer entre 10 et 20 minutes selon la puissance de la machine.

La commande doit se terminer avec la phrase "Everything is up to date. Type 'make test' to run test suite" qui indique que le programme a été compilé avec succès.

Certains tests sont ignorés car ils ne s'appliquent pas à la plateforme, mais la plupart des tests doivent retourner "OK". Vous ne devriez n'avoir que 2 tests qui échouent, relatifs à Berkley DB, mais qui peuvent être ignorés dans le cas présent car nous n'aurons pas besoin de cette fonctionnalité.

2.6 Installation

La dernière étape consiste à installer dans le système les fichiers fraichement compilés :

Cette étape dure moins de 5 minutes. Les modules sont installés dans /Library/Perl, les fichier binaires dans /usr/local/bin et la documentation de Perl dans /usr/local/share/man.

2.7 Test

La meilleure solution pour vérifier que l'installation de Perl fonctionne consiste à exécuter un programme Perl réel, mais pour l'instant nous pouvons nous contenter des commandes suivantes :

Bon nombre de modules standards sont préinstallés avec Perl, mais les modules tiers préalablement installés sous Perl 5.6 devront être recompilés pour pouvoir être utilisés avec Perl 5.8. Pour cette raison, il est important de faire la mise à jour vers Perl 5.8 avant d'installer les modules Perl dont ProxyFilter a besoin (LWP, XML-Parser, etc...)
 

Le système Mac OS X 10.2.8 est livré avec Apache 1.3.27 et mod_perl préinstallés. Cela dit, il ne suffit pas d'avoir compilé et installé un Perl 5.8 plus stable et plus récent nous-même pour que Apache puisse en tirer parti : il faut pour cela recompiler mod_perl.

Un module Apache écrit en C peut être soit compilé statiquement dans l'exécutable du serveur, soit compilé comme une bibliothèque dynamique partagée (dynlib). L'avantage de compiler un module statiquement avec le serveur est que le serveur est un peu plus rapide à se lancer et tourne un peu plus vite, l'inconvénient est une perte en souplesse puisque l'on ne peut pas désactiver un module en commentant simplement la ligne du fichier de configuration : il faut recompiler Apache.

La version 1.3.27 de Apache compilée par Apple n'a presque aucun module compilé statiquement (juste le strict minimum). Tous les modules fournis sont mis à disposition sous forme de bibliothèques dynamiques (fichier .so), y compris mod_perl. Il est pourtant connu que mod_perl est plus stable lorsqu'il est compilé statiquement dans Apache. Nous allons donc profiter de cette recompilation forcée de mod_perl pour l'inclure dans notre propre version de Apache.

Il est intéressant d'afficher quels sont les modules compilés statiquement dans l'exécutable du serveur avec la version Apple de Apache 1.3.27 :

À l'exception de mod_so qui permet justement de gérer les modules sous forme de bibliothèques dynamiques partagées, tous les autres modules sont externes et doivent être importés à l'aide des directives LoadModule et AddModule :

Plusieurs de ces modules gagneraient à être inclus statiquement dans l'exécutable du serveur sachant que nous avons presque toujours besoin d'eux. Nous allons donc compiler notre propre Apache 1.3.29 (dernière version de la génération 1.3 à l'heure où ces lignes sont écrites) avec mod_perl. Nous profiterons également d'inclure mod_rewrite, mod_proxy et mod_ssl statiquement dans le serveur. Mod_ssl est nécessaire pour permettre d'utiliser SSL entre le client et le proxy, mais non entre le proxy et le serveur.

Les explications qui suivent sont adaptées du document "Build Your Own Apache Server with mod_perl" de David E. Wheeler.

3.1 Préparation

Ici encore, les Apple Developer Tools comprenant gcc 3.3 sont nécessaires à la compilation de mod_perl et Apache, ils peuvent être téléchargés gratuitement sur le site du ADC.

Il s'agit de télécharger les sources de Apache à partir de l'un des serveurs miroirs. Remplacer dans les commandes suivantes la version 1.3.xx la plus récente (ProxyFilter n'a pas été testé avec le nouvel Apache 2.x).

Nous téléchargeons et décompressons dans le même dossier /usr/local/src les sources de Apache 1.3.29 et le mod_perl 1.3.29 correspondant.

Il s'agit également de télécharger libapreq, une suite de modules pour manipuler la requête du client, des cookies et les données des formulaires plus rapidement qu'avec les modules CGI conventionnels de Perl au sein de l'environnement Apache.

3.2 Configuration de la compilation

Nous sommes maintenant prêts à compiler les différents éléments logiciels. Perl 5.8 est supposé avoir été installé et testé à ce stade. Nous commençons par compiler mod_perl.

Le script MakeFile.PL crée le Makefile qui sera utilisé pour compiler mod_perl. L'option APACHE_SRC indique au script où trouver les sources de Apache. L'option EVERYTHING=1 est importante : elle active toutes les fonctions de mod_perl, lui permettant ainsi d'être appelé par Apache lors de chacune des phases de la requête (hooks).

3.3 Compilation

Nous pouvons maintenant compiler et installer mod_perl :

Il reste à compiler Apache lui-même à l'aide du script configure auquel on passe des options de compilations. Ces options déterminent notamment quels modules seront inclus statiquement dans l'exécutable httpd.

--with-layout=Apache signifie que nous souhaitons que Apache soit installé à l'emplacement par défaut, c'est à dire dans /usr/local/apache. Ainsi, il ne se mélange pas et ne remplace pas la distribution de Apache livrée d'origine avec le système qui réside dans /usr.

--enable-module=rewrite permet de compiler statiquement mod_rewrite avec le serveur. Bien qu'il ne soit pas indispensable, il permet de réécrire de façon puissante les URL en amont de ProxyFilter.

--enable-module=so compile statiquement mod_so dans le serveur. C'est le seul module qui ne peut pas être compilé comme un dynlib car justement son rôle est de gérer au démarrage du serveur le chargement des modules compilés comme dynlibs.

--enable-module=proxy compile statiquement mod_proxy avec le serveur, il peut être utilisé conjointement avec mod_rewrite pour réaliser un proxy non-filtrant mais n'est pas indispensable.

--activate-module=src/modules/perl/libperl active le mod_perl que nous avons précédemment compilé.

--disable-shared=perl force mod_perl à être inclu statiquement dans le serveur plutôt que comme bibliothèque dynamique partagée (dynlib).

--disable-rule=EXPAT désactive l'inclusion de Expat dans Apache. Cette option est requise au bon fonctionnement de XML-Parser utilisé par ProxyFilter pour lire ses fichiers de configuration.

Lorsque configure a terminé son travail, nous sommes prêts à compiler et installer Apache :

À la fin de l'installation, le message suivant s'affiche :

Apache 1.3.29 réside dans /usr/local/apache où l'on trouve les sous-répertoires suivants :

Pour placer les modules Perl pour Apache, nous allons créer un nouveau répertoire :

Il s'agit maintenant d'installer libapreq qui inclut notamment Apache::Request et permet à un module Perl de manipuler la requête Apache, décomposer les paramètres GET et POST, les cookies, etc...

Ces instructions téléchargent, compilent et installent Apache::Test (prérequis) et libapreq.
 

4.1 Préparation

Mod_ssl ajoute à Apache le support des protocoles SSL et TSL permettant de crypter la communication entre le client et le serveur. Si l'on souhaite utiliser du HTTPS entre le client et ProxyFilter, il est donc nécessaire de compiler Apache avec le support de mod_ssl. La communication HTTPS entre ProxyFilter et le serveur ne nécessite pas l'installation de mod_ssl sur le proxy : il suffit de compiler LWP avec le support de SSL (voir plus haut).

Les instructions suivantes permettent d'installer MM, une bibliothèque gérant le partage de blocs mémoire entre processus enfants de Apache qui n'est pas strictement requise par mod_ssl, mais qui permet d'en augmenter les performances dans un environnement de production.

Il n'est pas nécessaire de faire un install car nous indiquerons l'emplacement de MM lors de la recompilation de Apache afin qu'il puisse l'inclure.
Depuis quelques temps, OpenSSL est livré en standard avec Mac OS X, il n'est donc plus strictement nécessaire de l'installer avant mod_ssl. La version livrée avec le système est toutefois, comme souvent, un peu ancienne. Dans un environnement de production où la sécurité est capitale, on choisira de télécharger la dernière version de OpenSSL, de le compiler et de l'installer soi-même :

Nous devons maintenant veiller à corriger un problème lié à la version de Berkley DB livrée avec le système Mac OS X. Berkley DB, également connu sous le nom de DBM, est un petit système de base de données qui est requis par mod_ssl. Malheureusement, la version livrée avec Mac OS X comporte un bug obscur qui empêche mod_ssl de s'installer en affichant d'erreur suivant lors de la compilation :

Apple et l'équipe de développement de mod_ssl ont été avertis de ce problème, et en attendant une correction définitive, la solution vient de David Wheeler qui propose un patch à appliquer aux sources de Apache avant de le recompiler :

Une autre possibilité consiste à installer GDBM (la version GNU de DBM) et de se passer complétement du DBM intégré par Apple dans Mac OS X, une installation relativement aisée mais que nous ne détaillerons pas ici.

4.2 Configuration de mod_ssl

Il s'agit de télécharger mod_ssl en prenant garde à choisir le bon numéro de version : mod_ssl comporte deux numéros de version, le premier (ici 2.8.16) s'applique à mod_ssl lui-même, le second (ici 1.3.29) à Apache. Il faut impérativement choisir des versions de Apache et mod_ssl qui correspondent.

Une fois l'archive extraite, on lance le script de configuration en lui passant en paramètre l'emplacement du dossier où résident les sources de Apache pour qu'il les modifie en conséquence.

La commande configure doit se terminer en retournant :

Les sources de Apache ayant été modifées pour inclure le support de mod_ssl, nous sommes prêts à recompiler Apache.

4.3 Recompilation de Apache

Il faut auparavant régler quelques variables d'environnement. La syntaxe ci-dessous d'applique au shell tcsh (C shell amélioré) par défaut de Mac OS X.

La première instruction indique d'utiliser la version de OpenSSL livrée avec le système, elle sera recherchée dans le PATH. La seconde instruction indique la position relative de la bibliothèque MM précédemment installée et qui améliore les performances de mod_ssl en permettant le partage de mémoire entre processus enfants de Apache.

Si l'on a compilé sa propre version de OpenSSL comme expliqué ci-dessus, on indiquera l'emplacement du dossier source de OpenSSL à la place :

Nous pouvons maintenant recompiler Apache comme auparavant mais en ajoutant deux lignes permettant d'y inclure mod_ssl comme un DSO (objet dynamique partagé) :

À la fin de la compilation le message suivant est affiché :

Le script nous propose de générer le certificat qui sera installé sur le serveur (ou plutôt dans notre cas sur le proxy). Si l'on dispose d'un certificat X.509 existant on peut l'installer ainsi :

Si le but est juste de tester SSL sans faire de production, on pourra utiliser l'instruction suivante qui génère un certificat auto-signé :

Dans cet exemple nous choisirons la seconde option. Une paire de clés est générée, puis un certificat. Ils sont installés dans conf/ssl.key/server.key et conf/ssl.crt/server.crt relativement à la racine du serveur.

Avant d'installer notre nouvelle copie de Apache, il est plus prudent de faire une sauvegarde de l'ancienne. Pour cela, nous nous contentons de renommer le dossier contenant Apache.

Nous pouvons maintenant procéder à l'installation de la nouvelle version de Apache dans /usr/local/apache, comme indiqué précédemment par l'option --with-layout=Apache du script configure :

4.4 Test de fonctionnement

Pour tester le bon fonctionnement de Apache et SSL, nous lançons le serveur en activant SSL :

Le serveur démarré, ouvrir un navigateur Web (ici Safari 1.0) et saisir l'adresse du serveur Web (127.0.0.1 si en local) précédée du scheme http. La page d'accueil par défaut de Apache s'affiche, indiquant que le serveur fonctionne.

Tentons maintenant d'appeler cette même adresse, mais en remplaçant le scheme http par https, initiant ainsi une connexion SSL :

Le message d'erreur de sécurité qui s'affiche indique que l'autorité de certification dont émane le certificat n'est pas sur la liste des certificats racine de confiance du navigateur, ce qui est normal puisqu'il s'agit d'un certificat d'essai autosigné. Pour s'affranchir de ce message d'erreur, il faudrait demander moyennant finance un certificat à un CA reconnu comme VeriSign, ou installer le certificat de notre propre CA dans la liste des certificats de confiance du navigateur.

Si nous cliquons sur Continuer, la connexion SSL à 128 bits est tout de même établie. La communication est bien cryptée mais le client ne peut pas être certain qu'il est connecté au bon serveur (un homme du milieu pourrait dévier le trafic et insérer son propre certificat). Une icône de cadenas qui, dans Safari, s'affiche en haut et à droite de la fenêtre, permet de vérifier que la connexion est sécurisée :

 

5.1 Libapreq

Cette bibliothèque faisant partie du projet Apache permet de manipuler les données de la requête du client, extraites les paramètres transmis par application/x-www-form-urlencoded ou multipart/form-data ainsi que les cookies. Elle met à disposition des programmes Perl le module Apache::Request dont ProxyFilter a besoin.
Il est recommandé de télécharger la version 1.3 de libapreq pour Apache 1.3.29. Pour pouvoir utiliser Apache::Request, mod_perl doit avoir été compilé avec l'option EVERYTHING=1 comme expliqué précédemment ou au minimum avec le support de Apache::Table activé. L'installation de libpreq nécessite en outre le module Apache::Test qui peut être trouvé sur le CPAN et dont l'installation ne présente pas de difficulté.

L'installation de libapreq se fait en deux phases : compilation et installation des bibliothèques C à l'aide de configure et make, puis installation des modules Perl à l'aide du script Makefile.PL et de make.

5.2 Expat

Le module XML::Parser utilisé par ProxyFilter repose sur Expat, il faut donc préalablement installer ce dernier, ce qui est relativement aisé.

Commencez par télécharger les sources de Expat (nous avons utilisé la version 1.95.2 pour le développement de ProxyFiter, les versions plus récentes posaient des problèmes de compilation sous Mac OS X 10.2.8, sauf via Fink qui a l'inconvénient de l'installer à un endroit non-standard du système). Décompiler l'archive dans /usr/local/src et lancer le script de configuration qui prépare la compilation :

Afin de corriger un problème lié compilateur cc de Mac OS X qui ne supporte pas l'attribut -static, il est maintenant nécessaire d'éditer le Makefile qui a été généré :

Nous pouvons à présent compiler et installer Expat :

À la fin de l'installation, vous devriez voir s'afficher ce message :

5.3 XML::Parser

Une fois Expat installé, XML::Parser s'installe simplement en allant chercher les sources sur le CPAN et en exécutant le script Makefile.PL comme pour la plupart des modules Perl.

Sur certains système, le script Makefile.PL n'arrive pas à trouver de lui-même l'emplacement de Expat. Dans ce cas il faut lui indiquer explicitement :

La commande make test effectue un certain nombre de tests afin de vérifier le bon fonctionnement du module avant de l'installer. Nous avons relevé 2 erreurs parmi ces tests, mais qui ne semblent pas être très importantes puisque le module s'installe et fonctionne correctement par la suite.

5.4 LWP

Afin de générer des requêtes HTTP internes à destination du serveur, ProxyFilter nécessite le module LWP qui fait partie du paquetage libwww-perl.

Il est au préalable recommandé d'installer les paquetages suivants avant d'installer libwww-perl :

• URI
• MIME-Base64
• HTML-Parser
• libnet
• Digest-MD5

Le script Makefile.PL vérifie que ces paquetages soient installés. D'autre part, avant d'installer LWP, il faut faire une copie de l'utilitaire /usr/bin/head qui fait partie du système BSD et sert à scanner les premières lignes d'un fichier. La raison est que LWP installe un utilitaire /usr/bin/HEAD et que comme le système de fichier HFS est insensible à la casse, HEAD viendrait écraser head. Cela est d'autant plus gènant que head, une fonction retournant les premières lignes d'un fichier, est utilisé par de nombreux scripts d'installation.

Déplaçons donc le head existant dans un autre répertoire :

LWP peut être téléchargé soit depuis son site officiel, soit à partir du CPAN. L'installation ne présente pas de difficulté particulière, elle s'effectue de la même façon que les autres modules Perl.

Durant la phase de test, LWP a besoin d'une connexion active à Internet pour effectuer quelques tests de bon fonctionnement. Le script d'installation demande également si l'on souhaite copier certains utilitaires parmi lesquels lwp-request et lwp-rget dans /usr/bin : ceux-ci ne sont pas nécessaires à ProxyFilter, mais cela ne gène pas de les installer.

5.5 Crypt::SSLeay

Pour que LWP puisse rediriger vers des URLs en https, c'est à dire pour établir une connexion SSL entre le proxy et le serveur final, il est nécessaire d'installer le module Crypt::SSLeay sur lequel LWP s'appuie.
Les sources de Crypt::SSLeay peuvent être téléchargées sur le CPAN. Il est important d'installer OpenSSL (expliqué plus haut) ou SSLeay avant de tenter d'installer ce module.

Ce chapitre n'est pas un descriptif de la syntaxe de configuration de ProxyFilter (voir la documentation dédiée, les exemples de fichiers de configuration et les DTDs pour cela), il se contente d'expliquer comment configurer Apache pour ProxyFilter.

L'archive tarball de ProxyFilter contient déjà toutes les sources nécessaires à la recompilation du produit, une version précompilée de Apache pour Mac OS X 10.2, et des fichiers de configuration prêts à l'emploi httpd.conf et httpd_proxyfilter.conf conçu pour ProxyFilter. Toutefois, nous détaillons ci-après les modifications à apporter à un fichier httpd.conf existant pour utiliser ProxyFilter.

6.1 Prérequis

Nous admettons que vous disposez d'un Apache 1.3.x et mod_perl parfaitement fonctionnels, installés selon les instructions du chapitre 3. Optionnellement, vous avez également installé OpenSSL et mod_ssl comme expliqué au chapitre 4, s'il est nécessaire d'établir des connexions sécurisées entre le client et le proxy. Vous devez avoir au minimum installé Expat, XML::Parser et LWP.

Votre installation de Apache doit en principe ressembler à ça :

Nous y créons un répertoire perl destiné à accueillir les modules Perl pour Apache et les éventuels cgi écrits en Perl.

Pour que mod_perl puisse trouver les modules dans ce répertoire, il faut l'ajouter à son path de recherche des modules, à la manière du CLASSPATH en Java. Pour cela, une solution consiste à créer une fichier n'initialisation de mod_perl qui règle le path en conséquence et précharge des modules Perl d'usage courant.

Créer un fichier perl/startup.pl et y copier le contenu suivant :

Sur la première ligne, il faut indiquer le chemin d'accès à l'interpréteur Perl 5.8 (et non le Perl 5.6 livré avec le système qui ne fonctionnerait pas avec le mod_perl que nous avons nous-même compilé). L'instruction use lib permet de modifier le path de recherche des modules inclus, il prend en paramètre un chemin d'accès absolu que nous créons relativement à la racine du serveur grâce à la fonction server_root_relative().

Les lignes suivantes préchargent certains modules lors du démarrage du serveur qui seront ainsi plus rapidement accessibles par la suite et ne devront pas être importés au début de chaque script. Ce fichier doit retourner la valeur 1 pour signifier qu'il s'est exécuté correctement, sinon le démarrage du serveur est interrompu.

Copier ensuite les sources de ProxyFilter dans un répertoire perl/Apache afin de respecter la hiérarchie des paquetages :

Y copier également le module Hello qui permet de tester le bon fonctionnement de mod_perl :

Dans le httpd.conf, au-dessous du chargement de mod_perl, placer les instructions suivantes pour initialiser mod_perl :

Il est recommandé de rendre Apache aussi anonyme que possible en désactivant l'entête Server. Sous Apache 1.3, celle-ci ne peut être totalement supprimée sans modifier les sources du serveur, mais on peut la simplifier de sorte à donner moins de détails. Le problème est que certains modules comme mod_ssl et mod_php4 prennent un malin plaisir à modifier cette entête pour se faire de la publicité. ProxyFilter ne permet pas d'erradiquer complétement cet entête car son rayon d'action est limité à celui de mod_perl qui est à égalité avec les autres modules. Sous Apache 2.x, un module dédié mod_header permet de supprimer complétement cet entête de la réponse. On en profitera également pour supprimer la signature de Apache dans les indexs de répertoire et dans les messages d'erreur générés par le serveur.

6.2 Chargement des modules

Il est conseillé de n'activer au niveau de Apache que les modules strictement nécessaires. La sécurité et les performances du serveur n'en seront que meilleures, car toute fonctionnalité additionnelle introduit un risque de vulnérabilité et d'instabilité, et signifie que chaque processus serveur prendra davantage de mémoire et donc que celle-ci sera plus vite saturée.

Les modules qui sont compilés statiquement dans l'exécutable du serveur (httpd) doivent être activés à l'aide d'une unique directive AddModule. Les modules compilés comme DSO doivent en plus être chargés au préalable à l'aide d'une directive LoadModule :

6.3 Chargement de ProxyFilter

ProxyFilter gère la phase de la requête de génération du document à retourner (content handler). Son activation nécessite une directive AddHandler pour déléguer cette phase à mod_perl et une directive PerlHandler pour indiquer à mod_perl le handler de quel module Perl appeler.

Une syntaxe alternative mais équivalente est de remplacer PerlModule par un '+' devant l'attribut de PerlHandler pour forcer le chargement et la compilation du module au démarrage du serveur.

La directive PerlSetVar doit être située avant PerlHandler dans le fichier de configuration. Elle règle une variable d'environnement indiquant à ProxyFilter l'emplacement de son fichier de configuration principal.

Ces directives peuvent être placées à la racine du fichier de configuration httpd.conf, auquel cas ProxyFilter s'applique au serveur par défaut, ou dans un bloc <VirtualHost>, pour que ProxyFilter ne soit actif que sur une certaine adresse IP, un certain port ou un certain nom de serveur.

Avec cette syntaxe, seules les requêtes arrivant sur le port 80 et dont l'entête Host vaut www.example.com seront passées au reverse proxy. Les autres requêtes seront soit prises en charge par un autre <VirtualHost> défini, soit par le serveur par défaut.

Rappelons qu'il existe deux types d'hôtes virtuels avec Apache 1.3 : ceux basés sur l'adresse IP et le numéro de port, et ceux nommés. Les premiers servent à faire la distinction entre les différents sites au moyen de l'adresse IP et/ou du numéro de port uniquement. Les seconds permettent de distinguer les divers sites à partir de l'entête Host de la requête et nécessitent un navigateur compatible HTTP/1.1 et la présence d'au moins une directive NameVirtualHost pour indiquer au serveur sur quelle(s) adresse(s) et quel(s) port(s) il doit s'attendre à recevoir des requêtes destinées à un hôte virtuel nommé.

À noter que la directive PerlSetVar doit être placée à la racine du fichier de configuration et non dans un bloc <VirtualHost>, sans quoi ProxyFilter ne pourra pas la lire et retournera une erreur indiquant qu'il ne trouve pas son fichier de configuration. Cela est dû à une limitation de la directive PerlSetVar, un mécanisme simple offert par mod_perl pour passer des paramètres de configuration aux modules Perl pour Apache. Les directives PerlSetVar sont lues au démarrage uniquement et non lors de chaque requête et ne peuvent donc pas être locales à un hôte virtuel.

Cela signifie que, alors qu'il est possible de définir plusieurs hôtes virtuels et d'activer ProxyFilter pour certains d'entre-eux, ils ne peuvent pas avoir des fichiers de configuration de ProxyFilter différents. Cette lacune assez limitative sera vraisemblablement comblée dans une future version de ProxyFilter par la définition d'une véritable directive de configuration utilisant l'API Apache de définition des directives de configuration, au moyen duquel peut définir précisément le contexte admis pour une directive (racine, VirtualHost, Location, Directory, htaccess, etc...)

Les directives SetHandler et AddHandler peuvent également être placées dans un bloc <Location> ou <LocationMatch> pour restreindre l'utilisation de proxy à un certain contexte de l'URL de la requête. Dans ce cas, il est recommandé d'utiliser PerlModule en dehors du bloc <Location> ou <LocationMatch> pour forcer le préchargement du module au démarrage du serveur.

Dans l'exemple ci-après, nous utilisons ProxyFilter pour filtrer les requêtes à destination du répertoire /script/ de l'application (le seul contenant du contenu dynamique et donc potentiellement vulnérable) tandis que les requêtes vers les autres parties de l'application (admises statiques) sont servies directement localement au serveur Web hébergeant le proxy, sauf celles destinées au répertoire /images/ qui sont transmises via mod_proxy à un serveur dédié hébergeant les images, un contenu statique ne nécessitant pas de protection particulière.

Cette configuration permet de répartir la charge de l'application entre plusieurs serveurs et est nettement plus performante que de servir via ProxyFilter du contenu statique tel que des images ne présentant pas de risque de sécurité particulier.

Même lorsque l'accès au reverse proxy est restreint à un certain contexte au moyen d'un <Location> ou <LocationMatch>, le fichier proxyfilter_mappings doit contenir le préfixe complet. Par exemple pour l'exemple ci-dessus nous aurions :

On remarque que ProxyFilter et mod_proxy, même s'ils remplissent tous deux la fonction de reverse proxy, peuvent cohabiter car mod_proxy intervient en amont de ProxyFilter pour décider, sur la base de la directive ProxyPass, s'il doit servir la requête. Le content handler de ProxyFilter ne sert la requête que si mod_proxy, mod_rewrite ou mod_alias n'en ont pas décidé autrement. De même, l'utilisation de mod_access et/ou mod_auth pour restreindre l'accès au reverse proxy à certains utilisateurs ou certains hôtes est tout à fait envisageable.

6.4 Utilisation de HTTPS

Pour pouvoir utiliser SSL entre le client et le proxy, il faut avoir installé mod_ssl et OpenSSL comme expliqué au chapitre 4. Pour pouvoir utiliser SSL entre le proxy et le serveur Web cible, il faut que le module Crypt::SSLleay qui peut être trouvé sur le CPAN et OpenSSL ou SSLleay soient installés.

Le configuration de mod_ssl fait l'objet du chapitre 7 et est expliquée de façon plus détaillée encore dans la documentation officielle de mod_ssl. Nous donnons ici juste quelques exemples de cohabitation entre mod_ssl et ProxyFilter.

Il est possible, sans définir de bloc <VirtualHost>, d'activer mod_ssl et ProxyFilter au niveau du serveur par défaut. On utilisera cette configuration si le serveur ne doit être accessible que par HTTPS (port TCP 443 par défaut) ou que par HTTP (port TCP 80 par défaut).

Pour que le serveur puisse être accessible à la fois par HTTP et HTTPS, il est recommandé de créer deux blocs <VirtualHost>, un sur chaque port, et d'activer ProxyFilter séparément pour chacun de ces hôtes virtuels. On ne devrait pas utiliser des hôtes virtuels nommés avec SSL, c'est à dire ne pas définir pour NameVirtualHost une adresse IP et un port sur lesquels HTTPS a été activé au moyen de SSLEngine on. Pour que le navigateur du client accepte le certificat du serveur, il est important que le ServerName de l'hôte virtuel corresponde au CN (Common Name) du certificat X.509.

Dans cet exemple, nous mélangeons les hôtes virtuels nommés (basés sur l'entête Host) qui permettent d'héberger plusieurs sites derrière un même socket, et un hôte virtuel basé sur l'adresse IP qui est nécessaire pour pouvoir supporter HTTP et HTTPS sur une même adresse IP (mais un numéro de port différent). Si l'on tente de configurer HTTP et HTTPS sur la même adresse et le même numéro de port (le même socket), le serveur renverra une erreur, soit durant le démarrage, soit à la réception d'une requête HTTP sur un port sur lequel HTTPS est activé ou vice-versa.
 

Ce chapitre détaille la configuration de Apache pour mod_ssl, permettant de sécuriser par SSL la connexion entre le client et le proxy. On admet que OpenSSL et mod_ssl ont été compilés avec succès. Mod_ssl peut être soit compilé statiquement dans l'exécutable httpd, soit comme DSO. L'installation de MM n'est pas requise, mais elle est recommandée pour une utilisation en production car sans cette bibliothèque les performances de mod_ssl sont très dégradées.

7.1 Créer son propre CA

Dans le cadre d'une entreprise ou pour faire des tests, il est intéressant de générer son propre certificat racine permettant ensuite de signer d'autres certificats. Nous allons utiliser OpenSSL pour mettre en place notre propre certificat CA, puis signer avec le certificat du serveur.

Commençons par créer des répertoires pour accueillir les fichiers du CA et du certificat serveur :

Puis générons la clé privée du CA de 1024 bits et le CSR (Certificate Request) correspondant. La commande demande de renseigner le nom et l'adresse de l'entreprise, le CN, un mot de passe pour la clé privée et diverses autres informations dont certaines sont facultatives.

Le fichier ssl/ca/ca.key contient la clé privée sous une forme PEM cryptée avec une clé symétrique dérivée du mot de passe fournit. La sécurité de ce fichier est néanmoins critique et il ne doit pas être publiquement lisible. Le fichier ssl/ca/ca.crt contient la requête de certificat, qui doit être transmis à un CA, mais que nous allons auto-signer puisque nous créons notre propre CA.

Créons maintenant le certificat X.509 du CA à partir du CSR. Il aura une validité de 365 jours, ce qui signifie que les certificats signés par le CA expireront également après cette date.

Comme nous indiquons la même clé privée pour signer le certificat que celle qui a été utilisée pour générer le CSR, on voit bien qu'il s'agit d'un certificat auto-signé. Celui-ci est généré dans le fichier ssl/ca/ca.crt.
Lorsque l'autorité de certification signe un certificat, elle lui assigne un numéro de série qui est incrémenté à chaque nouveau certificat. Créons donc le fichier contenant ce numéro de série en lui donnant un valeur initiale de 1 :

7.2 Générer et signer le certificat du serveur Web

Créons maintenant une paire de clés pour le serveur Web et le CSR correspondant. Pour le CN (Common Name), il est important d'indiquer le nom DNS complet de serveur Web et rien d'autre, car sinon le certificat ne sera pas reconnu comme valide par le navigateur.

Il reste à signer ce certificat au moyen du certificat du CA. Nous lui donnons une validité de 100 jours :

Nous pouvons maintenant afficher le contenu du certificat généré :

Le certificat contient l'identité de l'autorité de certification (issuer), celle du détenteur du certificat (subject), sa période de validité (date de début et de fin), l'algorithme de signature utilisé (ici RSA avec MD5), la clé publique du détenteur et la signature du CA. Ce certificat est retourné au client par le CA pour être installé publiquement sur le serveur Web.

Il est possible de vérifier la validité du certificat relativement à celui du CA :

7.3 Installer le certificat sur le serveur Web

Les certificats sont en principe conservés à l'emplacement des fichiers de configuration de Apache. On distingue le certificat du serveur, qui est renvoyé au client lors de l'établissement d'une connexion SSL lui permettant ainsi de vérifier l'identité du serveur, des certificats CA, qui sont utilisés par le serveur pour vérifier le certificat du client lorsque le client s'authentifie au moyen d'un certificat.
Si mod_ssl a été installé avec Apache, le script d'installation a normalement déjà créé des répertoires pour accueillir les clés et certificats SSL. Si ce n'est pas le cas nous pouvons le faire nous-même.

Si l'on a suivi les explications ci-dessus pour générer la clé privée du serveur, celle-ci est cryptée sur le disque au moyen d'un algorithme symétrique comme DES, 3DES ou IDEA et d'une clé dérivée d'un mot de passe. Si un hacker parvient à pénétrer le serveur et que la clé privée est cryptée sur le disque, il devra encore utiliser la force brute pour pouvoir trouver la clé. Si la clé est mémorisée en clair sur le disque, il pourra facilement usurper l'identité du serveur.

L'inconvénient de crypter la clé privée est que le mot de passe sera demandé à chaque démarrage de Apache, et donc qu'il est difficilement possible de l'automatiser. Si l'on ne souhaite vraiment pas crypter la clé privée, il faut s'assurer que la machine est bien sécurisée, la première des précaution étant de limiter l'accès au fichier contenant le clé à l'utilisateur root :

Il est aisé de retirer la protection à une clé :

De même, on peut crypter une clé qui ne l'est pas :

Il est important de choisir un mot de passe long et difficile à deviner pour crypter la clé, car il constituera la seule protection de la clé si le serveur venait à être pénétré.

7.4 Configurer Apache pour SSL

Voici un extrait du httpd.conf permettant d'activer SSL pour tout le serveur :

Les directives LoadModule et AddModule permettent de charger et d'activer mod_ssl au démarrage du serveur. Si celui-ci a été compilé en interne à l'exécutable httpd, seul AddModule est nécessaire.

Les deux directives Listen indiquent à Apache d'écouter, en plus du port TCP 80 standard pour HTTP, d'écouter les requêtes entrantes sur le port 443 (HTTPS) lorsque mod_ssl est activé. On pourra bien sûr changer ces numéros de ports à loisir, de même que rajouter des directives Listen pour définir des hôtes virtuels accessibles uniquement sur certains ports et adresses.

SSLPassPhraseDialog défini le moyen par lequel le mot de passe de la clé privée est obtenu. Dans le mode par défaut builtin, le mot de passe sera demandé de façon interactive à la ligne de commande à chaque démarrage de Apache. Cette technique n'est donc pas adaptée à un lancement automatisé de Apache au démarrage du système. Il est possible de faire en sorte que le mot de passe soit obtenu par une ligne de commande ou un script, mais il faut évidemment éviter qu'il ne soit trop facilement accessible en le plaçant en clair dans un fichier de configuration.

SSLSessionCache et SSLSessionCacheTimeout permettent de définir le méthode utilisée par les différents processus enfants de Apache pour partager les données d'une session SSL. On utilise ici une base DBM pour laquelle il nous fallait installer GDBM.

SSLMutex sert à désigner un fichier utilisée pour gérer l'exclusion mutuelle entre les diverses instances de mod_ssl.

SSLRandomSeed permet de définir une source d'entropie externe, tel que le périphérique /dev/random pour initialiser le générateur pseudo-aléatoire utilisé pour générer les clés de session. On utilise ici le générateur interne de mod_ssl par défaut.

SSLLog et SSLLogLevel définissent l'emplacement et la verbosité de l'historique dédié à mod_ssl. On peut ainsi choisir de ne voir s'afficher que les messages d'alerte ou le détail de chaque transaction. Cet historique est indépendant de celui de Apache et ProxyFilter.

La directive SSLEngine permet d'activer SSL pour un hôte virtuel. Si elle est placée à la racine du serveur, SSL est activé pour le serveur par défaut et tous les hôtes virtuels dans lesquelles elle n'est pas redéfinie, ce qui est rarement le comportement désiré. On a dans cet exemple défini un bloc <VirtualHost> par défaut pour SSL qui reçoit toutes les requêtes arrivant sur le port 443.

SSLCipherSuite est une directive complexe définissant quels sont les algorithmes de cryptographie qui peuvent ou doivent être utilisés entre le client et le serveur. Ainsi, on peut obliger la client à utiliser une encryption forte (128 bits minimum) ou privilégier RSA à DSA par exemple. Nous ne détaillerons pas ici la syntaxe de cette directive.

SSLCertificateFile indique le chemin d'accès au fichier .crt contenant le certificat du serveur. Généralement on aura un certificat par hôte virtuel puisque, dans le cas de HTTPS, le Common Name du certificat doit correspondre au nom d'hôte du serveur. Le certificat doit être au format PEM (il est possible de convertir un certificat entre les formats DER et PEM à l'aide de la commande openssl).

SSLCertificateKeyFile indique le chemin d'accès au fichier .key contenant la clé privée du serveur au format encodée au format PEM. Cette directive n'est utile que si la clé est dans un fichier séparée du certificat lui-même. Cette directive peut être utilisée deux fois pour spécifier à la fois une clé DSA et une clé RSA.

Il existe bien d'autres directives possibles que celles utilisées dans cet exemple très minimaliste : on se reportera à la documentation de mod_ssl pour des informations détaillées.

7.5 Ajouter un certificat CA au navigateur Web

Si l'on utilise SSL dans le cadre de développements ou de tests, il est rare que l'on dispose d'un certificat signé par une autorité de certification telle que Verisign. La plupart du temps, on utilisera un certificat auto-signé ou signé par un CA que l'on aura soi-même défini.

Dans ce cas, le navigateur Web va afficher un message d'alerte de sécurité lors de la connexion en HTTPS tant que l'on aura pas ajouté le certificat du CA à la liste des certificats de confiance du navigateur.

Pour ajouter un certificat CA à MS Internet Explorer, sur Mac comme sur Windows, il suffit de cliquer sur un lien pointant sur le certificat (fichier .crt) au format PEM. Le navigateur prendra alors en charge l'installation du nouveau certificat au moyen d'une interface dédiée. Il faut toutefois configurer le serveur pour qu'il retourne les bons types MIME et rendre le certificat accessible en le plaçant dans le dossier htdocs.

Pour ajouter un certificat au navigateur Safari de Mac OS X, il n'existe pas d'interface graphique. Il faut le télécharger dans un fichier puis utiliser la commande certtool pour l'installer au niveau global ou local à l'utilisateur :

Le certificat est stocké dans le trousseau de clés du système et donc est valable pour tous les utilisateurs. Il est reconnu par des applications telles que Safari et Mail.app, mais pas par IE ou Entourage (utiliser la technique expliquée plus haut pour installer un certificat avec ces applications).

7.6 Forcer l'utilisation de HTTPS

Si mod_ssl est activé pour un hôte virtuel ou pour le serveur global, celui-ci est atteignable aussi bien en HTTP sur le port 80 (par défaut) qu'en HTTPS sur le port 554 (par défaut). Dans certains cas, on peut souhaiter pour des raisons de sécurité ne permettre l'accès à un hôte virtuel que par HTTPS, notamment dans le cas où des mots de passe ou cookies sont échangés. SSL peut être forcé au moyen de la directive SSLRequireSSL placée dans un bloc <Directory> ou un fichier .htaccess :

Voici un résumé des principales URLs auxquelles les sources des logiciels cités dans le texte peuvent être téléchargées et davantage d'informations concernant leur installation ou leur utilisation peuvent être trouvées :

• CPAN (Comprehensive Perl Archive Network)
• Serveur Web Apache
• mod_perl
• mod_ssl
• OpenSSL
• libwww-perl
• ProxyFilter