Le TOFU, ça ne marche que dans certains contextes.
Rien ne dit que ça ne marcherait pas dans le contexte de HTTPS. D’ailleurs, c’est l’une des principales pistes pour pallier les déficiences de PKIX, c’est pour ça qu’on a inventé l’épinglage des clefs publiques dans les en-têtes HTTP (HPKP).
Un autre point, est que le certificat peut changer pour plein de raison, sans que l'utilisateur en soit averti, il n'a donc aucun moyen de savoir en cas de changement si c'est légitime ou pas.
Ce n’est pas parce que les navigateurs acceptent sans sourciller qu’un certificat puisse changer à tout moment (en absence d’extension chargée précisément de surveiller ça, comme CertPatrol ou assimilée) que c’est une bonne idée de changer de certificat à l’improviste.
Toutes les méthodes d’épinglage des clefs, que ce soit dans les en-têtes HTTP (HPKP), dans le DNS (DANE), ou même pré-chargées dans le navigateur, vont exiger des administrateurs de serveurs TLS un peu plus de rigueur et d’anticipation dans la gestion de leurs certificats, et c’est une bonne chose.
[^] # Re: Quel le problème en fait ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 2.
Rien ne dit que ça ne marcherait pas dans le contexte de HTTPS. D’ailleurs, c’est l’une des principales pistes pour pallier les déficiences de PKIX, c’est pour ça qu’on a inventé l’épinglage des clefs publiques dans les en-têtes HTTP (HPKP).
Ce n’est pas parce que les navigateurs acceptent sans sourciller qu’un certificat puisse changer à tout moment (en absence d’extension chargée précisément de surveiller ça, comme CertPatrol ou assimilée) que c’est une bonne idée de changer de certificat à l’improviste.
Toutes les méthodes d’épinglage des clefs, que ce soit dans les en-têtes HTTP (HPKP), dans le DNS (DANE), ou même pré-chargées dans le navigateur, vont exiger des administrateurs de serveurs TLS un peu plus de rigueur et d’anticipation dans la gestion de leurs certificats, et c’est une bonne chose.