Alors en fait non, si je réclame plus que 90j de durée de vie, ce n’est pas pour me faciliter la vie :P C’est du à HPKP justement.
À chaque modification de ton épinglage, tu dois t’assurer que TOUS tes anciens visiteurs auront soit leur dernier épinglage vu expiré, soit qu’ils sont repassés suffisamment récemment sur ton site pour avoir le nouvel épinglage.
En pratique, ça n’est possible que si tu respectes 2 conditions :
Tu dois toujours avoir un épinglage d’avance : si tu utilises actuellement la clef N, tu dois publier l’épinglage N et N+1.
Les 2 cumulés font qu’avec Let’s Encrypt, c’est head shot direct...
Le 1er point fait que tu dois avoir une clef prête à l’avance que tu peux déjà publier dans ton épinglage et que tu utiliseras pour la génération de certificat suivante. Très complexe avec la plupart des clients Let’s Encrypt (et ça demande dans tous les cas une bonne maîtrise de X.509).
Le 2nd point fait que tu as un compromis à faire entre « je peux révoquer rapidement ma clef en cas de compromission » (X faible) et « HPKP n’est intéressant qu’avec un délai de rétention élevé » (Sinon expiration entre 2 visites et donc pas d’intérêt). En pratique, le RFC HPKP recommande une durée X de l’ordre de 60j. Avec Let’s Encrypt, comme il est conseillé de renouveler ses certificats à 60j (et pas 90j histoire de se laisser un peu de temps en cas de merde, et avec LE, les merdes arriventtoujours, avec des corrections non implémentables automatiquement...), tu passes en pratique l’intégralité de ta vie à ne RIEN pouvoir faire en cas de compromission de ta clef privée (tu ne peux pas renouveler avant l’expiration du délai de 60j, qui est pile ton délai de renouvelement, tu passes donc 100% de ton temps à poil...).
Pour que HPKP fonctionne correctement, il faut un délai de rétention de l’épinglage très inférieur au délai de renouvellement de ta clef privée.
En pratique, avec une rétention de 60j, j’aurais tendance à conseiller une clef d’au moins 2 ans (60j à poil tous les 730j, soit 8% du temps) voire 10 ans (60j sur 3650, soit 2%).
Et donc se passer totalement du renouvelement de la clef de Let’s Encrypt :)
J’ajoute aussi que, à la différence du certificat, une clef privée n’a PAS de date d’expiration. À partir du moment où vous avez utilisé une clef pour un échange protégé, vous DEVEZ la gérer À VIE, en particulier si vous avez utiliser une suite de chiffrement sans PFS. Cf l’épisode HeartBleed.
Il est donc étrange de la part de Let’s Encrypt d’indiquer que renouveler fréquemment une clef augmente la sécurité, ce n’est à mon avis pas du tout le cas, voire plutôt l’inverse...
Les problèmes précédents existent aussi pour DANE/TLSA, la version DNS de HPKP.
Il est même encore pire puisque DANE/TLSA implique DNSSec, et donc que la phase de renouvelement du certificat ou de la clef devrait impliquer le renouvelement des entrées DNS correspondantes... donc une nouvelle signature de votre zone DNSSec... donc votre serveur web ayant un contrôle root sur votre zone DNSSec... donc le désintérêt total de DNSSec et de DANE/TLSA...
[^] # Re: 90 jours, et alors?
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 2. Dernière modification le 22 septembre 2016 à 11:23.
Alors en fait non, si je réclame plus que 90j de durée de vie, ce n’est pas pour me faciliter la vie :P C’est du à HPKP justement.
À chaque modification de ton épinglage, tu dois t’assurer que TOUS tes anciens visiteurs auront soit leur dernier épinglage vu expiré, soit qu’ils sont repassés suffisamment récemment sur ton site pour avoir le nouvel épinglage.
En pratique, ça n’est possible que si tu respectes 2 conditions :
Les 2 cumulés font qu’avec Let’s Encrypt, c’est head shot direct...
Le 1er point fait que tu dois avoir une clef prête à l’avance que tu peux déjà publier dans ton épinglage et que tu utiliseras pour la génération de certificat suivante. Très complexe avec la plupart des clients Let’s Encrypt (et ça demande dans tous les cas une bonne maîtrise de X.509).
Le 2nd point fait que tu as un compromis à faire entre « je peux révoquer rapidement ma clef en cas de compromission » (X faible) et « HPKP n’est intéressant qu’avec un délai de rétention élevé » (Sinon expiration entre 2 visites et donc pas d’intérêt). En pratique, le RFC HPKP recommande une durée X de l’ordre de 60j. Avec Let’s Encrypt, comme il est conseillé de renouveler ses certificats à 60j (et pas 90j histoire de se laisser un peu de temps en cas de merde, et avec LE, les merdes arrivent toujours, avec des corrections non implémentables automatiquement...), tu passes en pratique l’intégralité de ta vie à ne RIEN pouvoir faire en cas de compromission de ta clef privée (tu ne peux pas renouveler avant l’expiration du délai de 60j, qui est pile ton délai de renouvelement, tu passes donc 100% de ton temps à poil...).
Pour que HPKP fonctionne correctement, il faut un délai de rétention de l’épinglage très inférieur au délai de renouvellement de ta clef privée.
En pratique, avec une rétention de 60j, j’aurais tendance à conseiller une clef d’au moins 2 ans (60j à poil tous les 730j, soit 8% du temps) voire 10 ans (60j sur 3650, soit 2%).
Et donc se passer totalement du renouvelement de la clef de Let’s Encrypt :)
J’ajoute aussi que, à la différence du certificat, une clef privée n’a PAS de date d’expiration. À partir du moment où vous avez utilisé une clef pour un échange protégé, vous DEVEZ la gérer À VIE, en particulier si vous avez utiliser une suite de chiffrement sans PFS. Cf l’épisode HeartBleed.
Il est donc étrange de la part de Let’s Encrypt d’indiquer que renouveler fréquemment une clef augmente la sécurité, ce n’est à mon avis pas du tout le cas, voire plutôt l’inverse...
Les problèmes précédents existent aussi pour DANE/TLSA, la version DNS de HPKP.
Il est même encore pire puisque DANE/TLSA implique DNSSec, et donc que la phase de renouvelement du certificat ou de la clef devrait impliquer le renouvelement des entrées DNS correspondantes... donc une nouvelle signature de votre zone DNSSec... donc votre serveur web ayant un contrôle root sur votre zone DNSSec... donc le désintérêt total de DNSSec et de DANE/TLSA...