<-
Apache > Serveur HTTP > Documentation > Version 2.5 > Modules

Module Apache mod_ssl_ct

Langues Disponibles:  en  |  fr 

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 :

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

Directives

Traitement des bugs

Voir aussi

top

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

top

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 :

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.

top

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 :

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.

top

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.

top

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.

top

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 :

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.

top

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.

top

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.

top

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.

top

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

top

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

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.

top

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.

top

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

top

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.

Langues Disponibles:  en  |  fr 

top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.