Quels sont les problèmes liés au partage de la clé privée d'un certificat SSL?
Scénario: j'héberge un site Web pour un de mes clients, que nous appellerons S. S possède le domaine s.com et je possède les serveurs qui hébergent réellement le site Web. S souhaite maintenant activer SSL sur son site Web.
J'ai généré une clé privée et un CSR sur mon serveur, et envoyé le CSR à S afin qu'ils puissent le soumettre à leur CA.
Cependant, comme tous les clients, S est bon marché. Ils ne veulent pas dépenser de l'argent pour un nouveau certificat. Au lieu de cela, ils veulent me donner leur certificat SSL existant pour *.s.com et sa clé privée correspondante. Ce certificat et cette clé sont déjà utilisés par S et certains autres fournisseurs de S.
Je sais déjà que c'est une mauvaise idée, mais pourquoi? Quels problèmes cela cause-t-il maintenant et potentiellement à l'avenir?
Pour les points bonus, le partage d'une clé privée comme celle-ci pose-t-il des problèmes dans le contexte des normes PCI?
Les certificats génériques sont mauvais pour plusieurs raisons:
- La même clé privée doit aller sur les systèmes qui ont différents niveaux de sécurité, donc votre clé n'est aussi bonne que votre système le moins protégé. Le donner à des fournisseurs tiers est vraiment mauvaise idée, car cela échappe complètement à votre contrôle.
- Vous devez conserver des enregistrements méticuleux qui montrent exactement où votre clé privée générique est installée, de sorte que lorsque vous devez la remplacer, vous n'avez pas à jouer "Où est Waldo" sur tous vos sites.
- Plus important encore, si la clé privée et le certificat générique sont volés à un moment donné, les attaquants peuvent alors emprunter l'identité du système any dans cet espace générique. L'erreur courante est de dire "nous utiliserons des certificats génériques sur les systèmes à faible sécurité, mais des certificats nommés sur tous les systèmes importants" - vous devez faire exactement le contraire! Si les attaquants ont * .s.com, ils peuvent emprunter l'identité de n'importe quel domaine dans l'espace .s.com, qu'il utilise d'autres certificats. Donc, si vous avez "www.s.com" avec un caractère générique et "login.s.com" avec un certificat unique, les attaquants peuvent se faire passer pour "login.s.com" indépendamment de ce qui se trouve sur "login.s.com" .
- Le moyen le plus simple de tirer parti des clés génériques volées est par empoisonnement DNS ou via des points d'accès sans fil malveillants.
Cela étant dit, il faut évaluer les risques. Si votre ami S donne déjà ce certificat générique et cette clé à tous les fournisseurs, refuser de l'accepter ne réduit pas ses risques de manière significative. Vous aurez juste l'air obstiné et peu coopératif et perdrez ses affaires. Faites de votre mieux pour éduquer, mais comprenez également que certaines personnes s'en moquent.
Si, cependant, il est tenu de se conformer à PCI-DSS, alors je suis presque sûr qu'il n'est pas conforme, car je pense que vous êtes censé avoir des journaux de tous les accès aux clés de chiffrement privées. Je laisserai d'autres plus familiers avec PCI-DSS développer cela.
Quiconque a accès à la clé privée utilisée par un serveur SSL a le pouvoir technique de:
- Emprunter l'identité d'un serveur dont le nom correspond à celui inscrit dans le certificat.
- Décrypter les sessions qui ont été écoutées passivement (à moins que la session SSL n'utilise l'une des suites de chiffrement "DHE" qui fournissent secret de transmission parfait , mais ces suites sont rarement sélectionnées par défaut, quelqu'un doit les configurer explicitement).
Donc, donner la même clé privée à de nombreuses personnes, c'est vraiment leur faire confiance et leur faire confiance. N'oubliez pas que "quelqu'un en qui vous avez confiance" est une expression qui signifie vraiment "quelqu'un qui a le pouvoir de vous trahir".
D'une manière générale, une fois qu'une valeur secrète est connue de plus de deux personnes, elle n'est plus secrète, mais plutôt discrète. De plus, vous ne pouvez pas forcer l'oubli, donc si votre client S veut cesser de faire affaire avec l'un des fournisseurs auxquels S a donné une copie de la clé privée, il doit annuler le tout (révoquer le certificat, en créer un nouveau avec une nouvelle clé, et la distribuer) - alternativement, S peut monter d'un niveau sur l'échelle de crédulité, et juste supposer que tout le monde est honnête et compétents, et que les fournisseurs avec lesquels ils n’ont plus de relations commerciales s’occuperont néanmoins de leur clé privée, sans la divulguer via une bande de sauvegarde ou un stagiaire indélicat.
De plus, la prise en charge des certificats génériques est connue pour être un peu fragile, car ils ont toujours été une source de problèmes (pas en soi, mais ils amplifient la puissance de nuisance d'un malfaiteur qui arrive à voler la clé privée correspondante). Les fournisseurs de navigateurs ont tendance à les restreindre de manière arbitraire et changeante.
Il existe des autorités de certification qui fournissent des certificats de serveur SSL gratuitement . Comment devez-vous être bon marché pour trouver des certificats gratuits trop chers?
L'utilisation du même certificat sur de nombreux serveurs (approuvés) ne pose pas de problème en soi.
Le principal problème sera dans le cas où la clé privée tomberait entre de mauvaises mains (de l'un des nombreux fournisseurs, vous inclus).
Il est plus difficile de connaître une violation - si de nombreuses personnes/machines possèdent le certificat, la probabilité d'une violation augmente et la probabilité de découvrir la violation diminue. Si S.com est une cible de valeur relativement élevée, l'utilisation du même certificat sur tous les services signifie également que les pirates potentiels peuvent choisir le serveur le plus faible à exploiter.
Lorsque le certificat doit être révoqué, tous les fournisseurs doivent immédiatement remplacer le certificat par un nouveau pour éviter que les clients ne le rejettent. Cela signifie également que le client peut ne pas vouloir révoquer le certificat (car cela "causerait trop de tracas"). Si différents fournisseurs avaient des certificats différents, seul le certificat divulgué devrait être révoqué et seul ce fournisseur unique devrait installer un nouveau certificat.