La solution à ce problème est évidente et le lecteur la recherchera à titre d'exercice
-- Phrase standard des manuels
Résoudre des problèmes de sécurité particuliers pour un serveur web utilisant SSL n'est pas toujours évident à cause des interactions entre SSL, HTTP et la manière dont Apache traite les requêtes. Ce chapitre donne des instructions pour résoudre certaines situations typiques. Considérez-le comme une première étape sur le chemin de la solution définitive, mais efforcez-vous toujours de comprendre ce que vous faites pour résoudre le problème avant d'utiliser la solution. Rien n'est pire que d'utiliser une solution de sécurité sans connaître ses restrictions et la manière dont elle interagit avec les autres systèmes.
Les directives suivantes créent un serveur SSL qui ne communique que selon le protocole SSLv2 et ses modes de chiffrement.
Les directives suivantes ne permettent que les chiffrements de plus haut niveau :
Cette fonctionnalité se nomme Cryptographie Transférée par Serveur (Server Gated Cryptography - SGC) et nécessite un certificat de serveur à identifiant global, signé par un certificat de CA spécial de chez Verisign. Ceci permet d'activer le chiffrement fort dans les versions des navigateurs importés des US, qui n'en avaient habituellement pas la possibilité (à cause des restrictions à l'exportation imposées par les US).
Quand un navigateur se connecte avec un mode de chiffrement importé des US, le serveur présente son certificat à identifiant global. le navigateur le vérifie, et peut ensuite faire évoluer sa suite de chiffrement avant que la communication HTTP ne se mette en place. Le problème consiste à permettre au navigateur de se mettre à jour de cette façon, mais de nécessiter encore un chiffrement fort. En d'autres termes, nous voulons que les navigateurs démarrent une connexion soit avec chiffrement fort, soit avec une version export du chiffrement mais que dans ce dernier cas, le navigateur fasse évoluer sa suite de chiffrement vers un chiffrement fort avant de démarrer la communication HTTP.
Il est possible de parvenir à ceci de cette façon:
Dans ce cas bien évidemment, une directive Location qui permettent
d'adapter la configuration générale à un répertoire spécifique ;
Lorsque vous connaissez tous vos clients (comme c'est en général le cas
au sein d'un intranet d'entreprise), vous pouvez imposer une
authentification basée uniquement sur les certificats. Tout ce dont vous
avez besoin pour y parvenir est de créer des certificats clients signés par
le certificat de votre propre autorité de certification
(ca.crt), et d'authentifier les clients à l'aide de ces
certificats.
Pour forcer les clients à s'authentifier à l'aide de certificats pour une
URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration
de
La clé du problème consiste à vérifier si une partie du certificat
client correspond à ce que vous attendez. Cela signifie en général
consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il
contient une chaîne connue. Il existe deux méthodes pour y parvenir ;
on utilise soit le module
La méthode du module
SSLVerifyClient none <Directory /usr/local/apache2/htdocs/secure/area> SSLVerifyClient require SSLVerifyDepth 5 SSLCACertificateFile conf/ssl.crt/ca.crt SSLCACertificatePath conf/ssl.crt SSLOptions +FakeBasicAuth SSLRequireSSL AuthName "Snake Oil Authentication" AuthType Basic AuthBasicProvider file AuthUserFile /usr/local/apache2/conf/httpd.passwd Require valid-user </Directory>
Le mot de passe utilisé dans cet exemple correspond à la chaîne de
caractères "password" chiffrée en DES. Voir la documentation de la
directive
/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
Lorsque vos clients font tous partie d'une même hiérarchie, ce qui
apparaît dans le DN, vous pouvez les authentifier plus facilement en
utilisant la directive
SSLVerifyClient none
<Directory /usr/local/apache2/htdocs/secure/area>
SSLVerifyClient require
SSLVerifyDepth 5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions +FakeBasicAuth
SSLRequireSSL
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
</Directory>
On suppose dans ces exemples que les clients de l'intranet ont des
adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet
à laquelle vous voulez autoriser l'accès depuis l'Internet est
/usr/local/apache2/htdocs/subarea. Ces lignes de configuration
doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles
s'appliquent à la fois à HTTP et HTTPS.
SSLCACertificateFile conf/ssl.crt/company-ca.crt
<Directory /usr/local/apache2/htdocs>
# En dehors de subarea, seul l'accès depuis l'intranet est autorisé
Order deny,allow
Deny from all
Allow from 192.168.1.0/24
</Directory>
<Directory /usr/local/apache2/htdocs/subarea>
# Dans subarea, tout accès depuis l'intranet est autorisé
# mais depuis l'Internet, seul l'accès par HTTPS + chiffrement fort
+ Mot de passe
# ou HTTPS + chiffrement fort + certificat client n'est autorisé.
# Si HTTPS est utilisé, on s'assure que le niveau de chiffrement est fort.
# Autorise en plus les certificats clients comme une alternative à
# l'authentification basique.
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +FakeBasicAuth +StrictRequire
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
# ON oblige les clients venant d'Internet à utiliser HTTPS
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
RewriteCond %{HTTPS} !=on
RewriteRule .* - [F]
# On permet l'accès soit sur les critères réseaux, soit par authentification Basique
Satisfy any
# Contrôle d'accès réseau
Order deny,allow
Deny from all
Allow 192.168.1.0/24
# Configuration de l'authentification HTTP Basique
AuthType basic
AuthName "Protected Intranet Area"
AuthBasicProvider file
AuthUserFile conf/protected.passwd
Require valid-user
</Directory>