Question:
Dois-je rejeter un CSR lorsque l'hôte m'a envoyé par e-mail la clé privée pour la demande de certificat SSL?
scipilot
2017-04-12 17:16:53 UTC
view on stackexchange narkive permalink

Je viens de demander un CSR à mon fournisseur d'hébergement Web partagé, pour générer un certificat que je leur renverrai pour l'installation. (Le certificat lui-même doit être généré correctement par une organisation pour laquelle je travaille et qui peut fournir des certificats pour notre usage officiel.) La société d'hébergement m'a rapidement envoyé le CSR mais aussi la clé privée! Ils ont même copié quelqu'un d'autre, et c'est dans Gmail, donc Google l'a probablement déjà ingéré à des fins publicitaires.

À mon humble avis, cela semble être une chose terrible à faire. Je suis sur le point de leur répondre en rejetant celui-ci, et en demandant de renouveler le CSR et cette fois de garder la clé privée - privée.

Avant de me ridiculiser, j'aimerais confirmer que la clé privée d'un certificat "SSL" (TLS) ne doit jamais quitter le serveur?

Je travaille dans les industries liées à la sécurité depuis de nombreuses années, et j'étais programmeur crypto, donc je pense Je connais un peu le sujet, mais je sais que les choses changent avec le temps.

J'ai lu cette question connexe: Quels problèmes surviennent lors du partage de la clé privée d'un certificat SSL?

Meta Update: j'ai réalisé que j'avais écrit un format de question de mauvaise qualité pour Stack Exchange - car il est maintenant difficile d'accepter une réponse spécifique. Toutes mes excuses - toutes les réponses couvraient des aspects différents et tout aussi intéressants. Je me suis demandé au départ comment le formuler à cette fin, mais j'ai dessiné un blanc.

Mise à jour: j'ai bien suivi cela avec l'hôte et ils se sont "excusés pour tout inconvénient", promis de tenir futures clés privées "sûres" et m'a émis un nouveau CSR différent. S'il est généré à partir de la même clé privée exposée dont je ne suis pas sûr actuellement. Je me demande maintenant aussi, comme il s'agit d'un hôte partagé, s'ils m'ont envoyé la clé pour l'ensemble du serveur ou si chaque client / domaine / hôte virtuel obtient une paire de clés.

C'est une leçon intéressante comment tout la force cryptographique dans le monde peut être rendue nulle et non avenue par une simple erreur humaine. Kevin Mitnik ferait un signe de la tête.

Mise à jour 2: En réponse à une réponse de l'utilisateur @Beau, j'ai utilisé les commandes suivantes pour vérifier que le deuxième CSR a été généré à partir d'une clé privée secrète différente. 

  openssl rsa -noout -modulus -in pk1. txt | openssl md5openssl req -noout -modulus -in csr1.txt | openssl md5openssl req -noout -modulus -in csr2.txt | openssl md5

Les deux premiers hachages sont identiques, le troisième est différent. C'est donc une bonne nouvelle.

