Je profite de ce thread pour présenter une manière de valider les certificats que j’aimerais voir dans les navigateurs (et que j’ai déjà (削除) implémenté (削除ここまで)bidouillé dans mon Uzbl).
L’idée maîtresse est de permettre de vérifier un certificat par toute une série de mécanismes distincts — au lieu de se reposer uniquement sur le système PKIX comme actuellement — et de prendre la décision finale d’accepter le certificat (et donc d’afficher la page) ou de le rejeter (et de présenter un message d’erreur) en fonction du résultat combiné de tous les mécanismes.
Le principe consiste en une sorte de « pipeline de validateurs », où chaque validateur teste à tour de rôle le certificat présenté par le serveur et renvoie un score négatif pour un certificat invalide, un score positif pour un certificat valide, ou un score nul si la validation est impossible (le validateur ne peut pas se prononcer sur ce certificat). À la sortie du pipeline, le certificat est accepté si le score final est positif, rejeté si le score est négatif. Si le score est nul, la décision revient à l’utilisateur, à qui un message présente les résultats de chaque validateur.
Les validateurs possibles incluent (liste non exhaustive, justement un des buts de cette approche est de pouvoir ajouter de nouveaux mécanismes de validation sans tout chambouler) :
un validateur PKIX, comme ce qui existe déjà dans tous les navigateurs (renvoie 1 si le certificat est correct et signé — directement ou non — par une autorité de certification qui a la confiance de l’utilisateur, -1 si le certificat n’est pas correct, ou 0 si l’autorité de certification n’est pas connue) ;
un validateur DANE (renvoie 1 si le certificat correspond à au moins un enregistrement TLSA, 0 s’il n’y a pas d’enregistrements TLSA, -1 s’il y a des enregistrements TLSA et que le certificat du serveur ne correspond à aucun d’entre eux) ;
un validateur Monkeysphere (renvoie 1 si le certificat est présent dans la toile OpenPGP et qu’il existe un chemin de confiance jusqu’à lui, 0 dans tous les autres cas) ;
un validateur mémorisant les certificats associés à chaque hôte (renvoie 1 si le certificat actuellement présenté par le serveur est le même que celui mémorisé lors d’une précédente visite, -1 s’il est différent, 0 lors de la première visite) ;
un validateur de « bonnes pratiques », qui attribue un score négatif à tout certificat ne respectant pas certains critères de qualité (par exemple avoir une clef suffisamment grande, ou ne pas utiliser SHA-1).
L’utilisateur aurait la possibilité d’activer ou désactiver les validateurs de son choix, et aussi éventuellement de changer le « poids » accordé à chaque validateur dans le score final.
En gros, on ne jette pas PKIX à la poubelle (même si franchement, j’aimerais beaucoup...), mais on considère ça comme un moyen de valider un certificat parmi d’autres. On pourrait aussi ajouter des validateurs pour Convergence, Certificate Transparency, etc.
P.S. : Je sais qu’il existe pour Firefox des plugins pour chacun des mécanismes de validation décrits ci-dessus (DNSSEC/TLSA Validator, xul-ext-monkeysphere, CertWatch, etc.). Mais il manque, à ma connaissance, l’intégration de tous ces plugins dans un « pipeline » unique, donnant un seul résultat en sortie.
[^] # Re: PKIX + DANE + Monkeysphere
Posté par gouttegd . En réponse au sondage Comme autorité de certification pour linuxfr.org je préfèrerais.... Évalué à 8.
Je profite de ce thread pour présenter une manière de valider les certificats que j’aimerais voir dans les navigateurs (et que j’ai déjà
(削除) implémenté (削除ここまで)bidouillé dans mon Uzbl).L’idée maîtresse est de permettre de vérifier un certificat par toute une série de mécanismes distincts — au lieu de se reposer uniquement sur le système PKIX comme actuellement — et de prendre la décision finale d’accepter le certificat (et donc d’afficher la page) ou de le rejeter (et de présenter un message d’erreur) en fonction du résultat combiné de tous les mécanismes.
Le principe consiste en une sorte de « pipeline de validateurs », où chaque validateur teste à tour de rôle le certificat présenté par le serveur et renvoie un score négatif pour un certificat invalide, un score positif pour un certificat valide, ou un score nul si la validation est impossible (le validateur ne peut pas se prononcer sur ce certificat). À la sortie du pipeline, le certificat est accepté si le score final est positif, rejeté si le score est négatif. Si le score est nul, la décision revient à l’utilisateur, à qui un message présente les résultats de chaque validateur.
Les validateurs possibles incluent (liste non exhaustive, justement un des buts de cette approche est de pouvoir ajouter de nouveaux mécanismes de validation sans tout chambouler) :
un validateur PKIX, comme ce qui existe déjà dans tous les navigateurs (renvoie 1 si le certificat est correct et signé — directement ou non — par une autorité de certification qui a la confiance de l’utilisateur, -1 si le certificat n’est pas correct, ou 0 si l’autorité de certification n’est pas connue) ;
un validateur DANE (renvoie 1 si le certificat correspond à au moins un enregistrement TLSA, 0 s’il n’y a pas d’enregistrements TLSA, -1 s’il y a des enregistrements TLSA et que le certificat du serveur ne correspond à aucun d’entre eux) ;
un validateur Monkeysphere (renvoie 1 si le certificat est présent dans la toile OpenPGP et qu’il existe un chemin de confiance jusqu’à lui, 0 dans tous les autres cas) ;
un validateur mémorisant les certificats associés à chaque hôte (renvoie 1 si le certificat actuellement présenté par le serveur est le même que celui mémorisé lors d’une précédente visite, -1 s’il est différent, 0 lors de la première visite) ;
un validateur de « bonnes pratiques », qui attribue un score négatif à tout certificat ne respectant pas certains critères de qualité (par exemple avoir une clef suffisamment grande, ou ne pas utiliser SHA-1).
L’utilisateur aurait la possibilité d’activer ou désactiver les validateurs de son choix, et aussi éventuellement de changer le « poids » accordé à chaque validateur dans le score final.
En gros, on ne jette pas PKIX à la poubelle (même si franchement, j’aimerais beaucoup...), mais on considère ça comme un moyen de valider un certificat parmi d’autres. On pourrait aussi ajouter des validateurs pour Convergence, Certificate Transparency, etc.
P.S. : Je sais qu’il existe pour Firefox des plugins pour chacun des mécanismes de validation décrits ci-dessus (DNSSEC/TLSA Validator, xul-ext-monkeysphere, CertWatch, etc.). Mais il manque, à ma connaissance, l’intégration de tous ces plugins dans un « pipeline » unique, donnant un seul résultat en sortie.