Puis-je utiliser des clés publiques avec LetsEncrypt?


10

Puis-je configurer Public-Key-Pins lorsque je configure un cronjob pour renouveler le certificat LetsEncrypt tous les 30 jours?

Si le certificat est renouvelé, la clé publique est également renouvelée, n'est-ce pas?

Réponses:


12

Quelques mots de prudence pour commencer:

  • Sachez ce que vous faites, si vous prévoyez de mettre en œuvre HPKP.
  • Si vous ne le faites pas correctement ou "si de mauvaises choses se produisent", qui ne sont pas sous votre contrôle, vous risquez de rendre votre domaine inutilisable.
  • Assurez-vous de tester votre configuration avec un domaine qui n'est pas si important, ou avec un temps de cache très court, comme dix secondes par exemple.
  • Pensez aux certificats que vous souhaitez épingler: racine, intermédiaire, feuille ...
  • Réfléchissez s'il est logique d'épingler une autre autorité de certification (de sauvegarde), ce sont des certificats intermédiaires et votre certificat feuille.
  • Mieux vaut prévenir que guérir: pensez s'il est logique d'épingler une autre autorité de certification / certification de sauvegarde, pour en avoir deux.
  • Si ces points et ces questions vous paraissent «nouveaux»: lisez en quoi consiste HPKP et les pièges et avertissements courants avant de les mettre en œuvre.

Puis-je utiliser des clés publiques avec LetsEncrypt?

  • Oui.

Si le certificat est renouvelé, la clé publique est également renouvelée, n'est-ce pas?

  • Cela dépend du certificat auquel vous faites référence et du ou des certificats que vous épinglez.

9

Serait l'écho de tout ce que gf_ a dit.

Cependant, pour répondre à la question, oui, vous le pouvez.

Par défaut, Let's Encrypt recrée la clé et le certificat au renouvellement. Cela rend la mise en œuvre de HPKP difficile si vous souhaitez épingler la feuille, ce que vous devriez probablement faire en cas de changements intermédiaires ( comme ce fut le cas en mars 2016 ).

Vous avez donc plusieurs options à ce sujet si vous voulez toujours faire HPKP:

  1. Utilisez votre propre CSR fixe plutôt que le client standard qui crée le CSR pour vous à chaque fois afin que la clé feuille ne change pas. Ce billet de blog explique comment procéder spécifiquement parce que l'auteur utilise HPKP.
  2. Utilisez des expirations HPKP courtes et renouvelez dans ce délai d'expiration et modifiez la politique pour avoir à la fois les anciennes et les nouvelles clés avant de changer le certificat, avec suffisamment de temps pour que la nouvelle politique soit récupérée par les visiteurs.
  3. Épinglez la racine Let's Encrypt au lieu de la feuille ou du certificat.

1
Bons ajouts, +1.
gf_

Est-il sûr d'épingler la racine? Pour un MITM, il est vraiment facile d'utiliser son propre certificat Let's Encrypt.
melbic

2
Comment est-il "vraiment facile" pour un attaquant d'obtenir un certificat pour votre nom de domaine en utilisant Let's Encrypt? Pas au courant d'aucune façon de le faire. Cependant, il peut être possible avec n'importe quelle autorité de certification s'ils ont des bogues dans leurs procédures de validation de domaine. En épinglant la racine LE, vous avez massivement réduit votre surface d'attaque à Let's Encrypt uniquement, contrairement à toutes les autorités de certification du monde. Toujours pas aussi sûr que l'épinglage des feuilles, je suis d'accord, mais cela introduit ses propres risques dépend donc de votre définition de «sûr».
Barry Pollard

