Guide pratique de mise en œuvre d'un serveur WebDAV sous Apache avec LDAP et SSL

Version française du Apache based WebDAV Server with LDAP and SSL

Denis Berhaut

Adaptation française

Vincent Loupien

Relecture de la version française

Jean-Philippe Guérard

Préparation de la publication de la v.f.

Version : 4.1.2.fr.1.0

20 décembre 2004

Historique des versions
Version 4.1.2.fr.1.02004-12-20DB, VL, JPG
Première traduction française
Version 4.1.22003-10-17SA
Ajout de la section d'optimisation SSL
Version 4.1.12003-09-29SA
Mise à jour de la section SSL suite à des commentaires de lecteurs
Version 4.1.02003-09-02SA
Mise à jour de la section SSL suite à des commentaires de lecteurs
Version 4.0.22003-08-01SA
Mises à jour mineures de la ligne de commande de configuration d'Apache /dev/random référencée dans la section SSL.
Version 4.0.12003-07-27SA
Ajout d'informations dans la section SSL
Version 4.02003-06-29SA
Mise à jour du guide pratique pour Apache 2.0. De plus, conversion du source en XML.

Résumé

Ce document constitue le guide pratique de mise en œuvre d'un serveur WebDAV Apache utilisant LDAP pour l'authentification et SSL pour le chiffrement.


Table des matières

Introduction
À propos de ce document
Contributions au document
Qu'est-ce qu'Apache ?
Qu'est-ce que WebDAV ?
Qu'est-ce que PHP ?
Qu'est-ce que mySQL ?
Que nous faut-il ?
Considérations
Pré-requis
Éléments essentiels
Apache 2.0.46
OpenSSL
La bibliothèque iPlanet LDAP
mod_auth_ldap
Le moteur de base de données mySQL
PHP
Installation
Pré-requis
mySQL
Apache 2.0
mod_auth_ldap
CERT DB for LDAPS://
PHP
Configurer et installer les services WebDAV
Modifications au fichier /usr/local/apache/conf/httpd.conf
Créer un répertoire pour DAVLockDB
Donner l'accès à DAV
Créer un répertoire nommé DAVtest
Redémarrer Apache
Test de conformité au protocole du serveur WebDAV
Administration du serveur WebDAV
Limiter les accès aux partages de DAV
Limiter l'accès en écriture à des partages DAV
Mettre en œuvre et utiliser SSL pour protéger le trafic HTTP
Introduction à SSL
Certificats de test
Certificats destinés à la production
Génération d'un CSR
Installation de la clé privée et du certificat du serveur
Annulation de la phrase de passe pour la clef privée RSA
Réglage des performances SSL
A. Outils d'évaluation de performances HTTP/HTTPS
B. Solutions matérielles basées sur le chiffrement SSL
C. Autorités de certification
Glossaire de termes PKI

L'objectif de ce document est de configurer un serveur d'applications Apache avec mySQL, PHP et WebDAV, qui utilise LDAP pour l'authentification. La documentation fournira aussi des détails sur le chiffrement des transactions LDAP.

[Note]N.B. :

Si vous rencontrez des problèmes en installant Apache ou un quelconque de ses modules n'hésitez pas à contacter l'auteur en anglais à

N'hésitez pas à faire parvenir tout commentaire relatif à la version française de ce document à en précisant le titre et la version du document.

Si vous désirez contribuer à la version originale de ce guide pratique, vous pouvez télécharger le code source XML de http://www.xml-dev.com/xml/Apache-WebDAV-LDAP-HOWTO.xml, et envoyer le fichier source modifié à AVEC VOTRE NOM DANS LA LISTE D'AUTEURS ET DANS L'HISTORIQUE DES VERSIONS :) Cela sera plus facile pour moi de contacter la personne en cas de mises à jour ou de corrections. Je vous remercie.

Il est nécessaire de télécharger et de compiler différent paquets. Ce document expliquera le processus de compilation, mais vous êtes sensés savoir installer à partir du code source.

Il vous faudra télécharger OpenSSL de http://www.openssl.org/source/. Téléchargez la dernière version. L'installation d'OpenSSL sera utilisée pour compiler mod_ssl avec Apache à l'aide des bibliothèques SSL, et pour gérer les certificats SSL sur le serveur Web. Téléchargez les sources d'OpenSSL compressées par gzip dans /tmp/downloads

Téléchargez le SDK de iPlanet LDAP de http://wwws.sun.com/software/download/products/3ec28dbd.html. Nous utiliserons le SDK d'iPlanet LDAP, parce qu'il comprend les bibliothèques pour ldaps:// (LDAP over SSL) :

