DNSSec impose un roulement régulier de ta clef de signature.
En fait de tes 3 clefs de signature :
la signature de zone, renouvelée toutes les 2h
la ZSK, renouvelé tous les 90j, qui signe ta zone DNS
la KSK, renouvelé 1× par an
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).
Demander des challenges DNS pour son CSR au serveur ACME
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é :
modifier les empreintes TLSA (DNS) et HPKP (HTTPd) des certificats renouvelés
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.
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).
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
À 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.
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).
Un des buts de Let's Encrypt étant de favoriser l'automatisation, ça n'arrivera pas.
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)…
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.
Je l’aurais fait sans soucis si je n’avais pas besoin de ce f***** audit pour être intégré aux navigateurs.
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.
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.
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.
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é !
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 !).
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…
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
Donc le problème ne vient pas de DNSSec, ça me rassure :)
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.
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…).
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
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)
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…
Les CGUs ne doivent pas être codées en dur dans les clients ACME: le dictionnary permet 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.
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).
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.
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…
Ah et si leurs services ne te plaisent pas les spécifications sont ouvertes et leurs logiciels serveurs aussi il me semble…
Sauf que non, puisque du coup je ne pourrais pas être intégré aux navigateurs…
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…
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
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é.
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.
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à.
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…
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.
Je n’ai jamais dis que LE devait automatiser pour moi.
Je dis simplement que les choix techniques (90j de renew en particulier, mais aussi le HTTP-only pour ACME) de LE m’empèche d’automatiser sans mettre DRASTIQUEMENT ma sécurité à genou.
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.
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).
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.
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.
Faudrait savoir, en quoi TLSA permet de s’affranchir des CA moisies si ce n’est « implémenté nulle part » ?
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.
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.
Ç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.
Ah ouais quand même. Donc c’est trop dur pour un administrateur système d’invoquer openssl req correctement, 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.
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).
$ openssl req -config req.cfg -new -key $keydir/mykey.pem -outform DER -out $outdir/req.csr
[… too much snip…]
Vas-y, rigole dans ton coin. Moi ça fait déjà quelques messages que tu ne me fais plus rire.
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).
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.
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.)
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.
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…)
Quant à DANE, je ne vois pas en quoi Let's Encrypt empêche ou complique excessivement quoi que ce soit.
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…
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) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 1.
Je n’aurais pas mieux dis :)
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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: 90 jours, et alors?
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. É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.