Serveur Apache HTTP Version 2.3

Apache > Serveur HTTP > Documentation > Version 2.3 > SSL/TLS

# Chiffrement fort SSL/TLS : Mode d'emploi

Langues Disponibles: en | fr

Ce document doit vous permettre de démarrer et de faire fonctionner une configuration de base. Avant de vous lancer dans l'application de techniques avancées, il est fortement recommandé de lire le reste de la documentation SSL afin d'en comprendre le fonctionnement de manière plus approfondie.

## Exemple de configuration basique

Votre configuration SSL doit comporter au moins les directives suivantes :

`Listen 443 <VirtualHost *:443>
ServerName www.example.com
SSLEngine on
SSLCertificateFile /chemin/vers/www.example.com.cert
SSLCertificateKeyFile /chemin/vers/www.example.com.key
</VirtualHost>`

## Suites de chiffrement et mise en application de la sécurité de haut niveau

- Comment créer un serveur SSL qui n'accepte que le chiffrement fort ?
- 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 ?

### Comment créer un serveur SSL qui n'accepte que le chiffrement fort ?

Les directives suivantes ne permettent que les chiffrements de plus haut niveau :

### httpd.conf

`SSLProtocol all -SSLv2
SSLCipherSuite HIGH:!ADH:!EXP:!MD5:!NULL
`

Avec la configuration qui suit, vous pouvez activer deux méthodes de chiffrement relativement sécurisées, et rapides :

### httpd.conf

`SSLProtocol all -SSLv2
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!ADH:!EXP:!MD5:!NULL
SSLHonorCipherOrder on
`

Ceci correspond largement à la valeur par défaut de la directive `SSLCipherSuite`, et représente la pratique à conseiller.

## 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 ?

Dans ce cas bien évidemment, une directive `SSLCipherSuite` au niveau du serveur principal qui restreint le choix des suites de chiffrement aux versions les plus fortes ne conviendra pas. `mod_ssl` peut cependant être reconfiguré au sein de blocs `Location` qui permettent d'adapter la configuration générale à un répertoire spécifique ; `mod_ssl` peut alors forcer automatiquement une renégociation des paramètres SSL pour parvenir au but recherché. Cette configuration peut se présenter comme suit :

`# soyons très tolérant a priori
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
<Location /strong/area>
# sauf pour https://hostname/strong/area/ et ses sous-répertoires
# qui exigent des chiffrements forts
SSLCipherSuite HIGH:!ADH:!EXP:!MD5:!NULL
</Location>`

## Authentification du client et contrôle d'accès

- Comment forcer les clients à s'authentifier à l'aide de certificats ?
- 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 ?
- 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 ?
- 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 ?

### Comment forcer les clients à s'authentifier à l'aide de certificats ?

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.

### httpd.conf

`# exige un certificat client signé par le certificat de votre CA
# contenu dans ca.crt
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt`

### 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 ?

Pour forcer les clients à s'authentifier à l'aide de certificats pour une URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration de `mod_ssl` en fonction du répertoire :

### httpd.conf

`SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt
<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
`

### 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 ?

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 `mod_auth_basic`, soit la directive `SSLRequire`.

La méthode du module `mod_auth_basic` 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 tous les clients autorisés, comme suit :

### httpd.conf

    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 `SSLOptions` pour plus de détails.

### httpd.passwd

    /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 `SSLRequire`, comme suit :

### httpd.conf

    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>

### 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.

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.

### httpd.conf

    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>

## Journalisation

`mod_ssl` peut enregistrer des informations de débogage très verbeuses dans le journal des erreurs, lorsque sa directive `LogLevel` est définie à des niveaux de trace élevés. Par contre, sur un serveur très sollicité, le niveau `info` sera probablement déjà trop élevé. Souvenez-vous que vous pouvez configurer la directive `LogLevel` par module afin de pourvoir à vos besoins.

Langues Disponibles: en | fr