Dois-je changer la clé privée lors du renouvellement d'un certificat?
Mon service de sécurité insiste pour que (l'administrateur système) crée une nouvelle clé privée lorsque je veux renouveler un certificat SSL pour nos serveurs Web. Ils prétendent que c'est la meilleure pratique, mais mes tentatives de recherche sur Google n'ont pas réussi à vérifier leur affirmation. Quelle est la bonne façon?
Le plus proche que j'ai trouvé est Dois-je régénérer une nouvelle clé privée SSL chaque année? , mais cela n'explique pas vraiment pourquoi il serait nécessaire de changer les clés.
Je sais que ce n'est pas grave de changer les clés pendant que j'y suis, mais je n'ai jamais été du genre à faire ce qu'on me dit sans raison ou explication appropriée :)
Je dirais que leur suggestion n'est pas très solide, sauf si vous utilisez des tailles de clés horriblement petites - auquel cas vous avez un problème différent.
Une clé de 2048 bits, par la plupart des estimations , vous gardera en sécurité jusqu'à au moins l'année 2020, sinon plus. Si vous utilisez des clés de 1024 bits ou moins, vous êtes en dessous de la norme, et je recommande la mise à jour immédiate vers 2048 bits. Si vous utilisez actuellement des clés 1536 bits, vous devriez être en sécurité pendant un an ou deux.
Bien sûr, tout cela est académique. La probabilité qu'une personne soit capable (ou encline) à casser votre clé SSL 1024 bits dans un an est extrêmement faible.
Comme mentionné dans la question que vous avez liée, il y a des avantages et des inconvénients.
Avantages
- Donne à un attaquant moins de temps pour casser la clé. Un point discutable si vous utilisez des tailles de clé raisonnables de toute façon.
- Arrête tous les malfaiteurs qui pourraient avoir compromis votre clé privée. Peu probable, mais inconnu.
- Vous donne une chance d'augmenter votre taille de clé pour être en avance sur la courbe.
Inconvénients
- Ne vous donne pas vraiment de protection concrète contre la fissuration des clés, sauf si vous utilisez des clés terriblement petites.
- Les plugins de vérification SSL/anti-MitM pour les navigateurs peuvent alerter l'utilisateur que la clé a changé. C'est, à mon avis, un faible inconvénient - la plupart des utilisateurs ne l'utiliseront pas.
- Peut provoquer des avertissements temporaires par rapport aux politiques et implémentations HSTS plus strictes.
- Cela demande du travail. Vous pourriez faire autre chose.
Donc, des deux côtés, il y a quelques raisons faibles et certains cas d'angle que vous devrez peut-être considérer. Je pencherais légèrement vers l'angle "Ne le faites pas, sauf si vous en avez besoin", tant que vous utilisez des clés de 2048 bits ou plus.
La chose la plus importante est de demander eux pourquoi ils pensent que c'est nécessaire - il se peut que vous ayez une raison liée à l'infrastructure pour mettre à jour les clés que nous ne connaissons pas. S'ils ne parviennent pas à trouver un argument solide ("pourquoi pas?" N'est pas vraiment valable), ils devraient probablement réévaluer leurs conseils.
Changer la clé privée n'est pas une meilleure pratique , c'est une répandue entraine toi; cela a en fait très peu à voir avec la sécurité, et beaucoup à voir avec la façon dont les autorités de certification gèrent les renouvellements de certificats, c'est-à-dire la plupart du temps comme un nouveau certificat, avec une nouvelle génération de clé privée. Il est plus simple, côté CA , de ne rien faire de spécial pour un renouvellement. D'où l'habitude de changer les clés.
Les mêmes administrateurs système n'insisteront pas sur la génération de nouvelles clés chaque année pour leurs serveurs SSH, même si la situation est similaire, du point de vue de la sécurité. Ou, plus précisément, la modification d'une clé de serveur SSH est un peu gênante car elle rompt le .ssh/known_hosts fichiers des clients. Par conséquent, il est habituel d'éviter de modifier les clés du serveur SSH. Ainsi, les clés de serveur SSH ont une longue durée de vie. Personne ne saute vraiment un battement de coeur là-dessus. Pourquoi devraient-ils s'inquiéter des clés SSL d'une puissance cryptographique similaire?
La meilleure pratique consiste à changer la clé lorsque les progrès technologiques ont rendu votre clé quelque peu vulnérable, en tenant compte de la paranoïa générale (souvent appelée "pour des raisons de conformité"); vous considéreriez donc qu'en ce moment, en 2013, une clé RSA 1024 bits devrait être remplacée par une clé plus longue, même si nous sommes encore loin de pouvoir casser une telle clé. Si votre clé RSA est de 1536 bits ou plus, il n'y a aucune raison cryptographique d'en créer une nouvelle (mais, là encore, il est peut-être plus pratique de la changer, du côté de l'autorité de certification).
La réponse n'est pas technique ou cryptographique, elle concerne les gens. Avec des choses comme les changements de travail (entendu parler d'administrateurs mécontents?), Les migrations de serveurs, les tests DR, les sauvegardes et les clés privées peuvent devenir un peu exposées.
Compte tenu de ce qui précède, le renouvellement des clés est une meilleure pratique de sécurité.
Ne vous inquiétez pas si quelqu'un prend en compte votre clé RSA. La prise en compte d'une clé RSA 1024 bits peut être possible pour les adversaires au niveau de l'État, mais même pour eux, ce n'est probablement pas rentable. L'affacturage des clés à 2048 bits ne sera probablement pas possible avant quelques décennies.
Je m'inquiéterais principalement du vol de votre clé privée dans un compromis avec le serveur. Le gain en cas de compromis passés n'est pas clair, car l'attaquant pourrait avoir des logiciels malveillants persistants sur votre serveur. Vous devez donc réinstaller le serveur pour sécuriser la nouvelle clé.
Un autre problème est que certaines suites SSL faibles (principalement la famille basée sur le chiffrement RSA) utilisent votre clé à long terme pour la confidentialité, et pas seulement pour l'authentification. Avec ceux-ci, un compromis de la clé de votre serveur permet le déchiffrement de toutes les communications SSL passées avec votre serveur qui utilisait une suite aussi faible. L'utilisation d'une nouvelle clé et la suppression sécurisée de l'ancienne limite l'impact d'une telle attaque.
Donc, si votre serveur a toujours ces suites activées, je recommande fortement de changer la clé régulièrement.
- Avez-vous changé vos clés après HeartBleed?
- Que font les techniciens de votre centre de données avec les mauvais disques durs?
- Quelqu'un a-t-il quitté l'organisation des opérations au cours de la dernière année?
- À quand remonte la dernière fois que vous avez tourné les mots de passe administrateur et les clés ssh?
Toutes ces questions devraient vous amener à réfléchir à l'intégrité de vos clés. Je ne dis pas qu'il est probable qu'ils soient compromis ou que n'importe qui va pouvoir en abuser. J'essaie de vous faire réfléchir à la raison pour laquelle vous voudrez peut-être les faire pivoter.
Les clés rotatives doivent être super faciles et constituent une bonne hygiène de sécurité. Si vous ne le faites pas parce que c'est difficile, c'est un problème grave. Créez les outils et les processus pour vous faciliter la tâche. Si vous ne le faites pas, vous finirez par ne pas faire pivoter des choses beaucoup plus importantes.
Plus vous utilisez une clé, plus vous donnez de temps à un attaquant. Même si la rupture du bit 2048 n'est pas considérée comme possible avec la technologie actuelle, être extrêmement prudent et remplacer la clé n'est pas du tout une mauvaise chose.
De plus, quelqu'un aurait pu obtenir votre clé privée, sans que vous puissiez la détecter. S'il ne peut pas répéter l'action, alors l'avantage du renouvellement est très clair.
Bien que je convienne qu'il y a peu de raisons techniques de générer de nouvelles clés chaque fois que vous renouvelez un certificat, je ne contesterais pas immédiatement votre équipe de sécurité/vos gestionnaires et ne les appellerais pas sur le problème.
Il peut y avoir des raisons non techniques qui sont tout aussi valables pour générer de nouvelles clés. Par exemple, dans une grande organisation où il existe différents niveaux de centralisation informatique, de compétences, de procédures et de bonnes pratiques, une zone de gestion de la sécurité centralisée peut nécessiter de telles pratiques pour aider à atténuer certains des risques. maniable. Bien que des procédures plus complexes puissent être plus correctes d'un point de vue technique, elles sont plus difficiles à documenter et rendent plus difficile pour le personnel de savoir qu'il les suit correctement. À condition que la pratique ne crée pas de frais généraux importants, il peut être plus facile d'adopter et de maintenir l'approche toujours plus simple de X.
Pensez-y sous un autre angle. Est-ce que tous les membres de votre organisation qui sont responsables de la gestion des certificats ont la même conscience et compréhension des problèmes que vous et sont-ils aussi approfondis/dévoués? Quel est le niveau de rotation du personnel et dans quelle mesure faut-il se préoccuper de la quantité de données sensibles auxquelles les anciens employés peuvent avoir accès, etc.
Chaque fois que l'on considère la sécurité, le facteur humain est presque toujours aussi important ou plus important que les seuls aspects techniques. Les politiques et procédures doivent prendre en compte l'élément humain et essayer de s'assurer que ces politiques et procédures sont structurées de manière à permettre au personnel de faire la bonne chose, même s'il peut ne pas comprendre pleinement pourquoi il doit le faire.
SP 800-57 Partie 1 révisée, recommandation pour la gestion des clés
Les recommandations du NIST sur les cryptopériodes RSA semblent être de 1 à 2 ans.
Plusieurs personnes ont évoqué le fait que les clés d'hôte ssh sont rarement tournées comme argument pour ne pas faire tourner les clés ssl. Cela semble être un autre problème à résoudre. (Je m'excuse pour une réponse légèrement hors sujet, mais plusieurs personnes ici l'ont mentionnée, cela semble donc approprié)
Voir ma réponse ci-dessus pour pourquoi on pourrait vouloir faire pivoter les touches.
Les éléments suivants seront particulièrement utiles pour tous ceux qui, pour des raisons de conformité, doivent faire pivoter les clés de l'hôte ssh, mais qui s'inquiètent de l'impact de l'utilisabilité sur les utilisateurs finaux.
1) Déployer un ssh_ca (Instructions remarquablement complètes dans man ssh-keygen)
ssh-keygen -f ssh_ca -b 4096
2) Distribuez le certificat à vos utilisateurs: ajoutez une ligne d'autorité de certification à ~/.ssh/known_hosts
@cert-authority *.domain.name ssh-rsa AAAAB3[...]== Comment
3) Signez vos clés d'hôte (assurez-vous de limiter chacune à un hôte individuel)
ssh-keygen -s ssh_ca -I Host.domain.name -h -n Host.domain.name -V +52w /etc/ssh/ssh_Host_rsa_key.pub
4) Configurez le ou les serveurs pour présenter le certificat (/ etc/ssh/sshd_config):
HostCertificate /etc/ssh/ssh_Host_rsa_key-cert.pub
Toute clé d'hôte signée par l'autorité de certification est désormais approuvée par le client (n'acceptez plus aveuglément une signature de clé la première fois que vous vous connectez)
Le roulement de la clé d'hôte peut désormais être effectué sans interruption pour les clients. La signature de clé peut être intégrée dans le processus de génération/orchestration de l'hôte.
This est une bonne référence. Ce projet a créé quelques outils utiles autour de l'utilisation de ssh_ca pour l'accès utilisateur expirant automatiquement.
C'est vraiment la même chose que de changer les mots de passe. Si quelqu'un est en train de déchiffrer votre mot de passe lorsque vous le changez, il devra recommencer. Ou si le mot de passe ou la clé privée a été volé, le renouvellement invaliderait leur clé volée (en supposant qu'ils ne peuvent pas facilement la voler à nouveau).
Cela peut être une bonne habitude de changer la clé privée chaque année ou toutes les quelques années pour que vous sachiez qu'elle ne cassera rien lorsque vous en aurez besoin, mais ce n'est pas nécessaire pour la sécurité du certificat en soi.