Ce module implémente la transparence des certificats en conjonction
avec
logtout 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.
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,
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.
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
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é.
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
En outre, si la directive
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.
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 :
ctauditscts peut utiliser cette configuration pour
trouver l'URL des logs.Les éléments de configuration pouvant être définis par l'une ou l'autre méthode sont les suivants :
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
Le module
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.
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
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 verify_single_proof.py.
Voici quelques indication à l'état brut pour l'utilisation de
ctauditscts :
requirements.txt du projet
certificate-transparency, et exécuter les étapes suivantes
avec ce virtualenv activé.PYTHONPATH de façon à inclure le
répertoire python dans les chemins par défaut des
utilitaires du projet certificate-transparency.PATH de façon à inclure le chemin du
répertoire python/ct/client/tools.ctauditscts avec comme
arguments la valeur de la directive
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.
La directive
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.
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.
La directive
Veuillez vous référer à la documentation du programme
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é.
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 :
La directive
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.
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.
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
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 :
- 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.
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
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
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.