Précautions concernant la sécurité

Apache gère la sécurité en prenant les précautions suivantes :

• Lorsque le serveur démarre, il se connecte au réseau et crée de nombreuses copies de lui-même. Ces instances changent immédiatement de propriétaire pour s’exécuter sous le compte d’un utilisateur plus sûr, webuser du groupe webgroup dans nos exemples (voir le chapitre 2). Seul le processus initial continue de s’exécuter sous le compte du super-utilisateur, mais les requêtes réseau ne sont traitées que par les nouveaux processus : le processus initial ne s’occupe jamais du réseau, il se contente de superviser le fonctionnement des processus fils, en lance de nouveaux si besoin est et supprime ceux qui sont en trop si la charge du réseau décroît.
• Tout envoi aux shells est soigneusement testé pour repérer les caractères dangereux, mais cela ne résoud qu’à moitié le problème. Les auteurs de scripts CGI (voir le chapitre 13) doivent également faire attention de ne pas tomber dans les pièges.

Considérons, par exemple, ce simple script shell :

#!/bin/sh

cat /repertoire/$1

Imaginez que vous utilisez un script comme celui-ci pour présenter à l’utilisateur le contenu d’un fichier qu’il aurait choisi dans un menu, par exemple. Ce simple code pose pourtant plusieurs problèmes, le plus évident étant que si l’on arrive à faire en sorte que $1 contienne "etc/passwd", le serveur affichera le contenu de votre base de données des utilisateurs ! Supposons que vous ayez corrigé ce problème (l’expérience a prouvé qu’il n’était pas trivial à résoudre), un autre surgit : si $1 vaut "xx /etc/passwd", le script affichera /repertoire/xx et /etc/passwd. Comme vous pouvez le constater, il faut à la fois du soin et de l’imagination pour être totalement sécurisé et, maheureusement, il n’existe pas de formule toute faite -- bien que, en général, s’assurer que les entrées des scripts ne contiennent que les caractères voulus (nous conseillons de n’autoriser que les caractères alphanumériques) est un très bon point de départ.

Les utilisateurs internes posent des problèmes spécifiques. Le principal étant qu’ils veulent écrire des scripts CGI fonctionnant avec leurs pages. Dans une installation classique, le client, qui s’exécute sous le compte Apache ( webuser ou webgroup ) n’a pas suffisamment de droits pour lancer ces scripts de façon correcte : ce problème peut être résolu grâce à suEXEC (voir la section suEXEC et Unix dans le chapitre 16).

mod_ssl et Apache 1.3

L’autre solution SSL pour Apache 1.3 consiste à utiliser mod-ssl. Vous trouverez une excellente introduction à SSL sur la page http://www.modssl.org/docs/2.8/ssl_intro.html.

Vous devez récupérer une archive mod_ssl correspondant à votre version d’Apache 1.3 -- 1.3.27 ici : téléchargez-la à partir de http://www.modssl.org/. Vous aurez également besoin de openssl ( http://www.openssl.org/ ) et, si vous souhaitez utiliser un cache de session en RAM plutôt que sur disque, de la bibliothèque OSSP mm pour la mémoire partagée ( http://www.engelschall.com/sw/mm/ ). Nous avons copié chacune de ces archives dans des répertoires distincts sous /usr/src. Perl et gzip doivent aussi être présents, mais nous supposons que c’est le cas.

Décompressez l’archive mod_ssl :

gunzip mod_ssl-2.8.14-1.3.27.tar.gz

puis extrayez le contenu du fichier .tar :

tar xvf mod_ssl-2.8.14-1.3.27.tar

Faites la même chose pour les autres archives. Revenez dans le répertoire .mod_ssl/mod_ssl-<date>-<version>, et lisez le fichier INSTALL.

Commencez par configurer et compiler la bibliothèque OpenSSL. Allez dans le répertoire et tapez la commande suivante en respectant bien les majuscules :

sh config no-idea no-threads -fPIC

Cela doit créer un fichier makefile approprié à votre environnement Unix. Puis, faites :

make

make test

Cela peut prendre un certain temps... Pour être complets, nous avons ensuite installé mm :

cd ....mm/mm-1.3.0

./configure --prefix=/usr/src/mm/mm-1.3.0

make

make test

make install

Il est maintenant temps de revenir dans le répertoire mod_ssl. Le fichier INSTALL contient une foule de conseils et de mises en garde et présente un grand nombre de procédures différentes. Nous ne décrirons ici qu’une compilation absolument minimale -- elle n’utilise même pas mm. Utilisez les options de configuration correspondant à votre schéma de répertoire. Le symbole \ signale que la ligne suivante fait partie de la même ligne physique :

