HSTS n'est pas dangereux du moment que nous sommes certain que le site sera dorénavant toujours en HTTPS.
Si, le risque c’est que la moindre erreur de configuration rende le site inaccessible, parce que le navigateur n’aura pas le droit de passer outre.
Typiquement, un administrateur oublie de renouveller son certificat et le laisse expirer (un des écueils que Let’s Encrypt cherche à éviter en automatisant le plus possible, justement parce qu’on a constaté que ce genre de choses arrivaient trop souvent dans la réalité) :
Sans HSTS, ce n’est pas trop grave, le navigateur va afficher un message d’erreur mais va laisser à l’utilisateur la possibilité de passer outre (« il y a un problème avec le certificat de ce site. Voulez-vous continuer ? » — ce à quoi l’utilisateur répond « un problème avec quoi ? Évidemment que je veux continuer, je veux continuer ma visite moi. »).
Avec HSTS et si l’utilisateur a déjà visité le site préalablement, c’est mort, le navigateur qui respecte le RFC 6797doit avorter la connexion.
C’est justement le but recherché de HSTS, qui signifie en gros « l’administrateur de ce site ne fait pas d’erreurs, si votre navigateur détecte un problème, c’est qu’il y a réellement quelque chose de louche, ce n’est pas un truc que vous pouvez ignorer en mettant ça sur le compte du laxisme de l’administrateur ».
D’où l’importance de n’utiliser HSTS que si l’on ne fait réellement pas d’erreur...
HPKP pour moi est un vrai risque car il faut faire le pari que ton visiteur va revenir dans le laps de temps qui lui est imparti.
Ce n’est pas un problème, ça. Si le visiteur revient après la durée d’épinglage, on se replace juste dans le cas initial d’une première connexion. Ça n’interdit pas l’accès au site, c’est juste qu’on n’a pas, pour cette « première » connexion, la protection apportée par HPKP.
Pour info, HSTS a un comportement similaire : lui aussi a une directive "max-age" au-delà de laquelle le navigateur ne doit plus considérer que le site doit être accédé en HTTPS uniquement.
les navigateurs décident d'implémenter leur propre résolveur
Je préférerais que les systèmes d’exploitations fournissent par défaut un résolveur DNS validant (que non seulement les navigateurs mais aussi toutes les autres applications pourront utiliser) plutôt qu’un « stub resolver ». À ma connaissance, aucun système ne fait ça à l’heure actuelle, celui qui veut un résolveur validant doit l’installer lui-même.
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 5.
Si, le risque c’est que la moindre erreur de configuration rende le site inaccessible, parce que le navigateur n’aura pas le droit de passer outre.
Typiquement, un administrateur oublie de renouveller son certificat et le laisse expirer (un des écueils que Let’s Encrypt cherche à éviter en automatisant le plus possible, justement parce qu’on a constaté que ce genre de choses arrivaient trop souvent dans la réalité) :
Sans HSTS, ce n’est pas trop grave, le navigateur va afficher un message d’erreur mais va laisser à l’utilisateur la possibilité de passer outre (« il y a un problème avec le certificat de ce site. Voulez-vous continuer ? » — ce à quoi l’utilisateur répond « un problème avec quoi ? Évidemment que je veux continuer, je veux continuer ma visite moi. »).
Avec HSTS et si l’utilisateur a déjà visité le site préalablement, c’est mort, le navigateur qui respecte le RFC 6797 doit avorter la connexion.
C’est justement le but recherché de HSTS, qui signifie en gros « l’administrateur de ce site ne fait pas d’erreurs, si votre navigateur détecte un problème, c’est qu’il y a réellement quelque chose de louche, ce n’est pas un truc que vous pouvez ignorer en mettant ça sur le compte du laxisme de l’administrateur ».
D’où l’importance de n’utiliser HSTS que si l’on ne fait réellement pas d’erreur...
Ce n’est pas un problème, ça. Si le visiteur revient après la durée d’épinglage, on se replace juste dans le cas initial d’une première connexion. Ça n’interdit pas l’accès au site, c’est juste qu’on n’a pas, pour cette « première » connexion, la protection apportée par HPKP.
Pour info, HSTS a un comportement similaire : lui aussi a une directive "max-age" au-delà de laquelle le navigateur ne doit plus considérer que le site doit être accédé en HTTPS uniquement.
Je préférerais que les systèmes d’exploitations fournissent par défaut un résolveur DNS validant (que non seulement les navigateurs mais aussi toutes les autres applications pourront utiliser) plutôt qu’un « stub resolver ». À ma connaissance, aucun système ne fait ça à l’heure actuelle, celui qui veut un résolveur validant doit l’installer lui-même.