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
Suites de chiffrement et mise en application de la sécurité +de haut niveau
Agrafage OCSP
Authentification du client et contrôle d'accès
Journalisation

Voir aussi

Commentaires

Exemple de configuration basique

+ + +

Votre configuration SSL doit comporter au moins les directives +suivantes :

+ +

LoadModule ssl_module modules/mod_ssl.so
+
+Listen 443
+<VirtualHost *:443>
+    ServerName www.example.com
+    SSLEngine on
+    SSLCertificateFile "/path/to/www.example.com.cert"
+    SSLCertificateKeyFile "/path/to/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 :

SSLCipherSuite HIGH:!aNULL:!MD5

+ + +

Avec la configuration qui suit, vous indiquez une préférence pour + des algorityhmes de chiffrement spécifiques optimisés en matière de + rapidité (le choix final sera opéré par mod_ssl, dans la mesure ou le + client les supporte) :

+ +

SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
+SSLHonorCipherOrder on

+ + + +

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:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
+
+<Location "/strong/area">
+# sauf pour https://hostname/strong/area/ et ses sous-répertoires
+# qui exigent des chiffrements forts
+SSLCipherSuite HIGH:!aNULL:!MD5
+</Location>

+ + +

Agrafage OCSP

+ + +

Le protocole de contrôle du statut des certificats en ligne (Online +Certificate Status Protocol - OCSP) est un mécanisme permettant de +déterminer si un certificat a été révoqué ou non, et l'agrafage OCSP en +est une fonctionnalité particulière par laquelle le serveur, par exemple +httpd et mod_ssl, maintient une liste des réponses OCSP actuelles pour +ses certificats et l'envoie aux clients qui communiquent avec lui. La +plupart des certificats contiennent l'adresse d'un répondeur OCSP maintenu +par l'Autorité de Certification (CA) spécifiée, et mod_ssl peut requérir +ce répondeur pour obtenir une réponse signée qui peut être envoyée aux +clients qui communiquent avec le serveur.

+ +

L'agrafage OCSP est la méthode la plus performante pour obtenir le +statut d'un certificat car il est disponible au niveau du serveur, et le +client n'a donc pas besoin d'ouvrir une nouvelle connexion vers +l'autorité de certification. Autres avantages de l'absence de +communication entre le client et l'autorité de certification : +l'autorité de certification n'a pas accès à l'historique de navigation +du client, et l'obtention du statut du certificat est plus efficace car +elle n'est plus assujettie à une surcharge éventuelle des serveurs de +l'autorité de certification.

+ +

La charge du serveur est moindre car la réponse qu'il a obtenu du +répondeur OCSP peut être réutilisée par tous les clients qui utilisent +le même certificat dans la limite du temps de validité de la réponse.

+ +

Une fois le support général SSL correctement configuré, l'activation +de l'agrafage OCSP ne requiert que des modifications mineures +à la configuration de httpd et il suffit en général de l'ajout de ces +deux directives :

+ +

SSLUseStapling On
+SSLStaplingCache "shmcb:ssl_stapling(32768)"

+ + +

Ces directives sont placées de façon à ce qu'elles aient une portée +globale (et particulièrement en dehors de toute section VirtualHost), le +plus souvent où sont placées les autres directives de configuration +globales SSL, comme conf/extra/httpd-ssl.conf pour les +installations de httpd à partir des sources, ou +/etc/apache2/mods-enabled/ssl.conf pour Ubuntu ou Debian, +etc...

+ +

Le chemin spécifié par la directive +SSLStaplingCache (par exemple logs/) +doit être le même que celui spécifié par la directive +SSLSessionCache. Ce chemin est relatif au chemin +spécifié par la directive ServerRoot.

+ +

Cette directive SSLStaplingCache particulière +nécessite le chargement du module mod_socache_shmcb (à +cause du préfixe shmcb de son argument). Ce module est en +général déjà activé pour la directive +SSLSessionCache, ou pour des modules autres que +mod_ssl. Si vous activez un cache de session SSL +utilisant un mécanisme autre que mod_socache_shmcb, +utilisez aussi ce mécanisme alternatif pour la directive +SSLStaplingCache. Par exemple :

