Bonjour,
je viens chercher vos avis après la mise en place de certificats signés par Let's Encrypt sur une machine, chez moi.
Je me pose la question: est ce que ce certificat apporte vraiment plus de sécurité?
L'obtention du certificat est automatisée, quiconque contrôle mon domaine peut créer ce certificat (ou le renouveler?). Cela pourrait être:
- Mon fournisseur de nom de domaine
- Mon FAI
- Quelqu'un sur mon réseau ayant accès à ma box
- Quelqu'un sur mon réseau débranchant mon serveur et prenant son IP
De plus le certificat doit être renouvelé périodiquement, alors si il change, on n'y prête pas vraiment attention. J'ai un serveur Mumble qui tourne chez moi, et j'en viens à me demander si il n'était pas plus sûr avec un certificat autosigné…
Merci pour vos avis éclairés
# Non, mais ce n’est pas Let’s Encrypt le problème
Posté par gouttegd . Évalué à 10. Dernière modification le 27 décembre 2017 à 12:41.
Non. En l’état actual de PKIX, un certificat signé par une autorité de certification reconnue (qu’il s’agisse de Let’s Encrypt ou d’une autre) n’apporte aucune sécurité supplémentaire par rapport à un certificat signé par une autorité non-reconnue.
La seule chose qu’apporte la signature par une autorité reconnue est l’absence de message d’erreur côté client, sans que les clients aient quoi que ce soit à faire (comme installer le certificat racine d’une autorité privée). C’est une mesure de confort, pas de sécurité (ce qui n’est pas négligeable pour autant).
Avec un certificat auto-signé, tes clients sont protégés contre un attaquant passif mais vulnérables à une attaque active de type MITM. Avec un certificat signé par une autorité reconnue, ben… ils sont toujours vulnérables à une attaque active de type MITM, puisqu’il y a what mille autorités de certification là dehors qui peuvent délivrer un certificat frauduleux que les navigateurs des clients accepteront sans broncher (« bah quoi, il est signé par une autorité reconnue, alors c’est bon »).
[^] # Re: Non, mais ce n’est pas Let’s Encrypt le problème
Posté par Krunch (site web personnel) . Évalué à 3.
L'attaque est un peu plus difficile comme même. De plus, si une attaque a lieu il est plus facile de la détecter a posteriori.
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
https://en.wikipedia.org/wiki/Certificate_Transparency
On peut aussi argumenter que le fait que Let's Encrypt force le renouvellement de certificat régulier force les utilisateurs à automatiser et sécuriser le processus. Alors qu'auparavant c'était souvent fait de manière ad hoc.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Non, mais ce n’est pas Let’s Encrypt le problème
Posté par gouttegd . Évalué à 5. Dernière modification le 29 décembre 2017 à 16:08.
Bof, il suffit de trouver une CA peu regardante. Avec certaines, on peut même obtenir (il suffit de demander) non pas un simple certificat frauduleux, mais un certificat intermédiaire permettant au titulaire d’émettre lui-même autant de certificats qu’il veut pour n’importe quel domaine.
Ça fera une belle jambe à ceux qui ont été victimes de l’attaque avant qu’elle ne soit détectée. Ou à celui qui a été victime, si on parle d’une attaque ciblée ne visant qu’une personne bien précise.
le HTTP Public Key Pinning, c’est mort, Google a dit qu’ils n’en voulaient plus. Et comme c’est Google, ben voilà quoi.
Ça par contre ce n’est pas mort puisque Google ne jure que par ça… et ça ne résoud absolument pas le problème. Oui, ça peut permettre une « détection a posteriori » d’une attaque. Ça ne change rien au fait qu’au moment où l’attaque se produit, mon navigateur acceptera sans broncher le certificat frauduleux présenté par l’attaque, Certificate Transparency ou pas.
Là-dessus je suis d’accord.
[^] # Re: Non, mais ce n’est pas Let’s Encrypt le problème
Posté par Krunch (site web personnel) . Évalué à 2.
Donc au final tu admet que Let's Encrypt est un gain net en sécurité par rapport à un certificat signé par une CA non reconnuee…
À court terme, CT ne fait effectivement « que » détecter le problème a posteriori. À moyen/long terme, l'idée c'est d'exposer les CA qui font n'importe quoi et les forcer à améliorer leurs procédures (ou a les faire sortir de la liste des CA reconnues).
Cela dit, même avec juste de la détection a posteriori ça permet souvent de mitiger l'attaque sous jacente. Par exemple si tu sais que les mots de passe utilisés pour un domaine donné sur une plage de temps donnée sont potentiellement compromis, tu peux les (faire) changer plus facilement que si tu n'es pas sûr et que tu dois tous les changer.
Pour les attaques ciblées, HTTPS avec les CA par défaut c'est un peu léger mais Let's Encrypt et CT ne rendent pas la situation pire. Elle est même un peu meilleure. Ce qui n'empêche pas de rajouter des couches d'authentification / chiffrement par dessus selon le modèle de menace considéré.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Non, mais ce n’est pas Let’s Encrypt le problème
Posté par gouttegd . Évalué à 2.
Pas du tout.
Je suis un utilisateur, je me connecte à un site qui me présente un certificat signé par une autorité reconnue et donc mon navigateur ne me dit rien du tout. Quelle certitude ai-je que je ne suis pas victime d’une attaque de type MITM ?
Aucune. Point.
Oh, certes, peut-être que la nécessité pour l’attaquant de devoir obtenir un certificat signé par une CA reconnue (ou par une sous-CA totalement inconnue) réduit quelque peu la probabilité de ce genre d’attaque, en la réduisant à ceux qui savent où et comment obtenir un certificat frauduleux.
Mais une mesure de « sécurité » qui ne fonctionne que dans l’hypothèse heureuse où l’attaquant n’a pas beaucoup de moyens, et ne me donne comme seule garantie que « vous n’êtes probablement pas attaqué, sauf si vous l’êtes »… je n’appelle pas ça un « gain net en sécurité ».
Contrairement à HPKP par exemple, qui après la première connexion alertera immanquablement l’utilisateur de toute tentative d’attaque. Ça c’est un vrai gain en sécurité. Seulement la vrai sécurité, c’est chiant, c’est difficile, alors on vire parce que dire qu’on se préoccupe de la sécurité est plus important que de prendre la peine de le faire effectivement. (La raison avancée par Google pour virer HPKP est que les administrateurs de serveurs ne savent pas gérer ça correctement — ben oui, c’est difficile, la sécurité.)
Je maintiens : utiliser un certificat signé par une CA reconnue est une mesure de confort pour les utilisateurs, en aucun cas une mesure de sécurité. Ça ne veut pas dire que c’est mal, mais il ne faut pas se bercer d’illusion sur ce que ça apporte.
Oui, je connais l’idée, merci. Et perso j’y crois autant qu’à la trickle-down economics …
Let’s Encrypt, peut-être pas. Mais CT, si, absolument, en donnant encore plus d’importance aux CA et en empêchant activement toute méthode d’authentification alternative qui ne passerait pas par les CA.
Les CA font partie du problème, pas de la solution.
[^] # Re: Non, mais ce n’est pas Let’s Encrypt le problème
Posté par Krunch (site web personnel) . Évalué à 3.
Avec un raisonnement pareil, autant abandonner tout de suite. Il n'y a pas de sécurité absolue. Un attaquant qui a suffisamment de moyens finira toujours par arriver à ses fins.
De manière générale il me semble qu'on augmente bien plus la sécurité en rendant les mesures de sécurité plus accessibles qu'en mettant en place un système « parfait » et inutilisable. Voire par exemple https://www.google.com/search?q=usability+site:schneier.com
On peut débattre de savoir si le modèle de CA est « corrigible » ou s'il faut mettre en place un truc complètement différent mais ta conception de la « sécurité » ne me semble pas très réaliste.
Pour en revenir à la question de ted : ça dépend du modèle de menace. Si tu veux pas te casser la tête, Let's Encrypt me semble un bon point de départ et sera plus pratique qu'un certificat autosigné pour tes utilisateurs. Si tu ne fais pas confiance en ton hébergeur / ton serveur, HTTPS ne t'aidera de toute façon pas.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.