Nous nous occuperons d'abord des quelques pré-requis, puis nous procéderons à l'installation principale.

L'installation de mySQL est très simple. Les binaires téléchargés doivent être placés dans le répertoire approprié.

Nous commençons par créer un utilisateur:groupe pour le démon mysql, et copions les fichiers dans les répertoires appropriés.

# groupadd mysql
# useradd -g mysql mysql
# cd /usr/local
# gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
# ln -s full-path-to-mysql-VERSION-OS mysql

Puis nous lançons le script install_db et changeons les permissions des fichiers

# cd mysql
# scripts/mysql_install_db
# chown -R mysql .

Et maintenant la partie la plus facile. Dans cette section, nous rendrons un répertoire situé à la racine d'Apache disponible à WebDAV.

Il est très important que le serveur WebDAV que nous venons juste d'installer soit totalement compatible avec le protocole WebDAV-2. S'il n'est pas totalement compatible, les applications WebDAV côté client pourront ne pas fonctionner correctement.

Pour tester la compatibilité nous utiliserons un outil nommé Litmus. Litmus est une suite de tests de compatibilité avec le protocole d'un serveur WebDAV, qui est destinée à tester si un serveur est compatible avec le protocole WebDAV selon les spécifications de la norme RFC2518.

Téléchargez les sources de Litmus du site http://www.webdav.org/neon/litmus/ et placez les dans le répertoire /tmp/downloads

Puis utilisez gzip et tar pour extraire les fichiers :

# cd /tmp/downloads
# gzip -d litmus-0.6.x.tar.gz
# tar -xvf litmus-0.6.x.tar
# cd litmus-0.6.x

Il est facile de compiler et d'installer Litmus :

# ./configure
# make
# make install

make install installera les fichiers binaires de Litmus dans les répertoires /usr/local/bin et les fichiers d'aide dans /usr/local/man

Pour tester la compatibilité du serveur WebDAV que vous venez d'installer, recourez à la commande suivante

# /usr/local/bin/litmus http://you.dav.server/DAVtest userid passwd

Dans cette section, nous aborderons les différentes tâches d'administration — par exemple l'utilisation de LDAP pour le contrôle d'accès, et comment on travaille dans Apache avec DAV

La plupart des changements de configuration pour DAV devront être faits dans le fichier httpd.conf. L'emplacement de ce fichier est /usr/local/apache/conf/httpd.conf.

httpd.conf est un fichier texte qui est utilisé pour la configuration d'Apache. Il peut être édité à l'aide de n'importe quel éditeur de texte — je préfère vi. Faites une copie de sauvegarde de ce fichier avant de le modifier.

Après avoir effectué des modifications au fichier httpd.conf le serveur Apache doit être redémarré avec la commande /usr/local/apache/bin/apachectl restart. Cependant avant de le redémarrer, vous testerez la validité du fichier httpd.conf en utilisant la commande /usr/local/apache/bin/apachectl configtest.

Dans la section précédente, quand nous avons créé le partage DAVtest, nous avons utilisé LDAP pour l'authentification. Cependant, n'importe qui pouvant s'authentifier en utilisant son compte_utilisateur/mot_de_passe pourra accéder à ce dossier.

En utilisant la directive require dans le fichier httpd.conf, vous pouvez limiter l'accès à certains individus ou groupes d'individus.

Si nous regardons la configuration de DAVtest de la précédente section :

<Directory /usr/local/apache/htdocs/DAVtest>

Dav On
#Options Indexes FollowSymLinks
AllowOverride None
order allow,deny
allow from all
AuthName "LDAP_userid_password_required"
AuthType Basic

<Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>

Require valid-user

</Limit>

LDAP_Server ldap.server.com
LDAP_Port 389
Base_DN "o=ROOT"
UID_Attr uid

</Directory>

nous voyons que la commande require a pour paramètre valid-user. Ce qui signifie que n'importe quel utilisateur authentifié peut accéder à ce dossier.