+ +

SSLSessionCache "dbm:ssl_scache"
+SSLStaplingCache "dbm:ssl_stapling"

+ + +

Vous pouvez utiliser la commande openssl pour vérifier que votre +serveur envoie bien une réponse OCSP :

+ +

$ openssl s_client -connect www.example.com:443 -status -servername www.example.com
+...
+OCSP response: 
+======================================
+OCSP Response Data:
+    OCSP Response Status: successful (0x0)
+    Response Type: Basic OCSP Response
+...
+    Cert Status: Good
+...

+ +

Les sections suivantes explicitent les situations courantes qui +requièrent des modifications supplémentaires de la configuration. Vous +pouvez aussi vous référer au manuel de référence de +mod_ssl.

+ +

Si l'on utilise plus que quelques certificats SSL pour le serveur

+ +

Les réponses OCSP sont stockées dans le cache d'agrafage SSL. Alors +que les réponses ont une taille de quelques centaines à quelques +milliers d'octets, mod_ssl supporte des réponses d'une taille jusqu'à +environ 10 ko. Dans notre cas, le nombre de certificats est conséquent +et la taille du cache (32768 octets dans l'exemple ci-dessus) doit être +augmentée. En cas d'erreur lors du stockage d'une réponse, le +message AH01929 sera enregistré dans le journal.

+ + +

Si le certificat ne spécifie pas de répondeur OCSP, ou si une +adresse différente doit être utilisée

+ +

Veuillez vous référer à la documentation de la directive SSLStaplingForceURL.

+ +

Vous pouvez vérifier si un certificat spécifie un répondeur OCSP en +utilisant la commande openssl comme suit :

+ +

$ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
+OCSP - URI:http://ocsp.example.com

+ +

Si un URI OCSP est fourni et si le serveur web peut communiquer +directement avec lui sans passer par un mandataire, aucune modification +supplémentaire de la configuration n'est requise. Notez que les règles +du pare-feu qui contrôlent les connexions sortantes en provenance du +serveur web devront peut-être subir quelques ajustements.

+ +

Si aucun URI OCSP n'est fourni, contactez votre autorité de +certification pour savoir s'il en existe une ; si c'est le +cas, utilisez la directive SSLStaplingForceURL pour la spécifier dans +la configuration du serveur virtuel qui utilise le certificat.

+ + +

Si plusieurs serveurs virtuels sont configurés pour utiliser SSL +et si l'agrafage OCSP doit être désactivé pour certains d'entre eux

+ + +

Ajoutez la directive SSLUseStapling Off à la +configuration des serveurs virtuels pour lesquels l'agrafage OCSP doit +être désactivé.

+ + +

Si le répondeur OCSP est lent ou instable

+ +

De nombreuses directives permettent de gérer les temps de réponse et +les erreurs. Référez-vous à la documentation de SSLStaplingFakeTryLater, SSLStaplingResponderTimeout, et SSLStaplingReturnResponderErrors.

+ + +

Si mod_ssl enregistre l'erreur AH02217 dans le journal

+ +

AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!

Afin de pouvoir supporter l'agrafage OCSP lorsqu'un certificat de +serveur particulier est utilisé, une chaîne de certification pour ce +certificat doit être spécifiée. Si cela n'a pas été fait lors de +l'activation de SSL, l'erreur AH02217 sera enregistrée lorsque +l'agrafage OCSP sera activé, et les clients qui utilisent le certificat +considéré ne recevront pas de réponse OCSP.

+ +

Veuillez vous référer à la documentation des directives SSLCertificateChainFile et SSLCertificateFile pour spécifier une +chaîne de certification.

+ + +

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.

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

+ +

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 :

+ +

SSLVerifyClient      none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+SSLVerifyClient      require
+    SSLVerifyDepth       5
+    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 :

+ + +

SSLVerifyClient      none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+  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>

+ + + +

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.

+ +

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é
+    Require              ip 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
+    Require              ip 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.