./configure --with-apache=/usr/src/apache/apache_1.3.27 \

--with-ssl=/usr/src/openssl/openssl-0.9.7a \

--prefix=/usr/local

Cela configure mod_ssl pour la version d’Apache indiquée et configure également Apache. Le script se termine par les instructions suivantes :

Now proceed with the following ncommands:

$ cd /usr/src/apache/apache_1.3.27

$ make

$ make certificate

Ce processus produit un certificat exemple. Pour cela, il vous sera demandé s’il doit contenir des ingrédients de chiffrement RSA ou DSA : répondez « R » (pour RSA, qui est le chiffrement par défaut) car aucun navigateur ne reconnaît DSA. On vous demandera ensuite de fournir d’autres informations. Comme il ne s’agit pas d’un vrai certificat, ce que vous saisirez n’a pas grande importance. Comme la plupart des questions ont des réponses par défaut, contentez-vous de faire Entrée :

1. Country Name (2 letter code) [XY]:

....

Vous devrez fournir une phrase d’authentification PEM -- qui peut être n’importe laquelle, pourvu que vous en vous en rappeliez. Cela a pour effet de produire les fichiers suivants :

SSL et Apache 2

SSL pour Apache 2 est plus simple car il n’y a qu’un seul choix. Téléchargez OpenSSL comme nous venons de le décrire puis revenez dans le répertoire des sources d’Apache et supprimez-les toutes. Notre /usr/src/apache, contenait l’archive httpd-2_0_28-beta.tar et le répertoire httpd-2_0_28. Nous avons supprimé ce répertoire puis l’avons recréé en faisant :

rm -r httpd-2_0_28

tar xvf httpd-2_0_28-beta.tar

cd httpd-2_0_28

Pour recompiler Apache avec SSL :

./configure --with-layout=GNU --enable-ssl

--with-ssl=<chemin vers les sources ssl> --prefix=/usr/local

make

make install

Cette commande produit un exécutable httpd (et non httpsd, comme avec Apache 1.3) dans le sous-répertoire bin du chemin précisé par l’option --prefix.

Vous trouverez des FAQ utiles et très bien faites aux URL httpd.apache.org/docs-2.0/ssl/ssl_faq.html et www.openssl.org.faq.html.

Création d’un certificat de test

Quelle que soit la version d’Apache que vous utilisez, vous avez maintenant besoin d’un certificat de test. Allez dans le répertoire .src et faites :

% make certificate

Il vous sera posé plusieurs questions sur votre identité et votre résidence :

ps > /tmp/ssl-rand; date >> /tmp/ssl-rand; RANDFILE=/tmp/ssl-rand

/usr/local/ssl/bin/openssl req -config SSLconf/conf/ssleay.cnf -new

-x509 -nodes -out SSLconf/conf/httpsd.pem -keyout

SSLconf/conf/httpsd.pem; ln -sf httpsd.pem

SSLconf/conf/'/usr/local/ssl/bin/openssl x509 -noout -hash < SSLconf/conf/httpsd.pem'.0; rm /tmp/ssl-rand

Using configuration from SSLconf/conf/ssleay.cnf

Generating a 1024 bit RSA private key

...........++++++ .

.........++++++

writing new private key to 'SSLconf/conf/httpsd.pem'

-----

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) [GB]: US

State or Province Name (full name) [Some-State]: Nevada

Locality Name (eg, city) []: Hopeful City

Organization Name (eg, company; recommended) []: Butterthlies Inc

Organizational Unit Name (eg, section) []: Sales

server name (eg. ssl.domain.tld; required!!!) []: sales.butterthlies.com

Email Address []: sales@butterthlies.com

Les saisies de l’utilisateur sont représentées en gras. La seule qui compte vraiment est « server name », qui doit être le nom pleinement qualifié de votre serveur. Cette information doit être correcte car les navigateurs soucieux de sécurité vérifieront que cette adresse est la même que celle à laquelle ils accèdent. Pour vérifier le résultat, allez dans le répertoire .SSLConf/conf et ouvrez le fichier httpsd.pem, qui doit contenir des lignes comme celles-ci (les vôtres seront différentes, bien sûr) :

-----BEGIN RSA PRIVATE KEY-----

MIICXAIBAAKBgQDBpDjpJQxvcPRdhNOflTOCyQp1Dhg0kBruGAHiwxYYHdlM/z6k pi8EJFvvkoYdesTVzM+6iABQbk9fzvnG5apxy8aB+byoKZ575ce2Rg43i3KNTXY+