Dire que je pense qu'il y a des risques massifs pour HPKP - principalement du point de vue de l'auto-suicide - donc je ne suis pas un fan. Si vous décidez de changer d'autorité de certification ou de changement de chemin d'accès au certificat (par exemple en raison de l'amortissement SHA-256), ou si vous devez de toute urgence réémettre le certificat, ou la clé de sauvegarde est compromise / perdue ou la personne qui l'a configurée quitte et la personne suivante ne s'en rend pas compte ils utilisent HPKP et / ou ne le savent pas. HPKP ne protège pas non plus contre les racines locales telles que Superfish. Ainsi, pour la plupart des sites, HPKP, est trop complexe et, à mon humble avis, ne vaut pas la protection supplémentaire pour le petit gain de sécurité supplémentaire. Mais c'est juste mon opinion.
Barry Pollard

Ok, j'ai seulement demandé parce que je pensais que tous les certificats LE ont le même certificat racine. Donc, si vous épinglez la racine, quelqu'un d'autre avec un autre certificat LE peut simplement utiliser un MITM et truquer dans son propre certificat. Tu vois ce que je veux dire?
melbic

5

Je viens de l'implémenter en utilisant le client déshydraté avec validation dns01. Le hook dns01 est certzure car notre DNS est hébergé dans Azure.

Edit: quand je parle de clés privées, évidemment, je veux toujours dire que vous ne transformez que les parties de clé publique en broches. Les clés privées, comme son nom l'indique, doivent toujours rester privées. Voir mon propre crochet pour les détails d'implémentation.


Vous avez besoin d'un roulement de clé privée pour rendre cela possible. Autrement dit, vous avez toujours la clé privée actuelle (appelez-la A) et la future clé privée (appelez-la B) à portée de main, afin que vous puissiez les ajouter à vos épingles. Donc, à ce stade, vos broches sont A et B. Lorsque le jour du renouvellement du certificat arrive, la clé privée A devient obsolète et B devient active. En même temps, vous obtenez une nouvelle future clé privée, appelez-la C. Vous régénérez votre liste de broches alors maintenant elle contient B et C. C'est donc comme ça que vous faites rouler vos clés privées. déshydraté le supporte maintenant .

De plus, vous avez besoin d'un hook qui est appelé à chaque fois que vous renouvelez vos certificats et que vous retrouvez ainsi vos clés privées. Je l'ai implémenté par moi-même .

Enfin, si je comprends bien, vous devez vous assurer que:

HPKP age x 2 < days between cert renewals

Par exemple, si votre âge HPKP est de 50 jours et que vous renouvelez les certificats tous les 30 jours, un client qui a visité votre site le premier jour sera bloqué avec les clés privées A et B, et vous êtes passé à B et C au 31e jour. le serveur a B et C, le client a A et B, il y a une correspondance même le jour 50 et le client ouvre correctement le site.

MAIS voyons si l'âge HPKP est de 70 jours. Vous renouvelez les certificats tous les 30 jours et le client a visité votre site le premier jour. Encore une fois, il n'a que les clés privées A et B. Votre serveur a C et D, le client a A et B, il n'y a pas de correspondance et le client reçoit le majeur du jour 61 au jour 71, lorsque sa politique HPKP expire.


Une autre option, probablement plus sûre et certainement beaucoup plus simple, consiste à utiliser la même clé privée à chaque fois et à générer une ou plusieurs clés privées de sauvegarde, puis à les coder en dur dans votre configuration HPKP et à en finir avec.


Oui, c'est délicat et il pourrait y avoir des mises en garde auxquelles je n'ai pas pensé, mais nous verrons à long terme. Évidemment, je l'ai déployé sur un sous-domaine non critique avec un âge HPKP court (15 jours) afin qu'il ne cause pas d'énormes problèmes.


Edit: J'ai écrit quelques scripts pour vous aider à configurer HPKP avec Let's Encrypt et déshydraté à l'aide de Nginx:

HPKPinx


3
J'ai décidé d'avoir le meilleur des deux mondes. Rollover de clé privée automatisé + une clé privée statique. Pourrait écrire un blog à ce sujet si quelqu'un est intéressé.
bviktor du

1
Si vous faites cela, veuillez modifier votre message et insérer le lien - merci!
gf_

Merci, je ferai de mon mieux pour terminer cela cette semaine ou la semaine prochaine
bviktor

2
Lien ajouté. La documentation est encore rare, mais le code est là pour que vous puissiez l'essayer et le pirater.
bviktor
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.