Salut
Je récupère l'administration d'un serveur web (2-3 sites Wordpress).
Ma première tâche va être d'activer HTTPS.
Réduction des coûts oblige, je regarde Let's Encrypt.
Je m'interroge sur la pertinence d'utiliser ces certificats.
Oui, ils sont gratuits, mais limités à 90 jours.
Il faut donc les renouveler régulièrement, ce qui implique des coûts d'exploitation, soit pour le renouvellement manuel, soit pour l'exploitation du script d'automatisation.
Finalement, autant payer quelques dizaines d'euros et être tranquille pendant deux ans.
Des avis ?
Merci.
David.
# Let's Party
Posté par n0wic . Évalué à -9.
Un certificat ressemble à un mot de passe, il est utile de révoquer un certificat que cela soit à 90 ou à 120 jours. D'où vient cette limite ? Supprimer la révocation équivaut à diminuer le niveau d'encryptions.
L'objectif de "Let's encrypt" c'est bien de fournir un certificat Publique pas vétuste pour garder un certains niveau d'anonymisation ?
# 90 jours, et alors?
Posté par GG (site web personnel) . Évalué à 6.
90 jours n'est pas un problème.
Il y a plein de mécanismes pour le renouvellement automatique avant terme.
Une fois que c'est en place, on a tendance à l'oublier.
Enfin, la mise en place des certificats Let's Encrypt est bien plus simple qu'avec les autres certificats. Sincèrement.
Let's Encrypt, c'est très bien. Il existe moins bien mais c'est plus cher.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: 90 jours, et alors?
Posté par EauFroide . Évalué à 2. Dernière modification le 21 septembre 2016 à 15:03.
Chez moi le script d'auto renouvellement ne fonctionne pas.
Rajoute que si on utilise une machine via plusieurs hostname (Tor ou Lan par exemple) et qu'on utilise le certificat let's encrypt (prévu pour WAN), les applications seront cassé au prochain renouvellement (j'ai eu le cas avec mon client Caldav et mon client owncloud qui ont cessé de fonctionner en attendant que je revienne accepter le nouveau certificat).
Pour des sites de commerce, Let's encrypt est bien, mais pour de l'auto hébergement let's encrypt est une horreur.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: 90 jours, et alors?
Posté par Framasky (site web personnel) . Évalué à 5.
C'est le script qui ne fonctionne pas ou la prise en compte du nouveau certif ? Moi avec nginx, j'ai mis
&& /usr/sbin/nginx -s reloadaprès l'appel du script de renouvellement dans le cron.Alors oui, je reloade nginx même quand il n'y a pas de nouveau certif, mais :
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: 90 jours, et alors?
Posté par EauFroide . Évalué à 1. Dernière modification le 21 septembre 2016 à 18:11.
Non c'est l'auto renouvellement qui ne fonctionne pas dans mon cas. J'ai testé avec le-renew et letsencrypt-auto.
Il faut que je me repenche sur la question car j'avais laissé tombé par lassitude ^ ^
Mais j'ai posté toutes les infos dans ce tuto que j'étais en train de rédiger pour l'occasion.
Je pensais passer par un sha256sum (je suis "contraint" de propager via SSH mes certificats TLS sur au moins deux machines)
PS: pour revenir sur les 90 jours de validité, il me semble avoir lu sur le site d'aeris que s'était incompatible avec HSTS.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: 90 jours, et alors?
Posté par gouttegd (site web personnel) . Évalué à 5.
Non. La durée de validité du certificat n’a aucun impact sur HSTS. HSTS dit juste « ce site ne doit être accédé qu’à travers une connexion HTTPS », sans aucune référence au certificat.
Là où la durée de validité peut poser problème, c’est avec HPKP, où l’on épingle la clef publique du certificat dans un en-tête HTTP. Avec HPKP, il devient nécessaire d’anticiper le changement de clef afin de pouvoir publier à l’avance la nouvelle clef (sinon on « casse l’épingle », empêchant ceux qui avaient déjà visité le site de revenir tant que la période d’épinglage n’est pas passée).
À ma connaissance, la plupart des clients ACME ne sont pas compatibles avec HPKP, du moins par défaut. En effet, ils génèrent une nouvelle clef à chaque renouvellement de certificat, sans laisser la possibilité de pré-publier la future clef dans les en-têtes HPKP.
Néanmoins, il est toujours possible de générer soi-même à l’avance la future clef, et donc de prendre en charge la pré-publication des épingles.
Évidemment, le risque de mauvaise manipulation (publication d’une mauvaise épingle ?) n’est pas négligeable… ce qui est un argument supplémentaire en faveur de l’automatisation. Encore une fois, si tu ne fais ça qu’une fois tous les trois ans, tu n’es pas incité à avoir une procédure robuste.
(Et j’ai personnellement l’impression que pas mal d’administrateurs en herbe voudraient des certificats valables trois ans précisément pour ne pas avoir à « se prendre la tête » avec ça trop souvent, ce qui veut bien dire que c’est quelque chose de trop pénible et/ou difficile pour eux… Mais dans ce cas, augmenter la validité du certificat pour avoir à le renouveler moins souvent n’est qu’une façon de balayer la poussière sous le tapis… ça donne un peu de tranquillité sur le coup mais le problème n’a pas disparu pour autant.)
[^] # Re: 90 jours, et alors?
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 22 septembre 2016 à 11:23.
Alors en fait non, si je réclame plus que 90j de durée de vie, ce n’est pas pour me faciliter la vie :P C’est du à HPKP justement.
À chaque modification de ton épinglage, tu dois t’assurer que TOUS tes anciens visiteurs auront soit leur dernier épinglage vu expiré, soit qu’ils sont repassés suffisamment récemment sur ton site pour avoir le nouvel épinglage.
En pratique, ça n’est possible que si tu respectes 2 conditions :
Les 2 cumulés font qu’avec Let’s Encrypt, c’est head shot direct…
Le 1er point fait que tu dois avoir une clef prête à l’avance que tu peux déjà publier dans ton épinglage et que tu utiliseras pour la génération de certificat suivante. Très complexe avec la plupart des clients Let’s Encrypt (et ça demande dans tous les cas une bonne maîtrise de X.509).
Le 2nd point fait que tu as un compromis à faire entre « je peux révoquer rapidement ma clef en cas de compromission » (X faible) et « HPKP n’est intéressant qu’avec un délai de rétention élevé » (Sinon expiration entre 2 visites et donc pas d’intérêt). En pratique, le RFC HPKP recommande une durée X de l’ordre de 60j. Avec Let’s Encrypt, comme il est conseillé de renouveler ses certificats à 60j (et pas 90j histoire de se laisser un peu de temps en cas de merde, et avec LE, les merdes arrivent toujours, avec des corrections non implémentables automatiquement…), tu passes en pratique l’intégralité de ta vie à ne RIEN pouvoir faire en cas de compromission de ta clef privée (tu ne peux pas renouveler avant l’expiration du délai de 60j, qui est pile ton délai de renouvelement, tu passes donc 100% de ton temps à poil…).
Pour que HPKP fonctionne correctement, il faut un délai de rétention de l’épinglage très inférieur au délai de renouvellement de ta clef privée.
En pratique, avec une rétention de 60j, j’aurais tendance à conseiller une clef d’au moins 2 ans (60j à poil tous les 730j, soit 8% du temps) voire 10 ans (60j sur 3650, soit 2%).
Et donc se passer totalement du renouvelement de la clef de Let’s Encrypt :)
J’ajoute aussi que, à la différence du certificat, une clef privée n’a PAS de date d’expiration. À partir du moment où vous avez utilisé une clef pour un échange protégé, vous DEVEZ la gérer À VIE, en particulier si vous avez utiliser une suite de chiffrement sans PFS. Cf l’épisode HeartBleed.
Il est donc étrange de la part de Let’s Encrypt d’indiquer que renouveler fréquemment une clef augmente la sécurité, ce n’est à mon avis pas du tout le cas, voire plutôt l’inverse…
Les problèmes précédents existent aussi pour DANE/TLSA, la version DNS de HPKP.
Il est même encore pire puisque DANE/TLSA implique DNSSec, et donc que la phase de renouvelement du certificat ou de la clef devrait impliquer le renouvelement des entrées DNS correspondantes… donc une nouvelle signature de votre zone DNSSec… donc votre serveur web ayant un contrôle root sur votre zone DNSSec… donc le désintérêt total de DNSSec et de DANE/TLSA…
[^] # Re: 90 jours, et alors?
Posté par gouttegd (site web personnel) . Évalué à 4.
Voire même N (clef actuellement en service, sur le serveur), N+1 (future clef, à l’abri hors-ligne), et clef de secours (stockée dans une grotte gardée par des orques, d’où tu ne la sors qu’en cas de pépin).
Je ne peux pas parler pour tous les clients, mais je réfute que ce soit « très complexe » avec le client Certbot. Il suffit de générer soi-même la clef et la requête de certificat (ce que tu devais faire de toute façon avec une CA plus traditionnelle), et d’utiliser l’option
--csrde Certbot.Pas plus que pour travailler avec une CA traditionnelle — avec laquelle tu dois déjà générer toi-même la CSR (si tu utilises une CA qui te génère la clef pour toi et te la donne en même temps que le certificat, euh comment dire…)
Complètement d’accord là-dessus, je n’ai d’ailleurs pas dit autre chose, que ce soit dans ma réponse ci-dessus ou dans mon dernier journal sur Let’s Encrypt.
Le renouvellement du certificat (pas de la clef) n’implique le renouvellement des enregistrements TLSA que si tu épingles le certificat lui-même (selector à 0) au lieu de la clef publique (selector à 1)… ce qui est déconseillé (même si pas très fortement) par le RFC 7671 : dans le cas où tu épingles au niveau terminal (DANE-EE au lieu de DANE-TA), il est conseillé d’épingler la clef publique plutôt que le certificat entier. (Et si tu épingles à un niveau intermédiaire, la question des renouvellements échappe totalement à ton contrôle de toute façon.)
Pas nécessairement. Mon serveur n’a pas les clefs de signature de ma zone DNS.
[^] # Re: 90 jours, et alors?
Posté par Aeris (site web personnel) . Évalué à 1.
Je veux dire qu’il faut déjà savoir générer une CSR. Donc comprendre comment la générer proprement (SAN, SHA-2…), faire la danse de la pluie et sacrifier 2 caisses de poulets lors de l’invocation openssl correspondante…
C’est un peu le sens de ce que je disais. Si tu veux faire les choses proprement, on en revient à restreindre LE à « une CA comme les autres ». Donc on s’attendrait à quand même pouvoir émettre du certificat d’un an…
Ça a l’intérêt de justement dégager la notion de CA, qui est bordélique au possible et devrait mourir vu le taux de compromission parmi ces trucs…
Donc de désactiver la gestion de la clef par LE :P
Je veux dire par là que ton serveur de renouvellement, nécessairement en DMZ par design (ACME challenge) va devoir modifier les entrées TLSA. Donc doit avoir accès à la zone DNS en écriture. Ce qui casse tout l’intérêt de TLSA (séparation forte/physique entre certificat et DNS).
En cas de compromission de ton certificat/clef, il y aura de fortes chances que l’attaquant puisse du coup modifier tes entrées TLSA au passage.
(En théorie, ton serveur DNSSec devrait être un shadow master hors DMZ, faisant les rollovers nécessaires et publiant via AXFR à ton « master » (en fait un slave du coup) DNS public qui lui est en DMZ. Ainsi tes clefs DNSSec sont à l’abri en cas de compromission de la DMZ.)
[^] # Re: 90 jours, et alors?
Posté par gouttegd (site web personnel) . Évalué à 3.
Quoi, le fait d’épingler le certificat entier ? Pas du tout, ça ne sert à rien. Le principe de l’enregistrement DANE-EE est justement que seule la clef publique du certificat compte, toutes les autres informations portées par le certificat doivent être ignorées et remplacées par les informations fournies par l’enregistrement TLSA lui-même (le nom de l’enregistrement donne le nom du serveur, et la durée de validité de la signature DNSSEC associée donne la durée de validité de la clef épinglée). Dans ces conditions, épingler le certificat n’apporte rien de plus qu’épingler la clef publique.
Dit autrement, c’est le principe même de l’enregistrement DANE-EE qui permet(trait) de dégager la notion de CA, pas le fait d’épingler le certificat au lieu de la clef publique.
Encore une fois, je n’ai pas dit autre chose.
Et je rappelle à toute fin utile que la décision de changer de clef à chaque renouvellement n’est pas une décision de l’autorité de certification Let’s Encrypt. C’est une décision purement locale qui est du seul ressors du client, Let’s Encrypt n’impose rien du tout sur ce point.
Pas si tu épingles la clef publique et que tu ne changes pas de clef à chaque renouvellement — ce que tu es parfaitement libre de faire.
OK, en fait tu trolles.
Fin de la discussion pour moi.
[^] # Re: 90 jours, et alors?
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 22 septembre 2016 à 13:18.
DANE-TA/EE n’est encore implémenté nul part malheureusement :'(
Mais TLSA, si tu pin sur le certificat, permet de s’affranchir des CA moisies, vu que si un faux certificat est émis (y compris par ta CA), il ne validera pas TLSA.
Un pin sur ta CA ou son intermédiaire te protège uniquement d’une usurpation par une autre CA.
Un pin sur ta clef ne te protège plus d’une compromission de ladite clef (possibilité d’émettre de nouveaux certificats, mais je t’accorde que ce cas est de toute façon un « tout est foutu » :P).
Et il est plus facile pour un humain de valider l’empreinte du certificat (dispo nativement et facilement dans les détails du certificat de ton navigateur) que celle de la clef associée (beaucoup plus difficile d’accès).
LE n’incite pas à faire autrement. Et les paramètres par défaut sont malheureusement plus proche d’une imposition par le prestataire que d’un choix local. Les probabilités qu’un utilisateur les remettent en cause sont assez faibles (c’est même un des gros problèmes actuels de la crypto, avec des softs possédants une configuration par défaut mauvaise, et un des cheval de bataille du monde sécu du moment avec le « privacy/security by design »).
Je te laisse mettre ici la ligne de commande openssl pour générer un CSR multi-domaine avec SAN et extensions X.509 corrects. On va rigoler…
J’ai même du développer ma propre PKI LE pour arriver à faire des choses correctes à ce niveau…
[^] # Re: 90 jours, et alors?
Posté par gouttegd (site web personnel) . Évalué à 3.
Faudrait savoir, en quoi TLSA permet de s’affranchir des CA moisies si ce n’est « implémenté nulle part » ?
(Au passage, c’est faux. Il y a des implémentations de DANE fonctionnelles, même si aucun navigateur ne les intègre par défaut. Et Victor Dukhovni, qui a implémenté DANE dans Postfix, travaillait aux dernières nouvelles à ajouter le support de DANE directement dans OpenSSL, où ça pourra bénéficier à pléthore d’applications.)
Un pin sur le certificat ne te protège pas davantage contre ce cas, celui qui a mis la main sur ta clef pourra potentiellement s’en servir tant que la signature de l’enregistrement TLSA n’aura pas expirée.
Ah ouais quand même. Donc c’est trop dur pour un administrateur système d’invoquer
openssl reqcorrectement, par contre tu attends d’un simple utilisateur qu’il compare lui-même, manuellement, l’empreinte du certificat telle que présentée par le navigateur avec celle qu’il sera aller chercher dans le DNS.Avec dans le fichier
req.cfg:Vas-y, rigole dans ton coin. Moi ça fait déjà quelques messages que tu ne me fais plus rire.
[^] # Re: 90 jours, et alors?
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 22 septembre 2016 à 14:52.
J’ai dit que DANE-TA/EE n’était pas implémenté (ie sans validation de la chaîne X.509 et qui permettrait d’avoir de l’auto-signé sans erreur lors de la navigation). PKIX-TA/EE est implémenté (plugin firefox disponible) et implique la validation X.509 en plus de DANE/TLSA.
Ça protège plus que juste sur la clef. Un pin sur le certificat empèchera par exemple une interception MitM via un faux certificat généré avec la même clef. En cas de compromission de la clef, avec un pin sur le certificat, le seul moyen d’attaque reste l’interception directe pour déchiffrement a posteriori du trafic RÉEL entre un client et le serveur.
Ce cas est hardcore, on est d’accord, mais ce petit détail peut te laisser un peu plus de temps pour révoquer la clef compromise sans mettre (trop) en péril tes utilisateurs.
Je ne pourrais pas te citer les cas concrets associés pour des raisons évidentes de sécurité, mais la vérification manuelle ça a (et ça peut toujours) potentiellement sauver des vies, oui :) (Par exemple quand ton navigateur ne permet pas la validation DNSSec ou DANE/TLSA).
C’est exactement ce que je dis. Hors de portée d’une personne standard.
D’ailleurs ton exemple est erroné puisque le CN devrait être identique à au moins un des SAN indiqués, généralement même le 1er.
Et il te manque aussi la gestion des paramètres d’utilisation de la clef (avec sa compatibilité Netscape).
[^] # Re: 90 jours, et alors?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4. Dernière modification le 22 septembre 2016 à 15:05.
Donc dans le cas ou un pirate aurait volé la clef sur ton serveur, mais n'aurait pas été capable de récupérer le certificat lui-même, pourtant public puisque non seulement présent sur ton serveur avec des permissions d'accès au moins aussi larges, mais en plus fourni à chaque connexion TLS.
Si tout l'intérêt de l'épinglage par certificat, c'est de se prémunir contre ce cas inexistant, autant dire que ça ne sert à rien.
[^] # Re: 90 jours, et alors?
Posté par gouttegd (site web personnel) . Évalué à 3. Dernière modification le 22 septembre 2016 à 15:30.
NON. Ça c’est pour la compatibilité avec de très vieux clients qui ne connaissent rien d’autre que le CN et qui ne tiennent pas compte des SAN. L’utilisation du champ CN pour identifier le serveur est deprecated (cf RFC 6125).
(Et de toute façon dans le cas d’une CSR destinée à Let’s Encrypt peu importe, puisque la CA ignore complètement le CN fourni dans la requête. Le CN présent dans mon fichier de config est un reliquat de l’époque où je signais moi-même mes certificats.)
Ça c’est l’autorité de certification qui les ajoute au moment de signer la requête. (Tu peux les mettre d’emblée dans la requête si tu veux mais je ne connais aucune CA qui accepte de recopier bêtement les extensions de la requête dans le certificat final.)
# L’automatisation, c’est bon, mangez-en
Posté par gouttegd (site web personnel) . Évalué à 7.
Un des objectifs de Let’s Encrypt est clairement de pousser à l’automatisation. En fait, c’est leur deuxième key principle :
Je suis pour ma part à fond pour l’automatisation. Avec ou sans Let’s Encrypt d’ailleurs (avant de passer à Let’s Encrypt, j’utilisais des certificats signés par ma propre autorité de certification, et l’une des raisons était justement de pouvoir créer/renouveller/remplacer des certificats en une seule commande sans aucune étape manuelle).
Le souci avec les certificats à longue durée de vie (outre le fait que la révocation dans le monde HTTPS ne fonctionne pas en pratique), c’est que si tu n’installes un nouveau certificat qu’une fois tous les trois ans, c’est une opération trop rare pour que tu sois bien familiarisée avec.
On a vu le résultat lors de la faille Heartbleed : des dizaines de messages d’administrateurs en herbe sur divers forums, demandant « on me dit que mon certificat actuel est compromis, comment je fais pour le remplacer ? » Et tous ceux qui ne faisaient pas la différence entre renouveller un certificat (en gardant la même clef privée, ce qu’il ne fallait pas faire dans le cas d’Heartbleed) et générer un certificat avec une nouvelle clef.
L’installation d’un certificat devrait être une opération de routine qu’un administrateur doit pouvoir faire immédiatement sans avoir à se replonger dans ses notes d’il y a trois ans (dans l’hypothèse heureuse où il avait pris des notes). Idéalement, ce doit être complètement automatisé ; a minima, l’administrateur doit avoir une procédure écrite à laquelle il n’a qu’à se référer.
Des certificats valides pendant trois ans n’incitent pas les administrateurs à mettre en place une telle procédure.
Personnellement, j’utilise le test suivant : supposons que j’apprenne à l’instant que je dois remplacer mon certificat (cas d’une faille Heartbleed-like), combien de temps me faut-il pour le faire¹ (en supposant que je suis devant mon ordinateur lorsque j’apprends la nouvelle) ? Si la réponse est « plus de deux minutes », c’est que la procédure n’est pas assez automatique.
¹ Sans casser les épingles TLSA et/ou HSTS, bien sûr, sinon c’est trop facile.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 2.
Sauf qu’ils l’ont déjà rendu impossible par au moins 2 fois :
* Changement de l’URL de leur CGU, ce qui a explosé tous les outils de génération. Pas mal de monde a du attendre la mise-à-jour (de LE puis de leur distribution…) pour pouvoir générer de nouveau des certificats.
* Passage de l’intermédiaire X1 à X3, ce qui a cassé toutes les chaînes de certificats (si vous aviez HSTS actif, ça a signifié l’impossibilité totale pour vos visiteurs de se connecter à votre site, il n’y a plus de bouton « Continuer quand même » sur l’alerte de sécurité dans ce cas).
Et que certains choix techniques empêchent en pratique une génération 100% automatique sans réduire DRASTIQUEMENT la sécurité globale de ton système d’information :
* Gestion du multi-frontal, par exemple un HA proxy ou de la virtualisation (comment je pousse le même certificat et clef sur tout le parc sans avoir un god-master root en DMZ sur tout mon parc ie le 7ème cercle de l’enfer)
* Impossibilité de générer du certificat sur du HTTPS-only (il faut obligatoirement HTTP actif, un comble…)
* Gestion impossible ou extrêmement complexe de HPKP et pire de DANE/TLSA
* Pas de support de IPv6 jusqu’à très récemment
* Impossibilité de récupérer le certificat racine automatiquement
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Pourquoi veux-tu que ça casse quoi que ce soit ? Le protocole ACME, et son implémentation par Let's Encrypt, fournit l'URL certificat intermédiaire lors de l'émission du certificat. Un client ACME bien fichu doit pouvoir l'utiliser, et n'a aucune raison de dépendre d'un certificat intermédiaire donné : s'il change, il récupère le nouveau et tout marche comme sur des roulettes.
Eh bien tu ne le pousse pas, tu le tires. Sérieusement, c'est un problème qui n'est pas du tout lié à Let's Encrypt : tu as une architecture compliquée, eh bien c'est compliqué à maintenir à la main, et compliqué à automatiser, c'est dur, mais c'est la vie.
Pour HPKP, c'est peut-être parce que l'idée même d'épingler un certificat est une belle connerie, qui est vouée à se retourner contre l'administrateur au moindre changement, et pour rappel, des changements, ça arrive de façon systématique et prévue, mais aussi de façon imprévue, hein.
Quant à DANE, je ne vois pas en quoi Let's Encrypt empêche ou complique excessivement quoi que ce soit.
Génial l'argument : Let's Encrypt c'est nul parce qu'avant ça ne faisait pas telle chose. (Bon, maintenant ça le fait, mais avant ça ne le faisait pas, donc c'est trop nul quand même.)
Ça n'a pas été prévu en effet. Mais ça n'est pas pire que la concurrence, qui ne permet même pas de récupérer l'intermédiaire automatiquement.
Et accessoirement, en fait tu peux tout à fait récupérer le certificat racine automatiquement : le certificat intermédiaire est fourni, et une fois que tu l'as, tu peux chercher l'URL de CA Issuers, qui permet de télécharger le certificat racine.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 22 septembre 2016 à 14:32.
Ce n’était pas le cas de certbot (à l’époque en tout cas) : il ne renouvellait que le certificat, et demandait à l’utilisateur d’embarquer en dur la chaîne intermédiaire (générée au 1er appel de certbot).
Et même pour ceux qui avait automatisé à mort, ils se sont retrouver avec 2 chaînes différentes (les certificats pas encore renouvelés et ceux fraîchement renouvelés), mais un seul chain.pem utilisé pour tous les vhosts via SSLCertificateChainFile (ça a donné pas mal de soucis en pratique en tout cas.)
Tirer, ça pose les problèmes de synchronisation. Il faut tiré pile après avoir renouvelé, et depuis toutes les machines en même temps pour éviter les problèmes de certificats pas identiques entre les machines.
Et mon archi n’est pas compliquée, c’est le b.a-ba d’une infra correcte aujourd’hui (virtualisation, dual stack ipv4 (reverse proxy)-ipv6 (direct access), HA proxy…)
Si tu changes de pin, il faut mettre à jour les entrées TLSA. Ce qui est encore plus compliqué à mettre en place que de tirer les certificats…
Quand ce n’est pas juste totalement buggé chez LE.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Mauvais client ACME, changer client ACME.
Pareil, mauvais client ACME, changer client ACME. Sérieusement, récupérer le certificat intermédiaire automatiquement, mais le mettre au même endroit pour tous les certificats, c'est une grossière erreur de conception, à corriger ou à faire corriger.
Eh bien pousse, dans ce cas. Ah oui, mettre à jour un fichier sur un serveur ça demande d'avoir un accès en écriture dessus ? Et c'est censé être un problème ‽ Mais c'est normal ça, tu voudrais quoi d'autre ? Franchement, je ne comprends pas l'argument, là.
Eh bien, si ce n'est pas compliqué, il n'y a pas de problème. Tu veux que ce soit géré de façon automatique, automatise-donc sa gestion, mais ne te plains pas que Let's Encrypt ne le fasse pas pour toi : ils permettent de récupérer le certificat automatiquement, ce que tu en fais, ça te regarde.
Ça, c'est toi qui voies ce que tu veux épingler avec TLSA. Si tu épingles la clef, tu peux faires des renouvellements sans changement de clef, et ne rien changer dans le DNS. Si tu épingles le certificat, forcément, tu doit faire un changement dans le DNS, mais ce n'est pas la faute de Let's Encrypt, seulement une conséquence de tes choix d'administrateur. Et si c'est compliqué à automatiser dans ton cas, tout ce que ça indique, c'est que tu as une architecture qui n'est gérée que de façon partiellement automatisée.
Dans tous ces cas, les problèmes que tu soulèves ne viennent pas de Let's Encrypt, qui font simplement, à peu de chose près, ce qui peut se faire de mieux, à savoir automatiser l'émission et la récupération de certificats. Intégrer ça sur un serveur tout simple, c'est trivial, intégrer ça dans une architecture plus complexe, eh bien c'est plus complexe, mais toujours automatisable quand on s'en donne les moyens. Et dans tous les cas, c'est toujours mieux que le processus manuel avec les autres autorités de certification.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1.
Oui, c’est un problème. Actuellement, pour pouvoir pousser sur mon infra, je me retrouve avec une machine en DMZ avec un HTTPd dessus (pour le challenge ACME), contenant l’ensemble de mes clefs privées, CSR et certificats, avec une clef SSH root sans mot de passe permettant l’accès à la totalité de mon parc (HTTPd content + reverse, HA proxy, postfix/dovecot, jabber… nécessaire pour scp les clefs/certificats + restart des services associés), devant rester allumée la majorité du temps (quand tu gères une 100aine de certificats avec 90j de renew, tu en as au moins 1 par jour à être renouvelé), y compris au shadow master DNSSec (pour pouvoir changer les TLSA et resigner la zone) et à mes config HTTPd (pour les empreintes HPKP).
Je te laisse imaginer ce qu’il se passe si cette machine se fait compromettre…
Une telle machine existait auparavant, mais elle était sur une machine air-gap, allumée 1× par an pendant 10min pour renouveler tous les certificats en 1× (même si les dates d’expiration sont différentes, tu peux grouper fortement les batchs). Aujourd’hui, elle est en DMZ et allumée H24…
Non. Je me retrouve à 1- utiliser LE, à désactiver la moitié de ses features et paramètres par défaut, pinner sur la clef ou 2- utiliser LE, pinner sur le cert, avoir la fucking machine de l’horreur en prod et en DMZ ou 3- utiliser LE, pinner sur le cert, ne pas pouvoir automatiser complètement (TLSA non pris en charge de manière sécurisée).
Non. L’automatisation avec LE implique une BAISSE de la sécurité globale de ton système. Uniquement par le fait du renouvellement du certificat à 90j. Ils le mettraient à 1 an, je pourrais automatiser complètement de manière sécurisée (avec certes un lancement humain de la procédure chaque année).
HTTP/2 a fait la même erreur que LE : réduire TLS à simplement les clefs et certificats X.509. TLS, c’est BEAUCOUP plus que ça, son écosystème est bien plus complexe.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Eh bien, ça confirme que cette difficulté d'automatisation tient à ton infrastructure particulière, pas aux caractéristiques du service de Let's Encrypt.
Personnellement, à ta place je mettrais en place un système tiré. Tous les deux mois, ta machine spéciale fait signer et récupère un nouveau certificat, et toutes les semaines par exemple, tes machines tirent le certificat et relancent ou rechargent d'elles-mêmes leurs services. Si tu veux faire plus fin, elles peuvent ne relancer ou recharger leurs services que si le certificat a changé et après vérification de sa validité. Ça n'a pas besoin d'être spécialement synchronisé. Avec ce système, ta machine de la mort n'a plus d'accès root pour faire n'importe quoi, seulement moyen de filer de la merde comme certificat, ce qui est infiniment plus facile à résoudre en cas de problème, et rien de plus.
Si tu préfères faire ça à la main une fois par an, tu n'es pas obligé de te fournir chez Let's Encrypt. Et ce n'est pas une raison pour leur reprocher… pour leur reprocher quoi, au juste ?
Lapin compris.
Comme je l'indique plus haut, tu peux l'automatiser, seulement tu as choisi de bouder cette possibilité pour des raisons qui t'appartiennent. C'est ton choix, donc tu ne peux pas en blâmer Let's Encrypt.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1.
Ce n’est pas possible en pratique.
Tu dois synchroniser le changement de certificats sur l’ensemble du parc.
Par exemple les empreintes HPKP ou TLSA doivent être mise-à-jour en même temps que les certificats sur les HTTPd frontaux ou sur le postfix.
Tirer ne fonctionne que si tu n’as qu’une unique machine de concernée par le certificat. C’est rarement le cas en pratique (HPKP/TLSA) et surtout sur le web (reverse proxy, HA proxy, proxy cache…).
Tu ne peux pas te permettre d’avoir ton HTTPd qui tire le certif, et 2h après le TLSA qui se met à jour.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Je ne connais pas les détails d'HPKP, ne m'y étant pas intéressé parce que cette idée me semble foireuse, mais concernant TLSA, il me semble qu'on peut avoir plusieurs enregistrements à la fois, ce qui résoudrait le problème ici : au renouvellement du certificat, ta machine de la mort ajoute un TLSA, et ensuite les serveurs ont un mois pour tirer le nouveau certificat avant que le précédent expire. Lorsqu'il expire, la machine de la mort retire l'ancien TLSA.
Pour sécuriser encore plus cela, et éviter que ta machine de la mort ait la main sur tout le DNS, tu peux au choix :
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à -1.
Tu as le choix entre :
* Monter une infra délirante à l’opposé des principes de sécurité des technologies utilisées (TLSA étant intéressant quand il y a justement une séparation physique entre la machine détenant le certificat et celle détenant l’entrée DNS et que donc quelqu’un pouvant manipuler le certificat ou la clef ne pourra PAS manipuler le DNS), avec de la mise-à-jour automatique, des clefs partout et des systèmes de permission nécessitant presque d’écrire de nouveaux RFC pour gérer ton DNS de manière sécurisée
* Taper sur LE pour avoir des certificats de 1 an
Le rasoir d’Ockham indique que la bonne solution est la 2, pas la 1…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Un des buts de Let's Encrypt étant de favoriser l'automatisation, ça n'arrivera pas.
Vu tes idées et ton goût pour la maintenance manuelle, je suggérerais plutôt de monter une alternative à Let's Encrypt, proposant le même service mais sans le but d'automatisation.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 23 septembre 2016 à 11:15.
Quand on fait de la sécurité, tout n’est pas automatisable. Loin de là.
Va dire par exemple à l’ICANN qu’ils n’ont qu’à automatiser le renouvellement de la clef racine DNSSec (qui aujourd’hui réclame 4h et une 20aine de personne)…
Je l’aurais fait sans soucis si je n’avais pas besoin de ce f***** audit pour être intégré aux navigateurs.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Michaël (site web personnel) . Évalué à 4.
Tu dis des choses bizarres la fréquence à laquelle les certificats sont renouvelés ne change essentiellement rien à la procédure, et si tu es capable d'accomplir cette procédure de façon que tu juges sécurisée avec une connection distante, je ne comprends pas ce qui t'empêche d'automatiser cette procédure.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1.
Si la fréquence change beaucoup de chose.
Le lancement de la procédure (automatique et sécurisée) nécessite l’accès à une machine air-gap ou à des ressources hors ligne (clef SSH administrateur, disque dur chiffré verrouillé…), qu’il faut déverrouiller et lancer manuellement.
Je peux parfaitement faire ça 1 ou 2× par an (c’est ce qui est fait pour la signature DNSSec racine par l’ICANN par exemple), je ne peux pas faire ça tous les 60j (et encore moins avec 100 certificats qui fait que je vais devoir le faire presque chaque jour).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Michaël (site web personnel) . Évalué à 2.
Je prends la discussion en plein vol et je ne connais pas les détails, mais bien naïvement je me dis que ta procédure doit:
Je suppose que c'est ton token qui te permet de t'authentifier auprès de let's encrypt qui est caché sur ton disque dur crypté sur ta machine derrière un air gap … je comprends qu'on fasse attention à ce genre de choses, mais en réalité tu obtiendrais une meilleure sécurité en montant un serveur constant ( immutable en anglais :) ) faisant tourner un service qui récupère les nouveaux certificats chez let's encrypt et les met à disposition de tes autres machines (par exemple sous forme d'un paquet debian, rpm ou autre, d'une image docker ou d'un simple fichier crypté). En effet si ton serveur constant n'accepte aucune connexion entrante, même sur un réseau il est plus sécurisé qu'une machine de travail utilisée pour récupérer le certificat et le pousser sur les autres machines de l'infrastructure.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0.
C’est plus compliqué que juste le lien avec LE.
DNSSec impose un roulement régulier de ta clef de signature.
En fait de tes 3 clefs de signature :
Ces clefs ne doivent absolument pas sortir de ton parc et sont extrêmement critiques. Il est donc impossible de mettre ça sur ton serveur DNS primaire, qui est en DMZ et exposé sur le net, donc potentiellement attaquable.
Pour parvenir à tenir le renouvellement toutes les 2h de manière sécurisée, on utilise ce qu’on appelle un shadow master. Ton DNS primaire devient en réalité un secondaire, et tu montes un serveur DNS OpenDNSSec bien à l’abri dans ton parc derrière une tonne de firewall et isolé de l’Internet (air-gap, et potentiellement éteint 99% du temps).
À chaque signature de zone, le shadow master signale à ton DNS « primaire » qu’il y a eu un changement de zone, et ton primaire va alors télécharger la nouvelle zone via le mécanisme AXFR de DNS.
Si tu dois modifier ta zone DNS, tu dois alors intervenir sur le shadow master, demander la resignature de la zone, qui sera poussée sur ton primaire.
Le problème avec LE, c’est que ton frontal web va du coup se mettre à renouveller des certificats (peu importe la sécurité du token ou de la clef du certificat ici), et que le changement de ces certificats nécessitent de mettre à jour les entrées TLSA de ton DNS.
Sauf que pour faire ça, il faudrait qu’il ait accès à ton shadow master. Qui par définition ne doit jamais être mis en contact avec une machine de ta DMZ. Donc pas de ton frontal web. Donc impossible de mettre à jour TLSA. Donc impossible d’utiliser LE.
Pour l’idée des paquets Debian ou autres, ce n’est pas possible avec HTTPs, puisqu’il faudrait être capable de synchroniser l’installation des paquets sur X machines (dont des machines hors DMZ pour DNSSec) lors du renouvellement du certificat : déploiement du certificat sur tous les HTTPd (backend, reverse et HA proxy), modification des vhosts HTTPd concernés pour HPKP, changement des TLSA pour DANE (impossible car hors DMZ, sans connectivité, voire éteint).
Sans synchro, on pourrait se retrouver avec des certificats différents fonction du reverse sur lequel tu tombes après le HA proxy ou si tu passes par IPv4 (reverse) ou IPv6 (backend), avoir un certificat présenté différent de celui indiqué dans les entêtes HPKP ou les entrées TLSA, etc.
(Pour HPKP, c’est même encore plus problématique puisqu’il faut prévoir le rollover de l’empreinte au moins 60j avant la modification réelle. Donc déjà avoir le prochain certificat à dispo.)
NB: Pour les taquins qui signaleraient que DNSSec impose des rollovers de 2h alors que LE en impose des de 90j, le choix des 2h est une obligation technique et non un choix arbitraire.
DNS est basé sur UDP, et ne peut donc pas envoyer de paquets de plus de 548 octets, donc DNSSec est obligé d’utiliser des tailles de clefs volontairement faibles (1024 bits et moins) et des algos de hash faibles (SHA-1) pour pouvoir faire rentrer tout ça dans UDP.
On doit donc renouveller TRÈS fréquement les clefs et les hash pour éviter un bruteforce de la zone qui prendrait peu de temps vu les algos utilisés.
De plus, DNS embarque nativement un mécanisme de synchronisation (NOTIFY pour signaler un changement, AXFR pour récupérer les modifications), ce qui facilite le montage d’un shadow master hors DMZ, alors que LE/HTTPS/X.509 n’en possède pas.
Et enfin, DNSSec peut être fait totalement offline sur le shadow master (qui est du coup un vrai shadow master) alors que LE impose une connectivité internet et l’accès aux frontaux web (donc pas de shadow master hors DMZ possible).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Michaël (site web personnel) . Évalué à 2.
Merci pour tous ces détails! :)
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par gouttegd (site web personnel) . Évalué à 7.
Mon Dieu la quantité de désinformation dans ce message ><
C’est recommandé mais en aucun cas imposé. La seule chose qui est réellement imposé est le renouvellement des signatures elles-mêmes, qui ne sont valides que pour un intervalle de temps donné.
PERSONNE ne t’impose ces délais de renouvellement. Tu les choisis, toi et toi seul.
Le RFC 6781 donne à titre indicatif, pour la durée de validité des signatures, une plage allant de « quelques jours » à « plusieurs mois ».
Encore une fois, tu t’imposes ça. Il y a d’autres possibilités, par exemple opter pour un compromis avec une ZSK disponible sur le serveur primaire (via un HSM plutôt que directement sur le serveur pour ceux qui ont les moyens) pour re-signer périodiquement la zone, seule la KSK restant hors-ligne.
C’est d’ailleurs la principale raison d’avoir une ZSK et une KSK séparées (non, ça non plus ce n’est pas « imposé » par DNSSEC). Si tu les considères toutes les deux comme également critiques, devant absolument être hors ligne, autant se simplifier la vie et se contenter d’une seule clef.
Seulement si tu choisis ① d’épingler les certificats plutôt que les clefs publiques (j’ai déjà dit plus haut que ça n’apportait rien dans le cas où tu épingles au niveau terminal, et que c’est déconseillé par le RFC 7671) et ② de renouveller les clefs à chaque renouvellement de certificat, ce que RIEN NE T’OBLIGE À FAIRE (je ne suis pas le seul à te l’avoir dit, et ne viens pas dire « ouais mais c’est pas le comportement par défaut des clients », quand on monte des usine à gaz comme tu sembles aimer le faire, gérer soi-même les CSR avec un client ACME n’est pas hors de portée).
Si, ton choix des 2h est une obligation totalement arbitraire que tu t’imposes à toi-même.
Pour information, DNS fonctionne aussi bien sur UDP que sur TCP (seuls les administrateurs restés bloqués dans les années 90 continuent à croire que le DNS ne passe que sur UDP), et l’utilisation de TCP est même de plus en plus fréquente (en partie à cause/grâce à DNSSEC justement, qui augmente considérablement la taille des réponses).
D’une, TCP existe (cf. ci-dessus), et de deux, même en UDP, EDNS(0) permet de spécifier des tailles de paquets supérieures.
En général, on est plutôt sur du 2048-bit pour les KSK et 1024-bit pour les ZSK — et encore, la tendance est à la généralisation du 2048-bit même pour la ZSK (par exemple, la nouvelle ZSK 2048-bit de la racine vient d’être pré-publiée, et devrait bientôt entrer en service).
On a bien compris que tu n’aimais pas Let’s Encrypt. On t’oblige à l’utiliser alors que ce n’est pas compatible avec les choix arbitraires que tu as fait (et qui sont les seuls bons choix possibles, évidemment — quiconque ne fait pas les mêmes choix que toi est un inconscient qui n’y connais rien en sécurité, non mais c’est qui le crypto-terroriste ici ?), donc c’est le Mal.
C’est bon, on a compris, plus la peine de raconter n’importe quoi pour faire passer le message. ><
/plonk
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Il y a une autre raison : il est beaucoup plus facile de changer de ZSK que de KSK, cette dernière devant être déclarée au bureau d'enregistrement, ce qui s'automatise assez mal.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Quand on n'utilise pas franchement des algorithmes à courbe elliptiques, qui permettent de réduire considérablement la taille des enregistrements pour une sécurité identique, voire supérieure.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par EauFroide . Évalué à 2.
D'imposer une valeur arbitraire qui ne favorise pas du tout l'auto-hébergement.
Vouloir remplacer les auto-signé tout en voulant imposer un mécanisme qui casse tout tout les mois et demi, c'est pas top top…
Perso "je suis chez let's encrypt" uniquement pour supprimer l'alerte de sécurité bidon affichée par Firefox et consort et surtout son mécanisme qui empêche d'afficher une page web en https si des ressources proviennent de deux serveurs ou plus utilisant des auto-signé. (si tu veux de la sécurité pour visiter mes webservices, ils sont accessible via Tor Hidden Service)
J'ajoute que j'aimerais que mon infra puisse fonctionner même si on la coupe d'internet pendant un an, ce que let's encrypt empêche.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1.
Je n’aurais pas mieux dis :)
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par gouttegd (site web personnel) . Évalué à 3.
OK, donc quand tu te plaignais de ces gens qui montent des usines à gaz pour utiliser Let’s Encrypt sans comprendre que ce n’est pas adapté à du large scale… tu parlais de toi en fait ?
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1.
Le post initial est https://status.imirhil.fr/notice/48923.
Et oui, je parlais aussi de moi. Malheureusement, Let’s Encrypt reste la seule solution viable pour les non-pro (je n’ai pas 400 boules par an à claquer dans un certificat, surtout quand je gère au moins une 10aine de domaine et une 100aine de certificats).
Et d’ailleurs, le gouvernement américain en est arrivé à la même conclusion que moi sur Let’s Encrypt :
* LE, ça ne marche simplement que quand tu as une mono-serveur
* un gros serveur god-master centralisateur en DMZ
https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cnames-shall-we/
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par gouttegd (site web personnel) . Évalué à 7.
Donc tu es bien content de trouver Let’s Encrypt pour économiser 400 boules par an, mais parce que ça ne correspond pas exactement à tes besoins, tu ne rates pas la moindre occasion de cracher ta haine sur ce projet qui te pourrit la vie.
Plus haut tu dis carrément qu’il faut « taper sur Let’s Encrypt » pour avoir ce qu’il te faut (gratuitement bien sûr — payer pour un service, non mais et puis quoi encore)…
Hé ho, tu sais quand même que Let’s Encrypt ne te doit rien du tout, Môssieur le crypto-terroriste individuel auto-radicalisé qui monte des usine-à-gaz mais qui trouve
openssl reqtrop compliqué à utiliser ?[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par EauFroide . Évalué à -1. Dernière modification le 22 septembre 2016 à 21:46.
Let's encrypt ne s'est pas annoncé comme le remplaçant des arnaqueurs qui vendent des certificat TLS signé contre la peau du cul, non Let's encrypt s'est annoncé comme le grand sauveur de l'humanité qui va faire disparaître les certificats auto signé (et faire diminuer le prix des arnaqueurs).
Pas de chance son mécanisme est trop compliqué pour l'utilisateur lambda qui veut se faire auto héberger son blog ou un owncloud.
Pire il est tout simplement incompatible avec l'auto hébergement, malgré que let's encrypt vise ce publique cible. (ben oui, les sites de e-commerce n'utilisent pas d'auto signé…)
J'ai lu plusieurs de ses articles, il donne son avis posément, haine est un bien grand mot qui pourrait plus tôt définir se que je penses de TLS et des navigateurs qui font peur inutilement aux users et fou une merde pas possible en cross network au point que je rêve de forker firefox.
mozzila google et co veulent nous (users d'auto signé) forcer à signer nos certificat. Let's encrypt rentre dans cette logique (je tapais mozzila au moins une fois par semaine sur les réseaux sociaux a cause de ses alertes de sécu, et j'étais pas le seul, let's encrypt a détourné la cible des clash)
On ne peut donc pas critiquer quelque chose de gratuit, surtout si ce quelque chose ne possède pas d’alternative (et qu'il est imposé)?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Mais non. C'est trop compliqué pour l'utilisateur qui veut héberger son blog sur un système distribué et redondant pour avoir une haute disponibilité. Or ça, excuse-moi mais c'est tout sauf un utilisateur lambda. Et accessoirement, ce n'est pas de l'auto-hébergement, à moins d'avoir plusieurs maisons.
Je ne devais pas être au courant de ce détail, c'est pour ça que j'ai pu réussir à l'utiliser. Et sans problème, je dois dire.
S'il ne possède pas d'alternative, ce n'est pas leur faute, c'est seulement que personne n'en a proposé. Au boulot, donc.
Décidément, c'est une manie…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par EauFroide . Évalué à -1. Dernière modification le 23 septembre 2016 à 14:10.
Le problème apparaît aussi avec un seul serveur dans une seule maison … J'ai déjà pas mal galéré et j'ai pas encore réussi a automatiser let's encrypt (je suis fort probablement noob sur ce point, mais les gens que j'aide a monter leur owncloud sont encore plus noob que moi donc encore plus largué).
Cas de figure :
Utilisateur simple, tu as ton petiot VHOST simple (port 80 et 443 ouvert et un seul certificat TLS, celui de Let's Encrypt) pour ton owncloud. Admettons que tu veuilles faire ton montage DAVFS2 :
Depuis l'extérieur (de chez toi) :
- https://www.monDomaine.be ça fonctionne (note que j'ai pas vérifié si ça continue de fonctionner après un renouvellement)
Depuis l'Intérieur (LAN)
- tu retentes comme en WAN avec https://www.monDomaine.be mais la le routeur de ton FAI a beaucoup de chance de ne pas être compatible hairpinning, si tu peux le changer par un autre (ce qui n'est pas mon cas!), t'as bien de la chance
-donc tu veux que sa fonctionne quand même alors tu passe par https://adresseIPDuServeur mais comme le certificat n'est pas prévu pour ce hostname, il est traité par le logiciel comme un auto-signé (quand il va changer dans 90 jours, faudra tout recommencer)
Depuis Tor
- comme pour le lan, ton certificat n'étant pas prévu pour ce hostname, il est traité comme un auto signé, quand il changera hop tu peux tout recommencer.
Donc pour que ton montage DAVFS2 fonctionne sans devoir le refaire tout les nonantes jours, t'es obligé de repasser sur un auto signé ou de passer par http sans TLS (se qui, par sécurité, nécessite de remplacer par autre chose (Tor Hidden Service, SSH tunneling))
On pourrait rétorquer : t'as qu'a utiliser un auto signé pour tout sauf pour le WAN mais ca signifie complexifier le VHOST puis autant utiliser de l'auto signé partout a ce moment là.
Faut retenir qu'un serveur chez OVH c'est facile a gérer : un seul hostname, DMZ; un serveur auto-hébergé est face a plein de contraintes (multi hostname, hairpinning, NAT, IPv4/IPv6).
Quel est donc ta solution donc pour que mon montage DAVFS2 ne casse pas à chaque renouvellement ? Je suis ouvert à toute astuce.
Firefox, safari, chrome: ils empêchent tous l'utilisateur moyen d'avoir une expérience correct sur un site auto-hébergé utilisant des certificats auto signés. En auto signé je me fais souvent harceler par des users qui disent "ne pas savoir accéder" à mon site (ils trouvent pas le bouton habilement dissimulé par les navigateurs et ne comprennent pas le principe de l'exception de sécu).
Envoyer mes users harceler mozzila sur facebook/twitter n'a pas encore d'effet (ils sont pas assez nombreux) donc je me fais imposer soit la censure, soit Let's Encrypt.
Note : je rajouterai que TLS utilise un mécanisme très similaire a SSH, et que SSH ne force pas à renouveler ses clés tout les 90 jours (si non ca cassera pas mal d'automate et de montage)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
donc tu passe en IPv6.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 2.
Si tu as un FAI qui te file une box sans hairpinning, je pense que IPv6 est aussi un mot de la langue étrangère pour lui…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par EauFroide . Évalué à 1. Dernière modification le 23 septembre 2016 à 15:05.
Question : en IPv6 le problème du hairpinning disparaîtra?
Question annexe : quand on sera en IPv6, comment je fais pour trouver l'adresse IP d'un raspberry pi fraîchement installé? (actuellement j'utilise nmap 192.168.1.2-254 en IPv4 local mais si j'ai bien compris ça ne fonctionnera plus en ipv6)
C'est encore plus compliqué que ça : quand j'ai fais mon tuto sur syncthing j'ai remarqué que mes deux machines test communiquaient en IPv6 (en local mais que pour synchting, je les contrôlais via SSH en IPv4 au même moment)), mais j'ai jamais réussi a joindre un site web en IPv6, ni a configurer une adresse IPv6 (en suivant un tuto sur linuxfr), et quand je tente de mettre a jour mon DDNS en lui spécifiant IPv6 au lieu d'IPv4 ça ne fonctionne pas.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Oui, puisqu'il n'y aura pas de NAT. Le nom de domaine de ton serveur résoudra sur son adresse IPv6, qui sera joignable depuis l'intérieur comme depuis l'extérieur.
C'est un peu hors sujet, parce que récupérer l'adresse d'un truc qu'on vient d'installer, c'est plutôt une question pour ceux qui ont fait la procédure d'installation. Tu peux toujours faire un nmap sur le sous-réseau IPv6, même si ça risque d'être un peu plus long. Il y a sans doute des outils plus appropriés ; personnellement, si un mDNS est installé sur cette nouvelle machine :
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Dans ce cas, tunnel. Avec SixXS par exemple.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par kna . Évalué à 4.
Si tu gères toi-même ta zone DNS, tu peux mettre en place des views pour que l'adresse renvoie l'IP LAN si tu la résoud depuis ton LAN et l'IP WAN si tu la résoud ailleurs.
Après oui, ça serait plus simple si les box des FAI géraient l'hairpinning. D'autant que ce n'est pas évident de gérer sa zone quand on est autohébergé, vu que la bonne pratique est d'avoir 2 serveurs dans des AS différents.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par EauFroide . Évalué à 1.
Je t'avoue que j'ai déjà songé à m’attaquer au DNS du réseau (le bidouiller ou le remplacer voir même a passer par du arp poisoning+etterfilter), limite ça pourrait être plus utile que l'hairpinning (qui, j'imagine, doit bugger si un client interroge le DNS quand il y a une coupure internet et que la box gérant le serveur DNS a été reboot).
On pourrait aussi imaginer un script qui modifie le fichier host (sur linux voir android) via regex s'il a détecté une mac address spécifique.
Mais sa représente encore du boulot ^ ^
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Encore une fois, il y a une solution simple (IPv6 et pas de NAT), et d'autres solutions compliquées, c'est au choix.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par EauFroide . Évalué à 1. Dernière modification le 26 septembre 2016 à 18:38.
IPv6 c'est l'opérateur qui décide, pas moi.
Note qu'IPv6 ne résous en rien le "le webservice doit pouvoir fonctionner même si couper d'internet (donc nom de domaine HS et pas moyen de mettre a jour le certificat)".
Pour l'instant c'est beaucoup de prises de tête pour peu de résultats (ne protège même pas d'un MITM d'un état sur l'hostname, juste utile pour se préserver des exit node tor corrompu par des pirates non étatiques).
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Mais libre à toi de choisir un fournisseur d'accès à Internet v6 à utiliser par-dessus ton accès à Internet v4. C'est à mon avis bien plus simple à mettre en place que du double NAT ou des vues DNS.
Comment ça nom de domaine HS ? Si tu as un de tes serveurs de nom chez toi, coupé d'accès à Internet, tu peux toujours résoudre tes noms. Pas les autres noms, mais les noms de ta zone DNS, si.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par kna . Évalué à 3.
Ou bien ton god master récupère la clé et le certificat sur Certbot Host, et la pousse sur les autres serveurs.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par kna . Évalué à 3.
Il manque juste un outil type ansible/puppet/chef/salt à ta liste.
Sinon, tu peux simplement gérer le TLS sur haproxy, et laisser les backends en HTTP (avec une interface sur un VLAN privé).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par kna . Évalué à 3.
Chezmoiçamarche™ quand je redirige HTTP vers HTTPS.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0.
Oui, mais ça nécessite HTTP actif. Tu ne peux pas passer le challenge avec du HTTPS only…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Framasky (site web personnel) . Évalué à 3.
Question très con : en quoi est-ce un pb d'avoir un HTTP actif ? S'il redirige tout vers HTTPS ?
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 3. Dernière modification le 23 septembre 2016 à 00:51.
Parce que la 1ère requête HTTP avant la redirection contient déjà les données POST par exemple. Et peut donc suffire à leaker des données pas cool.
Et que ça permet des attaques marrantes comme SSLStrip par exemple (tu interceptes le « 302 redirect » de la requête HTTP, tu récupères le contenu HTTPS, tu remplaces tous les https:// par http:// dans le contenu que toi tu as reçu, tu envoies un « 200 found » avec le contenu modifié, tu recommences avec la prochaine requête qui sera du coup en http://, etc).
Il y a même des attaques plus marrantes qui laissent le joli cadena vert dans la barre d’adresse (avec du AJAX qui recharge toute la page en HTTP plutôt que de faire la vraie requête GET/POST) !
http://www.crack-wifi.com/tutoriel-sslstrip-hijacking-ssl-mitm-https.php
La désactivation complète de HTTP est par exemple préconisée pour les API par Mozilla.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Framasky (site web personnel) . Évalué à 2.
Ok, merci :-)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par GG (site web personnel) . Évalué à 3.
Pour générer le certificat pour LE, il faut effectivement du http.
Comme je fais gérer mes certificats par une machine virtuelle différente des serveurs web, je suis obligé de créer un cas particulier de redirection basée sur un motif particulier de la requête ( .well-known/acme-challenge ) pour l'envoyer de manière exceptionnelle sur ma VM pour LE.
J'ai donc des sites qui fonctionnent en http et https, parce que pour d'autres raisons techniques je dois laisser ça ainsi, pour le moment.
J'ai d'autres sites qui ne sont accessibles que par https. Le renouvellement reste automatique.
Comme tu le dis, le fait d'avoir un site visible en http ET https pose un gros problème, pas que à cause de la possibilité de faire du ssltrip.
Mais, le renouvellement/création du certificat par http n'empêche pas de forcer l'utilisation des sites web en https tout le temps. Il faut simplement créer une exception basée sur le motif de l'url de validation : .well-known/acme-challenge
Moi aussi j'ai un reverse-proxy, des vm etc. Alors oui, utiliser LE dans ces conditions c'est plus délicat, mais c'est plus simple qu'avec les autres certificats.
Pour ceux qui font de l'hébergement à domicile, je ne vois pas quel est le problème.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 2.
À partir du moment où tu as du HTTP actif, SSLStrip est possible, ou du leak de données involontaires.
Que tu y mettes des limitations logicielles derrière ne change rien, au niveau réseau des données peuvent continuer à passer en clair avant de se prendre un 3xx ou un 4xx.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par GG (site web personnel) . Évalué à 3.
On est bien d'accord. C'est pour ça qu'une partie de mes sites sont accessibles par les deux modes (http ET https). L'autre partie n'étant accessible que par un seul mode (http OU https, selon la configuration).
Une situation temporaire, qui n'est pas liée à Let's encrypt dans mon cas.
Les requêtes de création/renouvellement n'atteignant pas le serveur web, mais uniquement la VM en charge de LE.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 22 septembre 2016 à 22:17.
Les CGUs ne doivent pas être codées en dur dans les clients ACME: le
dictionnarypermet de connaître les CGUs en cours, il y a un Link aussi dans les réponses HTTP qui peut être renseigné par le serveur. Si l'utilisateur renseigne son e-mail lors de la création de son compte ACME, il pourrait aussi être averti en avance.Le passage de X1 vers X3 s'est passé durant la phase bêta si je ne me trompe pas.
Le challenge DNS permet de ne pas toucher à son serveur HTTP/HTTPS et permet une grande flexibilité dans son infrastructure. Par contre, il faut maîtriser un minimum son serveur DNS.
IPv6… Comment dire… Je suis très enthousiaste face à cette technologie, mais elle n'est pas évidente à utiliser pour des services d'authentification à mon avis. En plus, si ça a été activé récemment comme je l'ai lu dans les autres commentaires, ça veut dire qu'ils ont pu mettre en place cette infrastructure en moins d'une année après la sortie officielle de leur service (la version non beta donc). Moi je leur dit plutôt chapeau !
Ah et si leurs services ne te plaisent pas les spécifications sont ouvertes et leurs logiciels serveurs aussi il me semble…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 22 septembre 2016 à 22:55.
En pratique, c’est le cas… https://forum.cozy.io/t/du-fonctionnement-de-lets-encrypt-dans-cozy-et-des-certificats/2787/5?u=aeris
C’était déjà hors béta. Et LE a annoncé que ça pouvait arriver n’importe quand (s’ils doivent utiliser leur intermédiaire de secours par exemple).
Et c’est incompatible avec DNSSec. Sauf comme déjà mentionner à devoir filer les clefs privées de son serveurs DNSSec à certbot…
Et TLS-SNI-01 impose d’utiliser un serveur HTTPd custom…
Sauf que non, puisque du coup je ne pourrais pas être intégré aux navigateurs…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Je n'ai eu aucun problèmes avec DNSSec et mon client acme-dns-tiny. Quels problèmes as-tu ?
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1.
De devoir filer les clefs de mon shadow master DNSSec à un truc qui va gérer les certificats. Donc de casser la sécurité apportée par DANE/TLSA qui impose d’avoir 2 chaînes bien distinctes (DANE/TLSA d’un côté, le certificat de l’autre).
Mélanger les 2 fait qu’un attaquant qui prendrait possession de la clef privée ou du certificat aurait tout le loisir de changer au passage l’empreinte TLSA… Et donc rendrait inutile DANE/TLSA…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 22 septembre 2016 à 23:20.
Donc le problème ne vient pas de DNSSec, ça me rassure :)
Et non, car si tu configures ton serveur DNS correctement, le script acme-dns-tiny ne pourra mettre à jour que les entrées TXT des sous-domaines préfixés par
_acme-challenge.. Tout ceci grâce à une bonne configuration de la mise à jour DNS par des clés TSIG qui ne pourront toucher qu'un nombre restreint d'enregistrements.En plus, les clients ACME n'ont absolument pas besoin d'avoir la clé privée à disposition: seul le CSR est nécessaire et la clé ACME de ton compte enregistré chez LE (ou un autre CA d'ailleurs…).
Donc pour tes problèmes, ce challenge est valide: le client ne connaît pas la clé privée TLS et il ne peut pas modifier les entrées DANE/TLSA, seulement les TXT sur certains sous-domaines.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0.
Euh si quand même. Cf ma 2nde réponse :D
Je ne vois pas comment tu peux faire du DNS-01 challenge avec DNSSec activé. Les dynamic updates ne fonctionnent pas avec DNSSec.
Je parlais plutôt des KSK et ZSK DNSSec. Pas envie de les filer à un truc en DMZ, qui fait du web, online 100% du temps, etc
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1.
Et tu ne peux pas restreindre les dynamic updates à juste les entrées de challenge. Tu as nécessairement besoin de pouvoir mettre à jour les entrées TLSA dans le cas d’un changement de certificat justement :D
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Ce que tu peux faire bien plus tard. Le challenge te permet de récupérer un certificat, il ne t'impose pas de l'installer dans la seconde par le même processus. Il suffit de mettre à disposition le certificat à un autre service qui sera capable de mettre à jour ton DANE…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0.
Oui sauf que le « bien plus tard » en terme de TLSA d’habitude, c’est plutôt de l’ordre de l’année :P
Je ne touche pas à mon shadow master tous les matins… Sécurité = stabilité !
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0.
D’ailleurs, je ne vois même pas comment DNS-01 peut être compatible avec DNSSec, en tout cas si on utilise OpenDNSSec.
OpenDNSSec ne supportant pas les mises-à-jour dynamiques, ça imposerait de réécrire tout le fichier de zone pour le faire signer par OpenDNSSec (qui mettra à jour le master Bind).
Ça ne me semble compatible qu’avec les serveurs DNS master + DNSSec, pas ceux séparant les 2 concepts (par exemple Bind9 + OpenDNSSec)
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Bind9 est capable de mettre à jour dynamiquement les fichiers de zones pour avoir une configuration DNSSEC dynamique justement (voir le guide ARM de bind9 pour les détails).
Quand tu utilises cette fonctionnalité, tes fichiers de zone sont constament mis à jour par bind9.
Si tu as bessoin d'un contrôle manuel, tu peux lui demander de geler les modifications (rndc freeze) le temps de faire tes modifications manuelles puis de le dégeler (rndc thaw) pour lui rendre la main.
Comme bind9 gère déjà tes fichiers de zone dynamiquement, il est assez aisé d'ajouter la mise à jour dynamique des ressources par authentification TSIG.
Comme ça la boucle est bouclée et tout peut fonctionner de manière automatique pour ce qui concerne DNSSEC.
Après, je ne me suis pas encore penché sur DANE/TLSA, car ce sont des concepts complexes et dangereux à mettre en place. Personnellement, je préfère avoir des certificats Let's Encrypt complètement automatiquement mise à jour pour l'instant.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 22 septembre 2016 à 23:47.
Désolé, le message ci-dessus était hors sujet avec le commentaire parent.
Ok, alors DNS-01 peut facilement fonctionner avec un Bind9 master qui gère DNSSEC.
Il est plus difficile de le mettre en place sur un serveur DNS master qui ne gère pas DNSSEC.
Ça me paraît évident, puisque l'architecture est de base plus compliquée.
Par contre, ça n'invalide pas la procédure de vérification DNS-01 pour autant, puisqu'elle est utilisable pour identifier si un propriétaire possède bien une zone DNS.
Je crois vraiment que ton problème est que ton architecture réseau est bien trop compliquée pour pouvoir facilement automatiser la génération de certificats. Ce n'est pas à Let's Encrypt de prendre en charge ton infrastructure dans ses services. Ils proposent un moyen simple et standard pour la plus part des gens auto-hébergés et même pour ceux hébergés sur des environnements mutualisés chez certains fournisseurs.
Si tu veux profiter de l'automatisation proposée par ACME, ce sera à toi d'adapter tes configurations ou ton infrastructure. Malheureusement, j'ai l'impression que l'on ne peut pas tout avoir simplement (surtout que DANE et HPKP ne peuvent pas être mis en place, ni mis à jours, sur un coup de tête).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à -1.
Et donc LE aura fait exactement comme l’IETF avec HTTP/2 : s’asseoir sur toute la stack TLS en la restreignant à simplement une clef et un certificat…
HPKP, TLSA, DNSSec ou même moins violent un simple reverse-proxy ou de la virtualisation, et ça ne fonctionne plus.
Quand on se place en pourfendeur du certificat auto-signé, ça pique un peu quand même… Surtout quand un simple changement de renouvellement à 1 an réglerait tous les problèmes…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Ca n'a rien à voir: la procédure d'authentification est valide, c'est toi qui te met des batons dans les roues. Ce n'est pas la faute à LE si tu es incapable d'ajouter 1 ressource DNS dans ta zone facilement.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 23 septembre 2016 à 00:25.
C’est parfaitement de la faute à LE.
C’est une autorité de certification X.509, elle se doit donc de pouvoir respecter l’ensemble de la stack X.509. En particulier HPKP et TLSA.
C’est actuellement impossible, en tout cas simplement et de manière sécurisée.
C’est un non-sens total de la part d’une CA d’interdire les validations HTTPS ou de foutre des bâtons dans les roues de tout ceux qui veulent monter une infra sécurisée et fiable. Surtout quand on connaît la modification ultra simple (je ne la demande même pas par défaut dans certbot) qui le permettrait.
Ou sinon on est juste « yet another plain old CA », dont je me ferais une joie de me débarrasser dès l’émergence d’une solution alternative (coucou DANE-TA/EE !).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
X.509 existait n'a rien à voir avec HPKP et DANE… Ce sont juste des systèmes de certificats, c'est bien toi qui décide de lrs épinglés à la place de tes clés.
ACME ne t'oblige pas d'utiliser HTTP/HTTPS pour t'authentifier, tu peux utiliser DNS et d'autres moyens sont proposés également.
Le protocole ACME n'oblige pas de tout automatiser: tu peux demander un nouveau certificat aujourd'hui, l'installer dans plusieurs jours. Le délais de 60 jours dont tu parles plus haut n'existe pas: il faudrait le faire avant le dernier jour de validité, mais rien ne t'interdit de le faire le 85eme jour.
Il faut que tu acceptes qu'ACME est capable de répondre aux besoins de beaucoup de mondes, mais pas à tes besoins très spécifiques (ton infrastructure ne correspond pas aux plus générales visées par LE).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0.
Et comme signalé plus haut, beaucoup d’auto-hébergés n’utilisent pas LE pour cause de trop grande complexité…
Le cas d’usage standard de LE est trop restrictif pour être utilisable en pratique (mono-serveur, mono-domaine). Dès que tu dépasses de ce niveau (ce qui est en pratique le cas dès que tu touches un peu à l’auto-hébergement), les ressources nécessaires pour l’automatisation te sont hors de portée.
Je le vois bien avec Cozy, on reçoit ÉNORMÉMENT de retours négatifs (trop complexe, ne fonctionne pas, pas clair…) des utilisateurs. https://forum.cozy.io/search?q=let’s%20encrypt
Et ceux qui s’y mettent réellement tombent rapidement sur les os mentionnés un peu partout ici et au fur et à mesure qu’ils vont s’amuser avec leur infra et se semi-professionalisé (reverse proxy, virtualisation, puis HPKP, puis TLSA).
Mais ils seront bridés car pas les ressources humaines et temporelles pour développer toutes les verrues nécessaires un peu partout (httpd, dns…) à une automatisation à 60 jours.
Les grands gagnants dans l’affaire ont été les fournisseurs d’offres mutualisées et les vrais professionnels qui ont pu enfin délivrer du certificat en masse et qui ont les infras humaines, matérielles, temporelles et financières pour gérer l’automatisation (en se foutant au passage de HPKP et de TLSA) via le développement d’outillage ad-hoc pour leur infrastructure.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
Je suis d'accord que ton infrastructure a une "trop grande complexité".
J'aimerai bien comprendre en quoi ce processus est compliqué:
Tout en sachant que:
Mono-serveur et mono-domaine correspond à toutes les personnes qui utilisent un raspberry pi pour s'auto-héberger, à beaucoup de personnes qui utilisent un petit hébergement mutualisé,…
Non, voire ci-dessus. Pourquoi j'aurai 2 serveurs dans mon appartement s'ils sont distants de 2 mètres et qu'ils partagent la même adresse IPv4 publique ? Combien d'appartements différents as-tu ? Quelle est ta définition d'auto-hébergé ?
"ÉNORMÉMENT == 10 posts ", franchement ? Je comprends mieux pourquoi "mon cas personnelle == tous les auto-hébergés" :D Et oui, la gestion des certificats requiert beaucoup de connaissances, surtout si tu souhaites te mettre des bâtons dans les roues avec HPKP/DANE et une infrastructure réseau trop complexe.
Je m'y suis mis réellement et je n'ai pas eu tout ces problèmes. C'est HPKP/DANE qui te demandent d'être presque professionnalisé, pas ACME. D'ailleurs, devine pourquoi ces 2 concepts sont peu répandus et pourquoi ACME est très utilisé ?
Non, les grands gagnants sont tous les gens qui peuvent enfin utiliser un formulaire de contact sur de petits sites web sans avoir peur de diffuser plein d'informations en claire sur Internet.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
À noter qu'avec Let's Encrypt, s'il est nécessaire de changer de certificat au moins tous les 90 jours, et qu'il est en pratique recommandé de le faire tous les 2 mois, il n'est nullement nécessaire de changer aussi souvent de clef. Le client officiel, Certbot, génère effectivement une nouvelle clef à chaque fois, mais ce n'est pas obligatoire, et d'autres implémentations permettent de renouveler les certificats existants à la place.
Compte tenu de ceci, si veut limiter la fréquence des changements, il est pertinent de procéder à des renouvellements sans changer de clef. Si on veut également mettre en place HPKP et DANE, on peut alors épingler non pas le certificat, qui changera tous les deux ou trois mois, mais la clef publique, qui demeurera tant qu'on ne l'aura pas manuellement changée.
Ainsi, si la récupération des certificats a lieu sur une machine donnée, celle-ci n'a plus besoin de pouvoir mettre à jour des enregistrements DNS, seulement de fournir les certificats renouvelés aux serveurs qui les utiliseront.
En suivant la recommandation de renouvellement tous le deux mois, cela laisse une marge d'un mois pour que les serveurs les récupèrent, ce qui peut très bien se faire de façon tirée, sans aucune synchronisation. Personnellement, je recommanderais d'aller chercher les éventuelles mises à jour toutes les semaines.
Maintenant, on peut avoir des raisons personnelles pour ne pas vouloir telle ou telle étape de ce système, par exemple parce qu'on n'aime pas PKIX-EE ou DANE-EE avec SPKI (cf. http://www.bortzmeyer.org/7218.html), mais ce sont là des contraintes qu'on s'impose, et en aucun cas des raisons de blâmer Let's Encrypt.
En clair, si tu veux changer de clef à chaque fois, et utiliser HPKP et DANE, oui, il va falloir mettre à jour des trucs qui, sans cela, auraient pu être laissés, mais c'est ton choix, donc ton problème. Et si tu veux épingler, non pas la clef, mais le certificat ou l'AC, il va aussi falloir mettre à jour des trucs, mais encore une fois, c'est ton choix, donc ton problème, pas celui de Let's Encrypt.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 23 septembre 2016 à 14:10.
Je t’arrêtes immédiatement à partir d’ici.
Mon DNS a DNSSec activé, DNSSec étant géré avec OpenDNSSec sur un shadow master contenant les clefs privées de signature de ma zone (ce qui est la configuration recommandée quand on gère du DNSSec).
Ma zone DNS n’est donc pas modifiable automatiquement, il faut nécessairement une intervention humaine.
Et sur le point 3, tu as oublié :
Qui pose aussi le problème de l’accès au shadow master DNSSec, mais aussi casserait l’intérêt de TLSA si fait automatiquement (l’intérêt étant d’avoir justement 2 chemins bien distinct entre la gestion du certificat et celle du DNS).
Ainsi que celui du rollover de l’empreintre HPKP qui doit être faite au moins 60j avant le véritable changement de certificat (et nécessite d’avoir déjà le certificat à disposition pour le calcul de l’empreinte).
En bref, ton processus est parfaitement faisable si tu réduis l’environnement HTTPS à uniquement clef + certificat.
Dès que tu y mets les autres technos associées (DNSSec, HPKP & TLSA), c’est mort pour une automatisation et encore pire à 60j.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Non, je n'ai rien oublié, je t'ai décrit ce que le protocole ACME te demande de faire pour avoir une certification sans utiliser HTTP.
HPKP et DANE n'entrent pas dans ce processus et c'est normal: pour créer un certificat tu dois juste avoir une paire de clés, un nom de domaine et une autorité reconnue.
C'est toi qui choisit de lier ces 3 concepts, c'est ton problème.
Pour dnnsec, c'est la même remarque: tu as choisit de rendre manuel le changement de ressources DNS, donc c'est ton problème.
ACME fait une chose et le fait très bien: il permet de vérifier que tu possèdes un nom de domaine et te retourne un certificat si c'est le cas.
Certes, le client le plus connu fait déjà un peu plus en gérant lui-même les clés privées, mais ça n'a rien à voire avec un problème sur le protocole ACME.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 0.
HPKP et DANE font parti de la stack X.509 et assimilé. DNSSec devrait être déployé partout (98% de MitM mail si tu es en Turquie à cause de ce manque…)
Une CA doit permettre de les respecter.
Sinon c’est juste une « yet another plain old CA ».
Euh non, c’est ce qu’on appelle une stack TLS correcte en 2016.
HPKP devient limite critique vu les attaques aujourd’hui, TLSA arrivera derrière.
Quand tu sais que Symantec, root-CA, vient d’acquérir BlueCoat, vendeur de matos DPI, HPKP et TLSA, ce ne sont clairement plus des jouets mais ce qui peut faire la différence entre la vie privée ou pas…
Je n’ai pas choisi. C’est l’état de l’art d’un serveur OpenDNSSec d’avoir un shadow master hors DMZ. Et ça casse tout l’intérêt de DNSSec si tes clefs sont dispos sur une machine accessible depuis le net.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
N'importe quoi. Ça permet certaines attaques qui sans cela seraient impossibles, mais ça conserve au contraire une bonne partie de l'intérêt de DNSSEC, à savoir de rendre la falsification de réponses DNS beaucoup plus difficile. Sans DNSSEC par exemple, contrôler un bout du lien entre le client et un serveur de nom faisant autorité pour une zone donnée suffit à changer les réponses pour ce qu'on veut. Avec DNSSEC, ce n'est plus possible, il faut avoir accès à la clef de signature de la zone.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 26 septembre 2016 à 12:52.
Eh bien, tout va bien alors, Let's Encrypt est une CA moderne, parce qu'ils ne posent aucun problème avec HPKP et DANE. Avec HPKP, c'est la clef publique qui est épinglée. Avec DANE, tu as le choix, donc tu peux épingler la clef publique. Il suffit, tous les 90 jours, de changer, non pas de clef et de certificat, mais seulement de renouveler le certificat avec la même clef, et ça roule, rien à changer pour HPKP ni DANE.
Ah, c'est vrai, ta religion t'impose d'épingler le certificat et de changer de clef tous les 90 jours, c'est ça ?
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 1.
Mais des certificats valides 90j n’incitent pas plus à la sécurité, au contraire. C’est incompatible avec la plupart des autres protections X.509 existantes. La sécurité préfère largement les situations stables à celles instables, ne serait-ce que parce que la confiance est difficile dans une situation dynamique.
Un certificat de 1 an permet BEAUCOUP plus de sécurité que ce que LE propose (rien que par le fait que je peux transmettre son empreinte à un correspondant sans craindre qu’elle ne soit plus valide demain).
Certes, mais la différence est énorme entre « j’ai une procédure de 2 min automatique de renouvellement en cas de compromission » et « je l’applique violamment tous les 60j, on ne sait jamais ».
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par EauFroide . Évalué à 1.
C'est exactement se qu'il se passe avec les montages DAVFS2 qui nécessite de télécharger le certificat : si tu passes par une connexion non WAN (par exemple tu fais ton montage en LAN, over Tor ou over SSH), le changement de certificat va tout casser tout les nonantes jours, rendant inutilisable l'application cliente chez un "non initié". (comprendre grand papy va perdre l'accès a son album photo partagé tout les mois et demi jusqu'à ce que tu reviennes accepter le changement de certificat)
Ma solution est de tout passer par proxy SSH ou Tor sans passer par TLS purement et simplement. (j'avais restreint l'accès en https uniquement lorsque j'avais un auto signé, depuis que je test LE j'ai du ré-activer l'accès http).
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par GG (site web personnel) . Évalué à 3. Dernière modification le 23 septembre 2016 à 11:51.
D'ailleurs, qu'est ce qui techniquement pose problème à LE d'utiliser https pour le renouvellement d'un certificat, vu que celui en cours est encore valide?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 23 septembre 2016 à 12:02.
Les admins débiles et les environnements multi-tenants.
https://www.ietf.org/mail-archive/web/acme/current/msg00524.html
En gros, ils prêchent l’automatisation à 100% mais refusent la certification via HTTPS pour cause d’admin incompétents incapables de gérer correctement leur vhost par défaut (et du coup le 1er nom de domaine dans l’ordre lexicographique est capable de générer des certificats pour tous les autres domaines multi-tenants…).
D’ailleurs je n’ai toujours pas compris pourquoi ils ont ciblé HTTPS uniquement, alors que HTTP pose exactement le même problème (la seule piste de réponse que j’ai pu avoir est qu’il y aurait encore plus d’admins incompétents en HTTPS qu’en HTTP).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par EauFroide . Évalué à 1.
Si j'ai du ré-activer http sans TLS c'est pas pour le renouvellement (que toute façon j'ai pas encore réussi a automatiser) mais car Let's Encrypt casse les montages DAVFS2 de mes users tout les 90j et donc j'ai du remplacer par autre chose (SSH tunneling qui renvoi vers le http sans TLS, le tout over Tor Hidden Service comme ça sa règle d'avance tout problème lié au nom de domaine).
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# Merci
Posté par David . Évalué à 2.
Merci pour vos retours.
Conclusion : pas de raison de ne pas s'y mettre.
J'ai appris de nouveaux sigles à étudier :
HSTS
HPKP
DANE
TLSA
DANE-EE
DANE-TA
PKIX-TA/EE
[^] # Re: Merci
Posté par n0wic . Évalué à -10. Dernière modification le 23 septembre 2016 à 13:09.
Quand tu auras tout étudié tu pourras sortir
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.