RXUzy/5HIiL0JtX/oCESGKt5W/xd8G/xoKR5Qe0P+1hgjASF2p97NUhtOQIDAQAB AoGALIh4DiZXFcoEaP2DLdBCaHGT1hfHuU7q4pbi2CPFkQZMU0jgPz140psKCa7I 6T6yxfi0TVG5wMWdu4r+Jp/q8ppQ94MUB5oOKSb/Kv2vsZ+T0ZCBnpzt1eia9ypX ELTZhngFGkuq7mHNGlMyviIcq6Qct+gxd9omPsd53W0th4ECQQDmyHpqrrtaVlw8 aGXbTzlXp14Bq5RG9Ro1eibhXId3sHkIKFKDAUEjzkMGzUm7Y7DLbCOD/hdFV6V+ pjwCvNgDAkEA1szPPD4eB/tuqCTZ+2nxcR6YqpUkT9FPBAV9Gwe7Svbct0yu/nny bpv2fcurWJGI23UIpWScyBEBR/z34El3EwJBALdw8YVtIHT9IlHN9fCt93mKCrov JSyF1PBfCRqnTvK/bmUij/ub+qg4YqS8dvghlL0NVumrBdpTgbO69QaEDvsCQDVe

P6MNH/MFwnGeblZr9SQQ4QeI9LOsIoCySGod2qf+e8pDEDuD2vsmXvDUWKcxyZoV

Eufc/qMqrnHPZVrhhecCQCsP6nb5Aku2dbhX+TdYQZZDoRE2mkykjWdK+B22C2/4 C5VTb4CUF7d6ukDVMT2d0/SiAVHBEI2dR8Vw0G7hJPY=

-----END RSA PRIVATE KEY-----

-----BEGIN CERTIFICATE----- MIICvTCCAiYCAQAwDQYJKoZIhvcNAQEEBQAwgaYxCzAJBgNVBAYTAlVTMQ8wDQYD VQQIEwZOZXZhZGExFTATBgNVBAcTDEhvcGVmdWwgQ2l0eTEZMBcGA1UEChMQQnV0 dGVydGhsaWVzIEluYzEOMAwGA1UECxMFU2FsZXMxHTAbBgNVBAMTFHd3dy5idXR0 ZXJ0aGxpZXMuY29tMSUwIwYJKoZIhvcNAQkBFhZzYWxlc0BidXR0ZXJ0aGxpZXMu Y29tMB4XDTk4MDgyNjExNDUwNFoXDTk4MDkyNTExNDUwNFowgaYxCzAJBgNVBAYT AlVTMQ8wDQYDVQQIEwZOZXZhZGExFTATBgNVBAcTDEhvcGVmdWwgQ2l0eTEZMBcG A1UEChMQQnV0dGVydGhsaWVzIEluYzEOMAwGA1UECxMFU2FsZXMxHTAbBgNVBAMT FHd3dy5idXR0ZXJ0aGxpZXMuY29tMSUwIwYJKoZIhvcNAQkBFhZzYWxlc0BidXR0 ZXJ0aGxpZXMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBpDjpJQxv cPRdhNOflTOCyQp1Dhg0kBruGAHiwxYYHdlM/z6kpi8EJFvvkoYdesTVzM+6iABQ bk9fzvnG5apxy8aB+byoKZ575ce2Rg43i3KNTXY+RXUzy/5HIiL0JtX/oCESGKt5

W/xd8G/xoKR5Qe0P+1hgjASF2p97NUhtOQIDAQABMA0GCSqGSIb3DQEBBAUAA4GB

AIrQjOfQTeOHXBS+zcXy9OWpgcfyxI5GQBg6VWlRlhthEtYDSdyNq9hrAT/TGUwd
Jm/whjGLtD7wPx6c0mR/xsoWWoEVa2hIQJhDlwmnXk1F3M55ZA3Cfg0/qb8smeTx 7kM1LoxQjZL0bg61Av3WG/TtuGqYshpE09eu77ANLngp

-----END CERTIFICATE-----

Il s’agit d’un certificat plutôt atypique car il combine votre clé privée avec le certificat ; vous préférerez sûrement les séparer et n’autoriser la lecture de la clé privée qu’à root (voir plus loin). De plus, ce certificat est signé par nous-même, ce qui en fait un certificat émanant d’une autorité de certification d’origine : c’est uniquement pour simplifier les tests car, en pratique, les CA d’origine sont des organisations plus impressionnantes que nous. Cependant, ce certificat est fonctionnellement identique à un vrai : la différence importante est qu’il est moins cher et plus rapide à obtenir qu’un vrai.