De nos jours, la sécurité des données stockées sur un serveur de fichiers est très importante. Des données compromises peuvent coûter des milliers de dollars à une entreprise. Dans la dernière section, nous avons compilé le module d'authentification LDAP dans Apache pour fournir un mécanisme d'authentification. Cependant, le trafic http est très peu sur, et toutes les données sont transférées en clair — ce qui signifie que l'authentification LDAP (utilisateur/mot_de_passe) sera transmise elle aussi en clair. Ceci pose un problème. N'importe qui peut intercepter cet utilisateur/mot_de_passe et accéder aux dossiers de DAV. Pour éviter ceci nous devrons chiffrer le trafic http, essentiellement par HTTP + SSL ou HTTPS. Tout ce qui est transféré en HTTPS est chiffré, ce qui fait que le couple utilisateur/mot_de_passe LDAP ne peut pas être aisément déchiffré. HTTPS tourne sur le port 443. Les binaires résultants étant compilés selon la dernière section, Apache pourra écouter à la fois sur les ports 80 (HTTP normal) et 443 (HTTPS). Si vous désirez utiliser ce serveur uniquement pour DAV, alors je vous suggère fortement de fermer le port 80. Dans cette section du guide pratique, je fournirai des informations sur SSL et comment l'administrer dans un serveur http Apache.

SSL (Secure Socket Layer) est une couche protocolaire qui se situe entre la couche Réseau et la couche Application. Comme son nom le suggère, SSL fournit un mécanisme de déchiffrement pour toutes sortes de trafic : LDAP, POP, IMAP et plus important, HTTP.

Ce qui suit est une structure ultra simplifiée des couches impliquées par SSL.

+-------------------------------------------+
|   LDAP   |   HTTP   |    POP   |   IMAP   |
+-------------------------------------------+
|                    SSL                    | 
+-------------------------------------------+
|               Couche réseau               |
+-------------------------------------------+

SSL utilise trois sortes de techniques de cryptographie : les systèmes de clés publiques-privées, de clés symétriques et de signatures numériques.

Chiffrement par clés publiques-privées — Initialisation d'une connexion SSL : dans cet algorithme, le chiffrement et le déchiffrement sont effectués en utilisant une paire de clés publiques et privées. Le serveur Web détient la clé privée, et envoie la clé publique au client dans le certificat.

  1. Le client demande un contenu au serveur Web en utilisant HTTPS.

  2. Le serveur Web répond en envoyant un certificat numérique qui comprend la clé publique du serveur.

  3. Le client vérifie si le certificat est expiré.

  4. Puis le client vérifie si l'autorité de certification qui a signé le certificat est une autorité de confiance figurant dans la liste du navigateur. Ceci explique pourquoi il est nécessaire d'obtenir un certificat d'une autorité de certification de confiance.

  5. Puis, le client vérifie si le nom de domaine pleinement qualifié (FQDN) du serveur Web coïncide avec le Nom Commun (Common Name CN) du certificat.

  6. Si tout est correct, la connexion SSL est initialisée.

[Note]N.B. :

On ne peut déchiffrer ce qui a été chiffré avec une clé privée qu'avec sa clé publique. De la même façon, on ne peut déchiffrer ce qui a été chiffré avec une clé publique qu'avec sa clé privée. C'est une erreur répandue de penser qu'une clé publique est utilisée pour le chiffrement et que la clé privée est utilisée pour le déchiffrement. Ce n'est pas le cas. On peut utiliser les deux clés pour chiffrer ou déchiffrer. Cependant, si on utilise une clé pour chiffrer, alors l'autre clé devra servir à déchiffrer. Par exemple On ne peut chiffrer un message puis le déchiffrer en utilisant uniquement une clé publique.

L'utilisation d'une clé privée pour chiffrer et d'une clé publique pour déchiffrer garantit l'identité de l'émetteur (qui est le propriétaire de la clé publique) à ses destinataires. L'utilisation d'une clé publique pour chiffrer et d'une clé privée pour déchiffrer garantit que seul le destinataire (qui est le propriétaire de la clé publique) accédera aux données. (c'est-à-dire que seul le détenteur de la clé privée pourra déchiffrer le message).

Chiffrement symétrique — Transmission effective des données : une fois la connexion SSL établie, on utilise le chiffrement symétrique, qui est moins consommateur en cycles de processeur. Avec le chiffrement symétrique, on peut chiffrer et déchiffrer les données en utilisant la même clé. La clé de chiffrement symétrique est échangée durant le processus d'initialisation, en utilisant la clé de chiffrement publique.

Sommation de messages Le serveur utilise des algorithmes de sommation de messages comme HMAC, SHA-1, MD5 pour vérifier l'intégrité des données transférées.

Processus de chiffrement


           Clef privée              Clef publique
          de l'émetteur            du destinataire
          ,-.                     ,-.
         (   )..........         (   )..........
          `-' ''''|'|'||          `-' ''''''''||
                  | |                    |
                  | |                    |
   .----------.   | |    .----------.    |     .----------.
   |  Texte   |   V |    |   Texte  |    V     |   Texte  |
   |   en     |--------->|  chiffré |--------->|  chiffré |
   |  clair   | Étape1   |     1    | Étape2   |     2    |\
   `----------'     |    `----------'          `----------' \    __
         |          |                                        \   [_'
         |          |                                  Étape5 \   |
         |Étape3    |                                       __  --|--
         |          |                                  _.--'      |
         V          |                            _..-''          / \
    .---------.     |    .---------.       _..-''            Destinataire
    |  SHA 1  |     V    |Signature| _..-''
    |SomMessag|--------->|numérique|'
    `---------' Étape4   `---------' 
              _  ___ ___
        _    (_)/  _)  _)                                      _
   ____| |__  _ | |_| |_ ____ _____ _____  _____  _____ ____ _| |_
  / ___)  _ \| ||  _)  _) ___) ___ |  _  \|  _  \| ___ |  _ (_   _)
 ( (___  | | | || | | || |   | ____| || | | || | | ____| | | || |_
  \____)_| |_|_||_| |_||_|   |_____)_||_|_|_||_|_|_____)_| |_| \__)