_ "et il est dans Gmail, donc Google l'a probablement déjà ingéré à des fins publicitaires." _ Vous vous rendez compte que Google gère sa propre autorité de certification et pourrait insérer pratiquement n'importe quel certificat de l'autorité de certification dans Chrome?Dans ce scénario, Google est probablement l'une des parties les moins intéressées / intéressantes.
Oui, je ne suis pas inquiet pour Google en tant que tel (je leur ai confié ma vie!) Mais juste en soulignant les voyages supplémentaires que notre contenu personnel parcourt de nos jours, même après l'arrivée apparente à destination.
La clé privée est-elle chiffrée?
@DavidSchwartz Non, cela ne semble pas.
Je m'excuse de ne pas avoir publié ce commentaire - je n'ai pas assez de représentants.Mais vous pouvez comparer votre nouveau CSR avec la clé privée d'origine avec quelques commandes openssl: https://www.sslshopper.com/certificate-key-matcher.html.Si le module pour chacun est différent, alors vous devriez être d'accord.Je ne suis pas sûr de faire confiance aux pratiques de sécurité du fournisseur.La sécurité est entièrement une question de confiance, après tout.
C'est très utile Beau - j'ai utilisé ces commandes pour prouver que le nouveau CRS qu'ils ont fourni a été généré avec une clé privée différente - ce qui est une bonne nouvelle, car je n'ai pas à le rejeter aussi.
Ne vous excusez pas, je pense que c'est de ma faute d'avoir écrit une question d'opinion - cette question se transforme en un article wiki précieux :)
BTW c'est assez (dés) drôle la page sslshopper.com a un champ "upload private key"!Et un gros avertissement de ne pas l'utiliser.
À ce stade, passer à une entreprise qui * comprend réellement * la nature d'une clé * privée * pourrait avoir plus de sens, à mon humble avis.Un émetteur de certificats qui envoie volontiers des clés privées par e-mail à plusieurs destinataires ne semble * pas * savoir ce qu'il fait et s'est montré ne pas être aussi compétent.L'utilisation de [certbot] (https://certbot.eff.org/) pose-t-elle un problème?C'est ce que j'utilise pour mon serveur.
@BaileyS Google, la société n'est peut-être pas intéressée, mais Dave, l'employé de Google ayant accès au serveur de messagerie, pourrait l'être.Il y a eu des cas où des employés de Google ont abusé de leur accès aux comptes Gmail de personnes auparavant
@Pharap, la valeur des informations privées d'un individu est fortement surfaite.Vraiment, personne ne se soucie des secrets que vous pouvez garder si chers, les écrasements de Facebook, les journaux de discussion et les probables nudies stockés sur votre sauvegarde WhatsApp.Il est difficile d'admettre que nous ne sommes tout simplement pas si intéressants, et la plupart d'entre nous sont tout simplement ennuyeux.La valeur réelle vient avec d'énormes quantités de données agrégées, où votre individualité se dissout dans le néant par rapport à l'ensemble de données.À moins, bien sûr, que vous soyez la petite amie ado chaude de Poutine ou un PDG de F500, nos données privées individuelles ne valent tout simplement aucun effort.
@hlecuanda Eh bien.[ce gars] (http://gawker.com/5637234/gcreep-google-engineer-stalked-teens-spied-on-chats) l'était certainement.Je suis heureux d'apprendre que mes communications basées sur gmail avec mes amis hackers du pentagone sont sécurisées.Je ne manquerai pas de dire à Betty de faire attention, quelqu'un aurait peut-être compris avec quel chef d'État elle avait arrangé la liaison avec la chambre d'hôtel.
Six réponses:
dr_
2017-04-12 17:52:09 UTC
view on stackexchange narkive permalink

Oui, vous devez absolument rejeter le CSR. De plus, vous devriez changer de fournisseur d'hébergement car il semble qu'il ne sache pas ce qu'il fait.

Il est déjà déjà assez mauvais qu'ils vous aient envoyé la clé privée par e-mail, c'est-à-dire via un support non sécurisé . Cependant, ils l'ont également fait savoir à quelqu'un d'autre, ce qui constitue une violation complète de la confidentialité.

De plus, je me demande pourquoi ils vous ont envoyé la clé privée - elle est censée être installée sur le serveur, ce qu'ils peuvent faire par eux-mêmes.

Ils ont copié l'autre contact sur le compte (non technique).Et oui, je me demandais pourquoi aussi, c'était vraiment ma question.Il n'y a toujours aucune raison - juste m'assurer que je n'ai pas manqué un mémo ici.
Ok, donc ce n'est pas comme s'ils avaient envoyé la clé privée à une personne inconnue de vous.Pourtant, le point principal tient.
@dr01 Bien sûr qu'ils l'ont fait.Tous les administrateurs de serveurs de messagerie, administrateurs de routeurs et administrateurs de pare-feu qui étaient sur le chemin du courrier et qui voulaient le lire.
@DRF Je voulais dire * volontairement * divulgué la clé privée à des tiers.
Je me demande si la clé privée est utilisée pour l'ensemble du serveur partagé, auquel cas vous seriez en mesure d'emprunter l'identité non seulement de votre domaine, mais de toute autre personne utilisant le même serveur.
@dr01 Je pense que si vous envoyez des informations par e-mail, à moins qu'elles ne soient cryptées, vous les divulguez volontairement à chaque ordinateur sur lequel il rebondit jusqu'à ce qu'il atteigne sa destination.
+1 pour avoir demandé à OP de changer de fournisseur, qui a démontré son niveau d'ignorance dans son propre domaine.
@AaronHall C'est volontaire seulement si vous savez comment fonctionne le courrier électronique, sinon c'est une ignorance bienheureuse.Je pense que nous avons décidé que le fournisseur d'hébergement est géré par des incompétents.
vakus
2017-04-12 17:40:50 UTC
view on stackexchange narkive permalink

Si j'étais à votre place, je refuserais d'accepter ce certificat SSL. La raison en est que si quelqu'un pénétrait par effraction dans l'un des e-mails ayant reçu la clé privée, il serait en mesure de le télécharger, puis de se faire passer pour le serveur dans différentes attaques contre des clients, comme man in the middle ou similaire.De plus, dans le cas où l'une des adresses e-mail de réception a été mal écrite, quelqu'un peut déjà avoir la clé privée. Il existe probablement de nombreux autres scénarios dans lesquels cette clé privée pourrait être téléchargée et utilisée par un attaquant.

Il est également important d'avertir l'entreprise de ne pas partager la clé privée, pour s'assurer que l'entreprise ne le fera pas a envoyé la clé privée n'importe où ailleurs - la clé privée vous a été envoyée, ainsi que d'autres CC dans cet e-mail, mais vous ne pouvez pas savoir si l'entreprise n'a pas envoyé un e-mail séparé avec la clé privée ailleurs.

Il y a une raison pour laquelle la clé privée est appelée une clé privée

Veuillez noter que ceci est principalement mon opinion personnelle, et que je ne suis pas un expert en SSL.

Oui, bon point de les éduquer.
À ce stade, le passage à une entreprise qui comprend réellement la nature d'une clé privée n'aurait-il pas plus de sens?Un émetteur de certificats qui envoie volontiers des clés privées par e-mail à plusieurs destinataires ne semble * pas * savoir ce qu'il fait et s'est montré ne pas être aussi compétent, à mon humble avis.
@ray bien si vous changez d'entreprise, alors vous êtes plus en sécurité, mais si au lieu de cela vous les éduquez, tous leurs clients seront en sécurité.Si les éduquer n'aide pas, alors oui, il serait judicieux de changer d'entreprise, mais à ce stade, cela semble évident
@vakus Si vous souhaitez investir dans l'éducation de quelqu'un qui devrait déjà mieux connaître, c'est à vous de décider.Rappelez-vous simplement que les mauvaises pratiques de sécurité visibles pour vous, étant en dehors de l'entreprise, suggèrent des problèmes plus profonds que vous ne découvrirez peut-être jamais (par exemple, comment savez-vous qu'ils n'ont pas Cci cette clé vers d'autres adresses, ou pire?) Et, par conséquent, incapablespour les éduquer.Vous devez décider du niveau de risque que vous avez l'intention de placer * vos * clients dans le but de les «éduquer».Les éduquer ne signifie pas que vous devez rester en tant que client.Partir pourrait les inciter davantage à se réparer
Lie Ryan
2017-04-12 20:25:21 UTC
view on stackexchange narkive permalink

Oui, vous devez absolument rejeter le CSR.

Quant à savoir si vous devez reconsidérer le fournisseur d'hébergement, cela dépend.

Ils ont même copié quelqu'un d'autre,

Y a-t-il des raisons pour lesquelles la société d'hébergement devrait connaître la structure interne de votre entreprise? La personne qui fait cela est-elle un gestionnaire de compte désigné qui a été spécifiquement affecté à votre entreprise et qui est responsable de savoir qui est qui dans votre entreprise? Votre entreprise a-t-elle fourni des informations suffisantes au gestionnaire de compte sur la structure de votre entreprise et sur qui est autorisé à faire quoi? Si ce n'est pas le cas, c'est peut-être en partie la faute de votre (entreprise) de ne pas leur avoir expliqué comment ils doivent vous envoyer la clé.

Dans la plupart des comptes d'hébergement, si vous n'avez pas de compte désigné gestionnaire qui connaît votre secteur d'activité, vous devriez avoir expliqué très clairement à son support technique comment vous envoyer les clés, qui devrait les recevoir et si vous souhaitez ou non recevoir la clé en premier lieu. Ne présumez pas qu'un personnel du support technique connaît la situation de votre entreprise et ne supposez jamais qu'un personnel du support technique qui n'est pas votre responsable de compte désigné se souvienne de qui vous êtes lors d'une interaction précédente.

et c'est dans Gmail

Vous vous rendez compte que l'envoi d'un CSR par e-mail n'est pas non plus très sécurisé, non? Il est tout à fait possible que quelqu'un (un initié travaillant dans Gmail ou un APT) intercepte l'e-mail contenant le CSR, remplace le CSR que l'hôte vous envoie par son propre CSR et signe le CSR de la société d'hébergement à la société d'hébergement. Cela leur permettrait d'utiliser plus tard les faux certificats MITM entre vous et vos utilisateurs et la société d'hébergement.

Un CSR doit être livré via un canal authentifié (par exemple, ils soumettent le certificat à un site HTTPS que vous contrôlez ou ils doivent signer le CSR avec une clé GPG qu'ils publient sur leur site), ou à tout le moins, vous devez faire une empreinte digitale vérification et vous et votre hôte devez avoir un moyen d'identifier et d'authentifier l'autre partie. La configuration d'un canal authentifié peut être un processus assez complexe, et ce n'est pas quelque chose qui sera disponible chez les fournisseurs d'hébergement à bas prix ou ceux qui ne se spécialisent pas dans l'hébergement professionnel de haute sécurité.

Si vous ne le faites pas ne spécifiez pas comment votre entreprise exige que le CSR soit livré, et surtout si vous n'êtes pas traité par un gestionnaire de compte qui devrait savoir quel type d'entreprise vous faites, alors la plupart des hébergeurs supposeraient raisonnablement que vous êtes une société à sécurité minimale. La plupart des personnes travaillant dans une entreprise à sécurité minimale considèrent que le fait d'avoir une copie de la clé privée a une valeur plus élevée que la sécurité de ne pas contrôler la clé, il n'est pas déraisonnable pour eux de le supposer de votre part.

`Il est tout à fait possible pour quelqu'un ... d'intercepter l'e-mail contenant le CSR` - Avez-vous un lien ou quelque chose avec plus de détails à ce sujet?J'essaye de suivre comment cela fonctionnerait.
@Zoredache C'est super facile.Vous travaillez chez Google.Vous exécutez un script pour rechercher les e-mails non remis dans la base de données Gmail qui ont été envoyés aux utilisateurs au cours des 5 dernières minutes et qui contiennent ce qui semble être des charges utiles de clé privée.Vous déplacez temporairement cet e-mail vers une zone de transit afin qu'il ne soit pas livré, puis créez la charge utile alternative.Ensuite, vous placez le courrier électronique modifié avec votre charge utile malveillante dans la base de données où l'utilisateur le verra comme un autre bon courrier électronique attendu.
HTTPS n'aidera rien à moins qu'il ne dispose d'une authentification client, à quel point vous pourriez aussi bien signer le CSR avec le certificat client et avoir moins de travail.Le seul moyen sécurisé de fournir un CSR est d'utiliser l'authentification hors bande.Selon le niveau de sécurité que vous souhaitez, cela peut être aussi simple qu'un appel téléphonique et la lecture de l'empreinte digitale ou aussi ennuyeux que de devoir se présenter en personne.
@ErikE Bien sûr, si la clé privée est envoyée, il y a un problème, mais la réponse de LieRyan dit qu'un CSR seul dans un e-mail peut être abusé.Je ne suis pas en train de suivre comment vous pourriez utiliser MITM avec seulement un CSR.À moins que vous ne pensiez que l'attaquant peut intercepter le CSR et est également configuré sur MITM tous les accès au serveur pour lequel le certificat est réellement émis.
@Zoredache Le transfert d'un CSR (sans clé privée, bien sûr) ne pose en soi aucun risque de sécurité.Le demandeur a généré une paire de clés privée-publique qu'il souhaite associer à une entité à protéger (par exemple, utiliser avec un site https pour www.example.com) et demande gentiment à un signataire de confiance de signer et ainsi confirmer quecette connexion entre la clé publique et l'entité liée existe.Ce qui doit avoir lieu de manière sécurisée hors bande, c'est plutôt le processus de vérification du fait que le CSR a été émis par une personne détenant un contrôle digne de confiance de l'entité à protéger.
Oui, je me rends compte que les e-mails normaux eux-mêmes ne sont pas non plus sécurisés, j'ai l'impression que ces jours-ci, les e-mails sont moins appréciés par les individus et que l'acceptation de l'accès par des tiers est plus normale.Auparavant, seuls les postmasters / administrateurs système avaient accès au contenu du courrier pendant qu'ils faisaient la queue, dans un simple courrier électronique traditionnel.Maintenant, c'est beaucoup plus complexe avec beaucoup plus de surfaces d'attaque et un niveau de personnel inférieur avec un accès potentiel (je pense).Par Gmail, j'entendais aussi le webmail, donc par exempleAd Block Pro et tous les autres plugins de navigateur "lisent" probablement mes e-mails.
C'est un très bon point, et original, que je ne leur ai pas précisé comment le livrer.Vous avez probablement raison, j'ai mis la barre implicitement bas.Mais je leur ai seulement demandé le CSR, que je pense être partageable, donc cela n'avait pas élevé mon niveau de conscience normal, par exemple.dans le passé, j'ai demandé aux hôtes de sauvegarder les informations d'identification dans un fichier de l'environnement hébergé auquel je peux accéder (via SCP).
J'aurais dû mentionner que la personne cc'd est le "titulaire du compte" et que je suis le "contact technique", donc ils semblent toujours les cc.Je n'ai pas formé cette personne, car je ne m'attendais pas à un problème.
@Zoredache: oui, je faisais référence à quelqu'un qui peut également configurer un MITM, tel qu'un administrateur de n'importe quel système dans le centre de données / chemin réseau en amont de l'hôte Web, ou quelqu'un qui exécute un [DNS public largement utilisé] (https: // développeurs.google.com/speed/public-dns/).Quelqu'un qui peut intercepter vos e-mails pourrait au moins modifier votre e-mail afin qu'il contienne deux CSR, le vrai et un faux, et vous dire une histoire de couverture plausible comme avoir un équilibreur de charge redondant où ils installent un certificat séparé et que le HSM ne le fait pas.prend en charge l'exportation de clé privée.
"La configuration d'un canal authentifié peut être un processus assez compliqué" - Comptez-vous keybase.io comme canal authentifié?
Peter Green
2017-04-13 02:59:57 UTC
view on stackexchange narkive permalink

Avant de me ridiculiser, j'aimerais confirmer que la clé privée d'un certificat "SSL" (TLS) ne doit jamais quitter le serveur?

Cela dépend, il peut y avoir de bonnes raisons pour qu'il quitte le serveur. Par exemple, vous voudrez peut-être utiliser le même certificat sur plusieurs serveurs ou vous voudrez peut-être une clé de sauvegarde pour l'épinglage de clés.

Mais cela absolument doit être traité comme un secret précieux, uniquement stocké sur des machines en qui vous avez confiance et s'il a besoin de se déplacer entre les systèmes, cela doit être fait de manière sécurisée de manière appropriée.

Mon conseil serait de s'éloigner de ces clowns immédiatement.

Bon point, je l'ai même fait moi-même dans le passé.Je me suis senti assez nerveux et j'ai utilisé SSH pour le transférer directement au deuxième hôte.
trognanders
2017-04-13 03:33:08 UTC
view on stackexchange narkive permalink

Ils voulaient probablement que vous ayez toute la paire clé / certificat au cas où vous voudriez l'utiliser ailleurs.

La circulation de la clé privée est un problème de sécurité légitime, en particulier si vous ne comptez pas l'utiliser. Expliquez que ce certificat est uniquement destiné au fournisseur d'hébergement et demandez-lui de réémettre le CSR et de l'envoyer sans clé privée. Vérifiez que l'empreinte numérique CSR change.

On dirait qu'ils traitent le certificat comme un moyen de faire apparaître un verrou vert plus que comme un dispositif de sécurité, ce qui est probablement un signe d'avertissement. Envisagez un hébergement différent si cela est possible et / ou si votre site gère des informations très sensibles.

Marquis of Lorne
2017-04-13 05:47:10 UTC
view on stackexchange narkive permalink

Ils sont totalement incompétents en matière de sécurité. Une clé privée est, err, privée, par définition. Il sert à identifier légalement son propriétaire. Ils ont rendu possible la falsification et l'usurpation d'identité.

Vous devriez leur envoyer le CSR, après l'avoir généré vous-même depuis votre paire de clés privée / publique, et ils devraient vous envoyer le certificat signé et sa chaîne d'authentification. Rien d'autre.

S'ils vous envoient des clés privées et des CSR, tout leur modèle est cassé.

Changez de fournisseur et récupérez votre argent. À moins. Ils ont compromis votre sécurité, donc une action en dommages et intérêts peut être intentée. Au moins, vous pouvez les menacer pour faciliter le processus de remboursement.

Je suis à peu près sûr qu'il n'identifie pas son propriétaire de manière légale, mais simplement technologiquement.
Je pense que vous avez mal compris le rôle du fournisseur ici (sauf si je l'ai fait): ils n'émettent pas le certificat, ils l'installent sur un serveur auquel l'OP n'a qu'un accès limité.L'OP ne peut pas générer la paire de clés, car ils n'ont pas accès pour installer la clé privée dans la configuration du serveur Web.S'ils le faisaient, * ils * devraient transmettre la clé privée * à l'hôte *.L'hôte générant la paire de clés et envoyant le CSR semble être absolument le bon processus, mais il a raté le point en partageant la clé privée.
@QPaysTaxes Une signature numérique avec une clé privée est juridiquement exécutoire comme tout à fait équivalente à une signature personnelle sur un contrat ou un chèque.
@IMSoP Si plusieurs personnes ont la clé privée, elle n'est pas privée.Si le rôle du fournisseur est ainsi interprété, il est radicalement incertain.L'envoyer à tous viole totalement PKI.
@EJP Huh, je n'avais aucune idée.C'est plutôt cool!Par curiosité, pouvez-vous citer une loi / une décision spécifique qui l'a rendu ainsi?Est-il mondial, répandu ou spécifique aux États-Unis?
@QPaysTaxes Le * but * des signatures numériques est d'être licite.C'est une loi bien établie aux États-Unis, en Australie, au Royaume-Uni, ... Je ne suis pas avocat et je ne peux pas fournir les références que vous recherchez.
@EJP Oui, j'ai compris.Mais vous avez manqué le point dans la question initiale que la seule personne qui devrait détenir cette clé privée particulière est l'hébergeur Web.Nous convenons tous qu'ils ont fait une erreur en le partageant, mais votre suggestion selon laquelle l'OP devrait générer sa propre paire de clés n'a aucun sens, car la clé privée doit se retrouver dans la configuration du serveur, à laquelle seule la société d'hébergement a accès.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...