Ce certificat n’a pas de phrase d’authentification, sinon httpsd la demanderait au démarrage. Nous pensons qu’une telle phrase est une mauvaise idée car elle empêche les redémarrages automatiques du serveur mais, si vous voulez créer un certificat qui en comporte une, modifiez le fichier Makefile (n’oubliez pas de le re-modifier si vous relancez Configuration ), ôtez l’indicateur -nodes de la section certificate: et recommencez l’opération décrite ci-dessus. Vous pouvez également suivre la procédure suivante, qui servira aussi lorsque l’on demandera un vrai certificat à l’une des CA que nous présenterons plus loin. Allez dans le répertoire .SSLConf/conf et tapez la commande suivante :

% openssl req -new -outform PEM> new.cert.csr

...

writing new private key to 'privkey.pem'

enter PEM pass phrase:

Saisissez votre phrase d’authentification puis répondez aux questions comme précédemment. Il vous sera également demandé de fournir un mot de passe défi -- nous avons utilisé « swan ». Cela produira un CSR ( Certificate Signing Request ) contenant votre phrase chiffrée à l’aide de votre clé privée, ainsi que les informations que vous avez fournies sur votre identité et votre lieu de résidence. Vous en aurez besoin lorsque vous demanderez un certificat de serveur. Envoyez-la à la CA de votre choix : si elle réussit à la déchiffrer avec votre clé publique, elle peut continuer à contrôler -- plus ou moins minutieusement -- que vous êtes bien celui que vous prétendez être.

Cependant, si vous décidez que vous ne voulez pas utiliser de phrase d’authentification car cela complique le démarrage d’Apache, vous pouvez la supprimer avec cette commande :

% openssl rsa -in privkey.pem -out privkey.pem

Vous devrez, bien sûr, entrer votre phrase d’authentification une dernière fois. Dans les deux cas, vous devez ensuite convertir cette requête en un certificat signé :

% openssl x509 -in new1.cert.csr -out new1.cert.cert -req -signkey privkey.pem

Comme nous l’avons déjà fait remarquer, il est prudent de n’autoriser la lecture de ce fichier qu’à root :

% chmod u=r,go= privkey.pem

Vous disposez maintenant d’une version sécurisée d’Apache ( httpsd ), d’un certificat ( new1.cert.cert ), d’un CSR ( new1.cert.csr ) et d’une clé signée ( privkey.pem ).

Obtenir un certificat de serveur

Si vous souhaiter disposer d’un certificat plus convaincant que celui que nous venons de créer, vous devez vous rendre sur l’une des URL suivantes :

Revendeurs de http://resellers.tucows.com/products/.

Thawte Consulting, http://www.thawte.com/certs/server/request.html.

CertiSign Certificadora Digital Ltda., http://www.certisign.com.br.

IKS GmbH, http://www.iks-jena.de/produkte/ca/.

BelSign NV/SA, http://www.belsign.be.

Verisign, Inc., http://www.verisign.com/guide/apache.

TC TrustCenter (Allemagne), http://www.trustcenter.de/html/Produkte/TC_Server /855.htm.

NLsign B.V., http://www.nlsign.nl.

Deutsches Forschungsnetz, http://www.pca.dfn.de/dfnpca/certify/ssl/.

128i Ltd. (Nouvelle Zélande), http://www.128i.com.

Entrust.net Ltd., http://www.entrust.net/products/index.htm.

Equifax Inc., http://www.equifaxsecure.com/ebusinessid/.

GlobalSign NV/SA, http://www.GlobalSign.net.

NetLock Kft. (Hongrie), http://www.netlock.net.

Certplus SA (France), http://www.certplus.com.

Toutes ces CA peuvent avoir des procédures légèrement différentes car il n’existe pas de format standard pour les CSR. Nous vous conseillons de vous renseigner sur les exigences d’une CA avant de vous lancer dans l’achat d’un certificat.

Le cache global de session

SSL utilise une clé de session pour sécuriser chaque connexion. Au départ de la connexion, les certificats sont contrôlés et une nouvelle clé de session est négociée entre le client et le serveur (à cause des joies du chiffrement par clé publique, cette nouvelle clé n’est connue que du client et du serveur). Il s’agit d’un processus qui prend du temps : par conséquent, Apache-SSL et le client peuvent s’entendre pour améliorer cette situation en réutilisant des clés de session. Malheureusement, comme Apache utilise un modèle d’exécution multi-processus, il n’est pas garanti que la prochaine connexion du client utilisera la même instance du serveur ; en fait, c’est même peu probable. Par conséquent, il est nécessaire de stocker les informations de session dans un cache accessible à toutes les instances d’Apache-SSL : c’est le rôle du programme gcache, qui est contrôlé par les directives SSLCacheServerPath, SSLCacheServerPort, SSLSessionCacheTimeout d’Apache 1.3 et SSLSessionCache d’Apache 2.