ssl_howto.xml.fr revision 7fb4c0766e858653c9776474005a6ae6d94828af
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!-- English revision : 659902 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="ssl_howto.xml.meta">
<summary>
<blockquote>
<p>La solution à ce problème est évidente et le lecteur la recherchera
à titre d'exercice</p>
<p class="cite">-- <cite>Phrase standard des manuels</cite></p>
</blockquote>
<p>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.</p>
</summary>
<section id="ciphersuites">
<title>Suites de chiffrement et mise en application de la sécurité
de haut niveau</title>
<ul>
<li><a href="#realssl">Comment créer un véritable serveur
SSLv2 seulement ?</a></li>
<li><a href="#onlystrong">Comment créer un serveur SSL
qui n'accepte que le chiffrement fort ?</a></li>
<li><a href="#upgradeenc">Comment créer un serveur SSL qui n'accepte que le
chiffrement fort, mais permet aux navigateurs importés des USA
d'évoluer vers un chiffrement plus fort ?</a></li>
<li><a href="#strongurl">Comment créer un serveur qui accepte tous les types de
chiffrement en général, mais exige un chiffrement fort pour pouvoir
accéder à une URL particulière ?</a></li>
</ul>
<section id="realssl">
<title>Comment créer un véritable serveur SSLv2 seulement ?</title>
<p>Les directives suivantes créent un serveur SSL qui ne communique que
selon le protocole SSLv2 et ses modes de chiffrement.</p>
SSLProtocol -all +SSLv2<br />
SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP<br />
</example>
</section>
<section id="onlystrong">
<title>Comment créer un serveur SSL qui n'accepte
que le chiffrement fort ?</title>
<p>Les directives suivantes ne permettent que les
chiffrements de plus haut niveau :</p>
SSLProtocol all<br />
SSLCipherSuite HIGH:MEDIUM<br />
</example>
</section>
<section id="upgradeenc">
<title>Comment créer un serveur SSL qui n'accepte que le
chiffrement fort, mais permet aux navigateurs importés des USA
d'évoluer vers un chiffrement plus fort ?</title>
<p>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).</p>
<p>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.</p>
<p>Il est possible de parvenir à ceci de cette façon:</p>
# autorise tout mode de chiffrement pour l'échange de données
initial,<br />
# les navigateurs non US peuvent ainsi se mettre à jour
via la fonctionnalité SGC<br />
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
<br />
# et enfin interdit l'accès à tous les navigateurs qui n'ont pas fait
évoluer leur suite de chiffrement<br />
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128<br />
</Directory>
</example>
</section>
<section id="strongurl">
<title>Comment créer un serveur qui accepte tous les types de
chiffrement en général, mais exige un chiffrement fort pour pouvoir
accéder à une URL particulière ?</title>
<p>Dans ce cas bien évidemment, une directive <directive
module="mod_ssl">SSLCipherSuite</directive> au niveau du serveur principal
qui restreint le choix des suites de chiffrement aux versions les plus
fortes ne conviendra pas. <module>mod_ssl</module> peut cependant être
reconfiguré au sein de blocs <code>Location</code> qui permettent
d'adapter la configuration générale à un répertoire spécifique ;
<module>mod_ssl</module> peut alors forcer automatiquement une
renégociation des paramètres SSL pour parvenir au but recherché.
Cette configuration peut se présenter comme suit :</p>
<example>
# soyons très tolérant a priori<br />
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
<br />
# sauf pour https://hostname/strong/area/ et ses sous-répertoires<br />
# qui exigent des chiffrements forts<br />
SSLCipherSuite HIGH:MEDIUM<br />
</Location>
</example>
</section>
</section>
<!-- /ciphersuites -->
<section id="accesscontrol">
<title>Authentification du client et contrôle d'accès</title>
<ul>
<li><a href="#allclients">Comment forcer les clients
à s'authentifier à l'aide de certificats ?</a></li>
<li><a href="#arbitraryclients">Comment forcer les clients
à s'authentifier à l'aide de certificats pour une URL particulière,
mais autoriser quand-même tout client anonyme
à accéder au reste du serveur ?</a></li>
<li><a href="#certauthenticate">Comment n'autoriser l'accès à une URL
particulière qu'aux clients qui possèdent des certificats, mais autoriser
l'accès au reste du serveur à tous les clients ?</a></li>
<li><a href="#intranet">Comment imposer HTTPS avec chiffrements forts,
et soit authentification de base, soit possession de certificats clients,
pour l'accès à une partie de l'Intranet, pour les clients en
provenance de l'Internet ?</a></li>
</ul>
<section id="allclients">
<title>Comment forcer les clients
à s'authentifier à l'aide de certificats ?
</title>
<p>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
certificats.</p>
# exige un certificat client signé par le certificat de votre CA<br />
# contenu dans ca.crt<br />
SSLVerifyClient require<br />
SSLVerifyDepth 1<br />
</example>
</section>
<section id="arbitraryclients">
<title>Comment forcer les clients
à s'authentifier à l'aide de certificats pour une URL particulière,
mais autoriser quand-même tout client anonyme
à accéder au reste du serveur ?</title>
<p>Pour forcer les clients à s'authentifier à l'aide de certificats pour une
URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration
de <module>mod_ssl</module> en fonction du répertoire :</p>
SSLVerifyClient none<br />
<br />
SSLVerifyClient require<br />
SSLVerifyDepth 1<br />
</Location><br />
</example>
</section>
<section id="certauthenticate">
<title>Comment n'autoriser l'accès à une URL
particulière qu'aux clients qui possèdent des certificats, mais autoriser
l'accès au reste du serveur à tous les clients ?</title>
<p>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 <module>mod_auth_basic</module>, soit la
directive <directive module="mod_ssl">SSLRequire</directive>.</p>
<p>La méthode du module <module>mod_auth_basic</module> est en général
incontournable lorsque les certificats ont un contenu arbitraire, ou
lorsque leur DN ne contient aucun champ connu
(comme l'organisation, etc...). Dans ce cas, vous devez construire une base
de données de mots de passe contenant <em>tous</em> les clients
autorisés, comme suit :</p>
SSLVerifyClient none
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions +FakeBasicAuth
SSLRequireSSL
AuthName "Snake Oil Authentication"
AuthType Basic
AuthBasicProvider file
Require valid-user
</Directory></pre>
</example>
<p>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 <directive module="mod_ssl">SSLOptions</directive> pour
plus de détails.</p>
</example>
<p>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 <directive module="mod_ssl"
>SSLRequire</directive>, comme suit :</p>
SSLVerifyClient none
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions +FakeBasicAuth
SSLRequireSSL
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
</Directory></pre>
</example>
</section>
<section id="intranet">
<title>Comment imposer HTTPS avec chiffrements forts,
et soit authentification de base, soit possession de certificats clients,
pour l'accès à une partie de l'Intranet, pour les clients en
provenance de l'Internet ? Je souhaite quand-même autoriser l'accès en HTTP
aux clients de l'intranet.</title>
<p>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
doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles
s'appliquent à la fois à HTTP et HTTPS.</p>
# 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>
# 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></pre>
</example>
</section>
</section>
<!-- /access control -->
</manualpage>