Processus de déchiffrement

           Clef privée          Clef publique
         du destinataire        de l'émetteur
         ,-.                     ,-.
        (   )..........         (   )..........
         `-' ''''''''||          `-' '''''''|||
                |                      |    |
                |                      |    |
  .----------.  |       .----------.   |    | .----------.
  |  Texte   |  V       |  Texte   |   V    | |  Texte   |       .---No1---.
  | chiffré  |--------->| chiffré  |--------->|   en     |------>|  SHA 1  |
  |    2     | Étape1   |    1     | Étape2 | |  clair   |Étape3 |SomMessag|
  `----------'          `----------'        | `----------'       `---------'
                                            |                        ||
                                            |                        ||Étape5
                                            |                        ||
                                            |                        ||
                               .---------.  |                    .---------.
                               | Digital |  V                    |  SHA 1  |
                               |Signature|---------------------->|SomMessag|
                               `---------' Étape4                `---No2---'
     _    _              _  ___ ___
    | |  //        _    (_)/  _)  _)                                      _
  __| |_____  ____| |__  _ | |_| |_ ____ _____ _____  _____  _____ ____ _| |_
 / _  | ___ |/ ___)  _ \| ||  _)  _) ___) ___ |  _  \|  _  \| ___ |  _ (_   _)
( (_| | ____( (___  | | | || | | || |   | ____| || | | || | | ____| | | || |_
 \____|_____)\____)_| |_|_||_| |_||_|   |_____)_||_|_|_||_|_|_____)_| |_| \__)

Pour être signée, une CSR (Certificate Signature Request: Demande de Signature de Certificat) doit être envoyée à une AC de confiance. Cette section montre comment on crée une CSR, et comment on l'envoie à l'AC de son choix.

# openssl req

Pour créer une CSR, on peut recourir à cette commande comme suit :

# cd /usr/local/apache/conf/
# /usr/local/ssl/bin/openssl req -new -nodes -keyout private.key -out public.csr
Generating a 1024 bit RSA private key
............++++++
....++++++
writing new private key to 'private.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:San Jose
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Seagate 
Organizational Unit Name (eg, section) []:Global Client Server
Common Name (eg, YOUR name) []:xml.seagate.com
Email Address []:saqib@seagate.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:badpassword
An optional company name []:
[Note]« PRNG not seeded »

Si le fichier /dev/random n'existe pas sur votre système, le message d'erreur « PRNG not seeded » s'affichera. Dans ce cas, vous pouvez utiliser la commande suivante :

# /usr/local/ssl/bin/openssl req -rand mon_fichier.ext -new -nodes -keyout private.key -out public.csr

Remplacez le fichier mon_fichier.ext par le nom d'un fichier existant dans votre système. Vous pouvez spécifier n'importe quel fichier. Openssl utilisera ce fichier pour générer le noyau.

Sur Solaris 9 on trouve le fichier /dev/random . Cependant, il est possible que vous ayez à installer le correctif 112438 pour accéder à /dev/random

Arrivé là, vous devrez répondre à plusieurs questions concernant votre serveur pour générer la CSR.

N.B. : Votre Common Name (CN) est le nom DNS pleinement qualifié (FQDN) de votre serveur web, c'est-à-dire dav.server.com . Si vous saisissez quelque chose d'autre, ça ne marchera PAS. Mettez de côté le mot de passe pour un usage ultérieur.

