Serveur HTTP Apache Version 2.5

Apache > Serveur HTTP > Documentation > Version 2.5 > Modules

# Module Apache mod_ssl_ct

Cette traduction peut être périmée. Vérifiez la version anglaise pour les changements récents.

Description: | Implémentation de la transparence des certificats (Certificat Transparency - RFC 6962)
Statut: | Extension
Identificateur de Module: | ssl_ct_module
Fichier Source: | mod_ssl_ct.c

### Sommaire

Ce module implémente la transparence des certificats en conjonction avec `mod_ssl` et les outils en ligne de commande du projet open source certificate-transparency. Le but de la transparence des certificats consiste à révéler l'utilisation de certificats de confiance délivrés par erreur ou dans un but malintentionné. Vous trouverez plus de détails à propos de la transparence des certificats ici : http://www.certificate-transparency.org/. Voici la signification des termes utilisés dans cette documentation :

Certificate log
  Un Certificate log, auquel on fera référence avec le simple terme log tout au long de ce document, est un service réseau auquel les certificats de serveurs sont soumis. Un agent utilisateur peut vérifier que le certificat d'un serveur auquel il accède a bien été soumis à un log auquel il fait confiance, et que le log lui-même n'a pas rencontré de problème avec ce certificat.
Horodatage signé du certificat (Signed Certificate Timestamp - SCT)
  Il s'agit d'une information en provenance d'un log indiquant qu'il a validé un certificat. Cet horodatage est signé avec la clé publique du log. Un ou plusieurs SCTs sont passés au client durant la phase de négociation de la connexion, soit dans le ServerHello (extension TLS), soit dans l'extension du certificat, soit dans une réponse OCSP jointe.

Cette implémentation pour Apache httpd fournit les fonctionnalités suivantes pout les serveurs et mandataires TLS :

- Les SCTs peuvent être extraits automatiquement des logs, et en conjonction avec tout SCT défini statiquement, envoyés aux clients qui les supportent durant la phase ServerHello de la négociation de la connexion.
- Le serveur mandataire peut recevoir les SCTs en provenance du serveur original au cours de la phase ServerHello sous la forme d'une extension de certificat, et/ou au sein des réponses OCSP agrafées ; tout SCT reçu peut être validé partiellement en ligne, et éventuellement mis en file d'attente pour un examen plus approfondi hors ligne.
- Le serveur mandataire peut être configuré de façon à refuser la communication avec un serveur original qui ne fournit pas de SCT pouvant âtre validé en ligne.

La configuration des logs peut être définie statiquement au niveau de la configuration du serveur web, ou enregistrée dans une base de données SQLite3. Dans ce dernier cas, `mod_ssl_ct` rechargera à intervalles réguliers la base de données, de façon à ce que tout changement dans la configuration de la maintenance et de la propagation des logs pour un site spécifique ne nécessite pas de redémarrer httpd.

Ce module en est au stade expérimental pour les raisons suivantes :

- Tests et retours d'information insuffisants
- Repose sur une version non stable (version 1.0.2, Beta 3 ou supérieure) d'OpenSSL pour les opérations de base
- Implémentation de la fonctionnalité d'audit hors ligne incomplète

Les mécanismes de configuration, le format des données enregistrées pour l'audit hors ligne, ainsi que d'autres caractéristiques sont appelés à évoluer en fonction des tests et retours d'informations à venir.

### Sujets

- Vue d'ensemble du fonctionnement au niveau du serveur
- Vue d'ensemble du fonctionnement au niveau du serveur mandataire
- Configuration du log
- Stockage des SCTs sous une forme compréhensible pour mod_ssl_ct
- Journalisation des repères de temps des certificats (CT) dans le journal des accès
- Audit hors ligne pour mandataire

### Directives

### Traitement des bugs

- Journal des modifications de httpd
- Problèmes connus
- Signaler un bug

## Vue d'ensemble du fonctionnement au niveau du serveur ¶

Les serveurs doivent pouvoir envoyer les SCTs aux clients. Les SCTs seront envoyés sous la forme d'une extension de certificat ou au sein d'une réponse OCSP agrafée sans logique préprogrammée. Ce module gère l'envoi des SCTs configurés par l'administrateur ou en provenance des logs définis.

