Est-ce une bonne pratique de supprimer le mot de passe d'un certificat SSL?


10

J'ai lu sur plusieurs blogs maintenant qu'il faut supprimer les mots de passe des certificats SSL afin d'éviter les invites de mot de passe lors du redémarrage d'Apache.

Est-ce vrai et cela pose-t-il des risques pour la sécurité?


Si vous êtes vraiment inquiet, il existe du matériel disponible, où votre clé privée peut être stockée sur un périphérique USB et ne sera jamais récupérable. Cela ne fonctionnera pas vraiment dans un environnement hébergé.
Zoredache

Je note en passant, juste pour éviter toute confusion, que le certificat n'est jamais chiffré, et cela ne servirait à rien; pour que la prise de contact SSL se termine, le certificat doit être offert en texte brut à toute personne qui le demande. Un certificat n'est qu'une clé publique signée par un tiers. C'est la clé privée , l'équivalent asymétrique de la clé publique (qui est capable de déchiffrer le trafic chiffré vers la clé publique), qui peut être stockée chiffrée et à propos de laquelle vous posez la question.
MadHatter

Réponses:


22

Oui, cela empêchera les invites d'être envoyées au terminal lors du démarrage d'un serveur Web.

Et oui, cela pose un risque pour la sécurité, car là où avant le certificat était crypté, il est maintenant en texte brut. Cela signifie qu'il pourrait être possible de voler un certificat entièrement fonctionnel de la machine.

La question de savoir si cela présente un risque important pour la sécurité dépend des répercussions que cela pourrait avoir si cela vous arrivait et de ce que vous gagnez à le faire de cette façon.

S'il est plus important pour vous que les services redémarrent correctement, même sans surveillance, que la sécurité du système SSL dans son ensemble, c'est une réponse simple.

Personnellement, je trouve que conserver des copies décryptées des certificats SSL a globalement plus d'avantages que d'inconvénients pour ma charge de travail typique, voici pourquoi;

  1. Un attaquant aurait toujours une copie du certificat même s'il était crypté, il serait donc de votre devoir de le révoquer de toute façon.
  2. De nos jours, il est beaucoup plus facile pour un attaquant d'obtenir un certificat valide pour votre site via l'ingénierie sociale que d'en voler une copie de travail.
  3. Les certificats expirent naturellement, ce qui limite leur surface d'attaque.
  4. Les systèmes de sécurité basés sur l'hôte tels que les autorisations traditionnelles et SELinux offrent un moyen robuste de protéger les certificats sur la plate-forme.
  5. Un certificat n'est pas la clé d'un système sécurisé. Il existe de nombreux autres aspects à prendre en compte, tels que les données que vous stockez, les supports sur lesquels vous les stockez et la valeur et / ou la nature personnelle des données.

Choses qui pourraient me faire chiffrer:

  1. Si vous avez utilisé le certificat pour effectuer une authentification mutuelle.
  2. C'est un certificat générique ou un certificat qui héberge plusieurs domaines (les pertes doublent, triplent ou ce que de nombreux hôtes peuvent être utilisés pour cela)
  3. Le certificat est polyvalent d'une autre manière.
  4. Le but des certificats est d'assurer l'intégrité des données de grande valeur (dossiers médicaux, transactions financières et similaires).
  5. L'autre extrémité attend un degré élevé de confiance et / ou dépend de l'intégrité de votre système pour prendre des décisions opérationnelles.

En fin de compte, ne comptez pas sur les autres pour prendre des décisions de sécurité pour vous. Vous devez pondérer les risques et déterminer ce qui est le mieux pour vous et votre institution en utilisant autant d'informations que possible.


8

Il offre un peu plus de sécurité, mais la réalité est que si quelqu'un est entré assez loin dans votre système pour accéder à votre clé SSL privée, vous avez probablement de plus gros problèmes.

D'un point de vue pratique, voulez-vous vraiment être là chaque fois qu'apache doit être redémarré pour mettre un mot de passe?

Une chose que vous pourriez faire est de garder la clé non protégée protégée sur votre serveur (et de la protéger via la sécurité normale du système) et de conserver la sauvegarde de la clé que vous stockez ailleurs avec un mot de passe. Donc, si quelqu'un est capable de supprimer la clé ailleurs que sur votre serveur (beaucoup plus probable, pensez que l'ordinateur portable de quelqu'un est volé avec elle sur son bureau), il est toujours protégé.


0

Les clés utilisées pour la connexion doivent être protégées par mot de passe.

Si vous souhaitez que les services basés sur SSL redémarrent sans intervention manuelle, vous avez deux options:

  1. N'ayez pas de mot de passe sur la clé et protégez-le afin que seuls les services qui en ont besoin puissent y accéder.
  2. Stockez le mot de passe en texte brut ou un équivalent texte brut sur le serveur afin que les services qui en ont besoin puissent fournir le mot de passe. (Vous pouvez vous retrouver avec plusieurs copies du mot de passe dans des fichiers de configuration mal sécurisés.)

Les copies de sauvegarde de la clé doivent être protégées par mot de passe et sécurisées comme si elles n'étaient pas protégées par mot de passe.

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.