Une fois le processus achevé, un fichier private.key et un fichier public.csr seront présents dans votre arborescence. Il vous faudra envoyer le fichier public.csr à l'autorité de certification. À ce stade, le fichier public.key n'est pas chiffré. pour le chiffrer, saisissez :

# mv private.key private.key.unecrpyted
# /usr/local/ssl/bin/openssl rsa -in private.key.unecrpyted -des3 -out private.key

une fois que l'autorité de certification aura traitée votre demande, elle vous renverra un certificat codé (certificat numérique). Le certificat numérique est au format défini par la norme X.509 v3. Les lignes qui suivent montre la structure d'un certificat numérique conforme à X509 v3 (version française entre parenthèses)

Vous devrez placer ce certificat dans le serveur, et indiquer à Apache où le trouver.

Dans cet exemple, la clé privée est située dans le répertoire /usr/local/apache2/conf/ssl.key/ et le certificat du serveur est placé dans le répertoire /usr/local/apache2/conf/ssl.crt/.

Copiez en le renommant le fichier reçu de l'autorité de certification en server.crt dans le répertoire /usr/local/apache2/conf/ssl.crt/.

et placez le fichier private.key généré à l'étape précédente dans le répertoire /usr/local/apache2/conf/ssl.key/

Puis modifiez le fichier /usr/local/apache2/conf/ssl.key/ pour qu'il pointe correctement vers la clé privée et le certificat du serveur :

#   Server Certificate:
#   Point SSLCertificateFile at a PEM encoded certificate.  If
#   the certificate is encrypted, then you will be prompted for a
#   pass phrase.  Note that a kill -HUP will prompt again.  Keep
#   in mind that if you have both an RSA and a DSA certificate you
#   can configure both in parallel (to also allow the use of DSA
#   ciphers, etc.)
SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt
#SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server-dsa.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/private.key
#SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server-dsa.key

La clé privée RSA conservée sur le serveur Web est d'habitude chiffrée, et il vous faut une phrase de passe pour parcourir le fichier. Voilà pourquoi quand Apache est lancé avec modssl, une phrase de passe vous est demandée :

# apachectl startssl
Apache/1.3.23 mod_ssl/2.8.6 (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 your.server.dom:443 (RSA)
Enter pass phrase:

Il est très important de chiffrer une clé privée RSA. Si un pirate s'empare de votre clé privée RSA non chiffrée, il pourra facilement emprunter l'identité de votre serveur Web. Si la clé est chiffrée, la seule chose que pourra faire le pirate est de tenter une attaque en force brute sur votre phrase de passe. L'utilisation d'une phrase de passe robuste (c'est-à-dire longue) est encouragée.

Cependant, le fait de chiffrer la clé peut parfois être gênant, dans la mesure où vous devrez saisir la phrase de passe à chaque démarrage du serveur Web. En particulier si vous utilisez les scripts rc pour lancer le serveur Web au démarrage, le processus de démarrage sera stoppé sur l'invite de saisie d'une phrase de passe.

Vous pouvez facilement vous débarrasser de l'invite de saisie de la phrase de passe en déchiffrant la clé. Cependant, assurez-vous que personne ne pourra s'emparer de cette clé. Je ne saurais trop vous recommander d'appliquer les lignes de conduite de durcissement et de sécurisation du serveur avant de déchiffrer la clé du serveur Web.

Pour déchiffrer la clé :

tout d'abord, faites une copie de la clé chiffrée

# cp server.key server.key.cryp

Puis recréez la clé avec chiffrement. L'invite vous demandera la phrase de passe de la clé chiffrée d'origine

# /usr/local/ssl/bin/openssl rsa -in server.key.cryp -out server.key
read RSA key Enter PEM pass phrase: writing RSA key

Une façon de sécuriser la clé privée non chiffrée est de limiter l'accès en lecture à l'utilisateur root :

# chmod 400 server.key

A. Outils d'évaluation de performances HTTP/HTTPS

Vous trouverez ci-dessous une liste de quelques outils d'évaluation de performances OpenSource pour serveurs Web

  1. SSLswamp — pour un audit de performances lors de la connexion à un serveur SSL autorisé

  2. HTTPERF — un outil pour mesurer les performances d'un serveur Web

  3. ab — outil d'évaluation d'un serveur HTTP Apache

B. Solutions matérielles basées sur le chiffrement SSL

Des solutions de chiffrement SSL matérielles sont présentées ci-dessous :

  1. CHIL (Cryptographic Hardware Interface Library) fabriqué par nCipher

  2. ab — outil d'évaluation d'un serveur HTTP Apache

C. Autorités de certification

La liste qui suit présente des autorités de certification acceptées par les différents navigateurs :