Le nombre de SCTs envoyés au cours de la phase ServerHello (c'est à dire les SCTs autres que ceux inclus dans une extension de certificat ou une réponse OCSP agrafée) peut être limité via la directive `CTServerHelloSCTLimit`.

Pour chaque certificat de serveur, un processus maintient une liste de SCTs à envoyer au cours de la phase ServerHello ; cette liste est créée à partir des SCTs configurés statiquement, mais aussi à partir de ceux reçus depuis les logs. Les logs marqués comme suspects ou arrivés à péremption seront ignorés. A intervalles réguliers, le processus va soumettre les certificats à un log selon les besoins (suite à un changement de configuration du log ou de sa durée de vie), et reconstruire la concaténation des SCTs.

La liste des SCTs pour un certificat de serveur sera envoyée au cours de la phase ClientHello, lorsque ce certificat de serveur particulier est utilisé, à tout client qui fait savoir qu'il supporte cette fonctionnalité.

## Vue d'ensemble du fonctionnement au niveau du serveur mandataire ¶

Le serveur mandataire indique qu'il supporte la Transparence des Certificats au cours de la phase ClientHello en incluant l'extension signed_certificate_timestamp. Il peut reconnaître les SCTs reçus au cours de la phase ServerHello dans une extension du certificat du serveur original, ou au sein d'une réponse OCSP agrafée.

Une vérification en ligne est effectuée pour tout SCT reçu :

- Le repère de temps de chaque SCT peut être vérifié pour voir s'il n'est pas encore valide en le comparant avec l'heure actuelle ou tout intervalle de temps valide défini pour le log.
- Dans le cas d'un SCT issu d'un log pour lequel une clé publique a été définie, la signature du serveur sera vérifiée.

Si la vérification échoue ou renvoie un résultat négatif pour au moins un SCT et si la directive `CTProxyAwareness` est définie à require, la tentative de connexion est abandonnée.

En outre, si la directive `CTAuditStorage` est définie, la chaîne de certification du serveur et les SCTs sont stockés pour une vérification hors ligne.

A titre d'optimisation, la vérification en ligne et le stockage des données en provenance du serveur ne sont effectués que la première fois où un processus enfant du serveur web reçoit ces données, ce qui permet d'économiser du temps processeur et de l'espace disque. Dans le cas d'une configuration typique de mandataire inverse, seule une légère augmentation de la charge processeur sera induite.

## Configuration du log ¶

Les serveurs et les mandataires utilisent des informations différentes en ce qui concerne les logs et leurs traitements. Cette configuration des logs peut être effectuée de deux manières :

- On peut créer une base de données pour configurer le log en utilisant la commande `ctlogconfig` et en définissant le chemin vers cette base de données via la directive `CTLogConfig`. `mod_ssl_ct` relit la base de données à intervalles réguliers ; cette méthode de configuration supporte donc les mises à jour dynamiques. En outre, la commande d'audit hors ligne `ctauditscts` peut utiliser cette configuration pour trouver l'URL des logs.
- On peut aussi configurer les logs statiquement via la directive `CTStaticLogConfig`. Toute modification de cette directive nécessitera alors un redémarrage du serveur pour être prise en compte, comme pour toutes les autres directives.

Les éléments de configuration pouvant être définis par l'une ou l'autre méthode sont les suivants :

Identifiant du log
  L'identifiant du log est le hash SHA-256 de sa clé publique, et est inclus dans tout SCT. Ceci permet d'identifier aisément un log particulier lorsqu'on définit des plages de repères de temps valides ou certaines autres informations.
Clé publique du log
  Un mandataire doit disposer de la clé publique du log afin de pouvoir vérifier la signature dans les SCTs en provenance de ce log.
  Un serveur doit posséder la clé publique du log afin de pouvoir lui soumettre des certificats.
Configuration générale confiance/méfiance
  Il s'agit d'un mécanisme permettant d'instaurer une méfiance ou de restaurer une confiance envers un log donné pour certaines raisons particulières (y compris la simple interruption des interactions avec le log dans les situations où il est hors ligne).
Repères de temps minima et/ou maxima valides
  Lorsqu'ils sont définis, le mandataire pourra vérifier que les repères de temps contenus dans les SCTs sont compris dans une plage valide
URL du log
  Pour qu'un serveur puisse soumettre des certificats de serveur à un log, il doit connaître l'URL de ce dernier (pour son API). Le serveur soumettra chaque certificat de serveur afin d'obtenir un SCT pour chaque log dont l'URL est définie, sauf pour les logs aussi marqués comme non dignes de confiance ou si l'heure actuelle ne se situe dans aucune des plages de temps valides définies.
  L'audit hors ligne des SCTs reçus par un mandataire nécessite aussi de connaître l'URL du log.

En général, seuls quelque uns de ces éléments de configuration sont définis pour un log donné. Pour plus de détails, veuillez vous référer à la documentation de la directive `CTStaticLogConfig` et de la commande `ctlogconfig`.

## Stockage des SCTs sous une forme compréhensible pour mod_ssl_ct ¶

Le module `mod_ssl_ct` permet de configurer les SCTs de manière statique via la directive `CTStaticSCTs`. Ils doivent alors être sous une forme binaire prête à être envoyée au client.

Vous trouverez dans le Dépôt ct-tools de Tom Ritter un exemple de code sous la forme d'un script Python (`write-sct.py`) permettant de générer un SCT sous un format correct avec des données en provenance d'un log.

## Journalisation des repères de temps des certificats (CT) dans le journal des accès ¶

Dans les deux modes mandataire et serveur, les variables `SSL_CT_PROXY_STATUS` et `SSL_CT_CLIENT_STATUS` sont définies et indiquent si le serveur supporte les CTs.

Dans le mode mandataire, la variable `SSL_CT_PROXY_SCT_SOURCES` est définie pour indiquer si des SCTs ont été reçus ainsi que leur source (phase ServerHello de la connexion, extension de certificat, etc...).

Les valeurs de ces variables peuvent être journalisées via la chaîne de format `%{varname}e` de `mod_log_config`.

## Audit hors ligne pour mandataire ¶

Le support de cette fonctionnalité en est au stade expérimental, et est implémenté par la commande `ctauditscts`, qui repose elle-même sur l'utilitaire `verify_single_proof.py` du projet open source certificate-transparency. La commande `ctauditscts` peut parcourir des données, et ainsi effectuer un audit hors ligne (activé via la directive `CTAuditStorage`) en invoquant l'utilitaire `verify_single_proof.py`.

Voici quelques indication à l'état brut pour l'utilisation de `ctauditscts` :

- Créez un virtualenv en utilisant le fichier `requirements.txt` du projet certificate-transparency, et exécuter les étapes suivantes avec ce virtualenv activé.
- Définissez `PYTHONPATH` de façon à inclure le répertoire `python` dans les chemins par défaut des utilitaires du projet certificate-transparency.
- Définissez `PATH` de façon à inclure le chemin du répertoire `python/ct/client/tools`.
- Exécutez la commande `ctauditscts` avec comme arguments la valeur de la directive `CTAuditStorage`, et éventuellement le chemin de la base de données de configuration des logs. Cette dernière sera utilisée pour extraire les URLs des logs en fonction de leurs identifiants.

Les données stockées à des fins d'audit peuvent aussi être utilisées par d'autres programmes ; veuillez vous référer au code source de `ctauditscts` pour plus de détails à propos du traitement des données.

## Directive CTAuditStorage ¶

Description: | Répertoire de stockage des données pour l'audit hors ligne
Syntaxe: | `CTAuditStorage directory`
Défaut: | `none`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl_ct

La directive `CTAuditStorage` permet de définir le chemin du répertoire où les données destinées à un audit hors ligne seront stockées. Ce répertoire doit exister au préalable. Si le chemin contenu dans l'argument directory n'est pas absolu, il sera considéré comme relatif au chemin défini par la directive `DefaultRuntimeDir`.

Si cette directive n'est pas définie, aucune donnée ne sera stockée en vue d'un audit hors ligne.

Le répertoire considéré contiendra des fichiers nommés `PID.tmp` pour les processus enfants actifs et `PID.out` pour les processus enfants terminés. Les données disponibles pour un audit hors ligne sont donc contenues dans les fichiers `.out`. La commande expérimentale `ctauditscts` (située dans l'arborescence des sources de httpd, mais non encore prise en compte par le processus d'installation), fait appel aux utilitaires du projet certificate-transparency pour effectuer l'audit.

## Directive CTLogClient ¶

Description: | Chemin de l'utilitaire client du log certificate-transparency
Syntaxe: | `CTLogClient executable`
Défaut: | `none`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl_ct

executable est le chemin complet de l'utilitaire client du log qui est normalement le fichier `cpp/client/ct` (ou `ct.exe`) de l'arborescence des sources du projet open source certificate-transparency.

Il est possible d'utiliser une implémentation alternative pour extraire les SCTs d'un certificat de serveur à partir du moment où l'interface de la ligne de commande est équivalente.

Si cette directive n'est pas définie, il n'est pas possible de soumettre les certificats aux logs pour en extraire les SCTs ; seuls les SCTs gérés par l'administrateur ou situés dans une extension de certificat seront alors fournis aux clients.

## Directive CTLogConfigDB ¶

Description: | Base de données pour la configuration des logs avec mises à jour dynamiques
Syntaxe: | `CTLogConfigDB filename`
Défaut: | `none`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl_ct

La directive `CTLogConfigDB` permet de définir le nom de la base de données contenant la configuration des logs connus. Si le chemin contenu dans filename n'est pas absolu, il est considéré comme relatif au chemin défini par la directive `ServerRoot`.

Veuillez vous référer à la documentation du programme `ctlogconfig` qui gère la base de données.

## Directive CTMaxSCTAge ¶

Description: | Age maximum d'un SCT obtenu depuis un log avant son raffraîchissement
Syntaxe: | `CTMaxSCTAge num-seconds`
Défaut: | `1 jour`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl_ct

Les certificats de serveur dont les SCTs sont supérieurs à cet âge maximum seront soumis à nouveau aux logs définis. En général, le log va renvoyer le même SCT que précédemment, mais ceux-ci font alors l'objet d'une opération de la part du log. Les SCTs seront raffraîchis autant que nécessaire au cours du fonctionnement normal du serveur, les nouveaux SCTs étant envoyés aux clients au fur et à mesure de leur disponibilité.

## Directive CTProxyAwareness ¶

Description: | Niveau de prise en compte et de mise en oeuvre des CTs pour un mandataire
Syntaxe: | `CTProxyAwareness oblivious|aware|require`
Défaut: | `aware`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl_ct

Cette directive permet de contrôler la prise en compte et les recherches de SCTs valides pour un mandataire. Les options disponibles sont les suivantes :

oblivious
  Le mandataire de demandera jamais de SCTs, et par conséquent n'en examinera pas. Le processus de transparance des certificats est alors entièrement désactivé pour ce mandataire.
aware
  Le mandataire prendra en charge l'ensemble du processus de transparence des certificats, à savoir la recherche de SCTs et leur examen. Le mandataire n'interrompra cependant pas la connexion si le serveur original ne fournit pas de SCTs valides.
require
  Le mandataire interrompra la connexion avec le serveur original si ce dernir ne fournit pas au moins un SCT qui passe avec succès le test de validation en ligne.

## Directive CTSCTStorage ¶

Description: | Répertoire où les SCTs sont stockés
Syntaxe: | `CTSCTStorage directory`
Défaut: | `none`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl_ct

La directive `CTSCTStorage` permet de définir le nom du répertoire où les SCTs et listes de SCTs seront stockés. Si le chemin contenu dans directory n'est pas absolu, il sera considéré comme relatif au chemin défini par la directive `DefaultRuntimeDir`.

Chaque certificat voit ses informations stockées dans un sous-répertoire qui lui est propre ; le nom de ce sous-répertoire correspond au hash SHA-256 du certificat considéré.

Les sous-répertoires propres à chaque certificat contiennent des SCTs en provenance des logs définis, des listes de SCTs préparées à partir des SCTs configurés statiquement et des SCTs extraits, ainsi que diverses informations utilisées pour gérer les SCTs.

## Directive CTServerHelloSCTLimit ¶

Description: | Nombre maximum de SCTs pouvant être renvoyés au cours de la phase ServerHello
Syntaxe: | `CTServerHelloSCTLimit limit`
Défaut: | `100`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl_ct

Cette directive permet de définir le nombre maximum de SCTs pouvant être renvoyés par un serveur TLS au cours de la phase ServerHello dans le cas où le nombre de logs définis et de SCTs définis statiquement est assez important.

En général, seuls quelques SCTs sont disponibles, cette directive n'est donc nécessaire que dans certaines circonstances particulières.

Cette directive ne tient pas compte des SCTs contenus dans les extensions de certificats ou les réponses OCSP agrafées.

## Directive CTStaticLogConfig ¶

Description: | Configuration statique d'un log
Syntaxe: | `CTStaticLogConfig log-id|- public-key-file|- 1|0|- min-timestamp|- max-timestamp|- log-URL|-`
Défaut: | `none`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl_ct

Cette directive permet de configurer un log particulier. Elle est particulièrement appropriée dans les cas où cette configuration est rarement modifiée. Si votre cas nécessite plutôt une configuration dynamique, veuillez vous référer à la documentation de la directive `CTLogConfigDB`.

Chacun des six champs doit être renseigné, mais en général, la configuration d'un log nécessite peu d'information ; utilisez - lorsque vous ne disposez d'aucune information à spécifier pour un champ particulier. Par exemple, dans le cas d'une configuration de serveur simple (non mandataire), l'administrateur n'a besoin de spécifier que l'URL du log auquel soumettre des certificats de serveur afin d'en extraire les SCTs.

Les champs se définissent comme suit :

log-id
  Il s'agit de l'identifiant du log qui correspond au hash SHA-256 de la clé publique du log, codé en hexadécimal. Cette chaîne a une taille de 64 caractères.
  Ce champ peut être omis lorsque public-key-file est renseigné.
public-key-file
  Il s'agit du chemin d'un fichier contenant la clé publique du log codée au format PEM. Si ce chemin n'est pas absolu, il est considéré comme relatif au chemin défini par la directive `ServerRoot`.
trust/distrust
  Définissez ce champ à 1 pour marquer le log comme non digne de confiance, ou pour tout simplement interdire son utilisation pour le traitement des certificats. Définissez ce champ à - ou 0 (valeur par défaut) pour accorder votre confiance au log.
min-timestamp et max-timestamp
  Un repère de temps (timestamp) est un temps exprimé en millisecondes depuis le temps epoch, sans tenir compte des secondes sautées. C'est le format de temps utilisé dans les SCTs. Le repère de temps doit être fourni sous la forme d'un nombre décimal.
  Spécifiez `-` pour un des repères de temps s'il n'est pas connu. Par exemple, lorsque vous définissez le repère de temps minimum valide pour un log qui reste valide, spécifiez `-` pour max-timestamp.
  Les SCTs reçu par le mandataire depuis ce log seront invalides si le repère de temps est plus ancien que min-timestamp ou plus récent que max-timestamp.
log-URL
  Il s'agit de l'URL du log auquel soumettre les certificats de serveur et ainsi obtenir des SCTs à envoyer aux clients.

### Voir aussi

- Le paragraphe Configuration des logs contient des informations à caractère plus général à propos des champs qui peuvent être définis via cette directive.

## Directive CTStaticSCTs ¶

Description: | Configuration statique d'un ou plusieurs SCTs pour un certificat de serveur
Syntaxe: | `CTStaticSCTs certificate-pem-file sct-directory`
Défaut: | `none`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl_ct

Cette directive permet de définir statiquement un ou plusieurs SCTs correspondant à un certificat de serveur. Ce mécanisme peut être utilisé à la place ou en complément de l'obtention dynamique des SCTs en provenance des logs. Toute modification dans le jeu de SCTs d'un certificat de serveur particulier sera prise en compte de manière dynamique sans avoir à redémarrer le serveur.

certificate-pem-file fait référence au fichier contenant le certificat de serveur au format PEM. Si ce chemin n'est pas absolu, il sera considéré comme relatif au chemin défini par la directive `ServerRoot`.

sct-directory doit contenir le chemin vers un ou plusieurs fichiers possédant l'extension de nom de fichier `.sct`, représentant un ou plusieurs SCTs correspondant au certificat de serveur. Si ce chemin n'est pas absolu, il sera considéré comme relatif au chemin défini par la directive `ServerRoot`.

Si sct-directory est vide, aucun message d'erreur ne sera affiché.

Cette directive peut servir à identifier des répertoires de SCTs gérés par une autre infrastructure, sous réserve qu'ils soient enregistrés au format binaire avec l'extension de nom de fichier .sct.