L'interception SSL est-elle possible sans désactiver la clé publique d'épingler sur le côté du client?
Je confie actuellement un pare-feu PFSense dans mon laboratoire. Il prend en charge la création SSL qui fonctionne assez bien pour la plupart des sites.
Mais il existe certains sites qui utilisent des clés publiques HTTP pour prévenir les attaques de MITM et que ceci est une véritable douleur, car les systèmes situés derrière le pare-feu n'ont pas simplement été configurés et ont des clés publiques épinglées dans certains cas qui brise ensuite SSL pour ces sites.
Une façon de contourner cela est désactivée HPKP, ce qui est possible dans Firefox en définissant security.cert_pinning.enforcement_level à 0 et ça fonctionne bien. Y a-t-il une autre façon de contourner ce problème?
// L'hôte que j'ai essayé ceci était une machine Kali avec le navigateur Iceweasel.
L'erreur qui m'a été montrée a déclaré que la connexion était tombée en raison de la TVH de la TVH qui était très déroutante car il y avait aussi des sites Web qui utilisent HSTS et l'interception fonctionnait tout simplement bien. J'ai ensuite compris que cela a apparemment lieu avec HPKP et après avoir désactivé les erreurs HSTS ne se présentaient plus.
Cela semble être un problème spécifique au logiciel. Après que @steffen Ullrich m'a souligné que cela ne devrait pas se passer, je l'ai essayé avec un client Windows 7 et Chrome en tant que navigateur et cela a bien fonctionné.
En cas d'interception de la SSL légale, l'autorité de certification proxy utilisée pour émettre les certificats des connexions interceptées est explicitement importée dans le navigateur/système d'exploitation en tant que confiance. Dans un tel casque, le navigateur ignore à la fois le pinning intégré et l'épinglage effectué avec l'en-tête HPKP. Ceci est explicitement fait de cette façon de faire une interception de la SSL légale (dans des pare-feu, des raisons de sécurité) possibles. Ce qui signifie qu'il n'y a pas besoin de désactiver la clignotation publique dans de tels cas.