pendant la période de transition vers le nouveau certif
Le serveur demanderai une renégociation avec le nouveau certificat après l'établissement avec l'ancien.
Bien évidemment c'est plus lourd, mais c'est une possibilité. Il y en a peut-être d'autres.
Quoiqu'il en soit, c'est effectivement une problématique qui donne un intérêt à ces nouveaux en-tête, ce qui est dommage car l'épinglage devrait être un choix de client non dépendant de celui du serveur quitte à être moins user-friendly.
S'il arrive à ajouter une entête ou voir le trafic qui part sur une URL donnée, c'est qu'il fait déjà du MitM qui fonctionne.
Quelque chose m'avait échappé : le fait que le PKP-RO doit être envoyé après l'établissement du canal sécurisé ce qui ne permet pas à l'attaquant de demander les infos.
Du coup l'attaque nécessiterai une configuration très précise, où notamment, l'accès à la report-uri se ferait en clair et le client ne contacterai pas le serveur entre le moment du report et la date d'expiration de son épinglage.
[^] # Re: Politique de confiance client
Posté par ealprr . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 0.
Le serveur demanderai une renégociation avec le nouveau certificat après l'établissement avec l'ancien.
Bien évidemment c'est plus lourd, mais c'est une possibilité. Il y en a peut-être d'autres.
Quoiqu'il en soit, c'est effectivement une problématique qui donne un intérêt à ces nouveaux en-tête, ce qui est dommage car l'épinglage devrait être un choix de client non dépendant de celui du serveur quitte à être moins user-friendly.
Quelque chose m'avait échappé : le fait que le PKP-RO doit être envoyé après l'établissement du canal sécurisé ce qui ne permet pas à l'attaquant de demander les infos.
Du coup l'attaque nécessiterai une configuration très précise, où notamment, l'accès à la report-uri se ferait en clair et le client ne contacterai pas le serveur entre le moment du report et la date d'expiration de son épinglage.