Adrien Dorsaz a écrit 958 commentaires

Et comme signalé plus haut, beaucoup d’auto-hébergés n’utilisent pas LE pour cause de trop grande complexité…

Je suis d'accord que ton infrastructure a une "trop grande complexité".

J'aimerai bien comprendre en quoi ce processus est compliqué:

1. A la main, sur une machine à l'abris, 1 fois (sauf si tes clés sont corrompues):
   1. Créer 2 paires de clés privées / publiques
   2. Créer 1 CSR pour 1 la première paire de clés
2. De manière automatisable (et régulièrement au moins tous les 89 jours):
   1. S'inscrire sur un serveur ACME avec la seconde paire de clé crée (pas celle du CSR!)
   2. Demander des challenges DNS pour son CSR au serveur ACME
   3. Recevoir les challenges et ajouter 1 ressource TXT par domaine avec un identifiant qui peut être calculé par toi et par le serveur ACME
   4. Optionnel: attendre que les mises à jour DNS soient effectives
   5. Demander au serveur ACME de vérifier les challenges sur tes serveurs DNS
   6. Récupérer ton certificat quand les challenges sont tous validés
   7. Récupérer le certificat intermédiaire qui a généré ton certificat
3. De nouveau à la main sur les serveurs qui ont besoin et de temps en temps (pas de synchronisation nécessaire avec l'étape précédente):
   1. Aller récupérer les nouveaux certificats
   2. Installer les certificats là où les services les chercheront
   3. Redémarrer les services utilisant TLS

Tout en sachant que:

• les étapes principales peuvent être faites avec de grand décalages de temps.
• le renouvellement des certificats, seul l'étape 2 et 3 doivent être faites.
• si un épinglage est nécessaire, il suffit de créer une paire de clé publique/privée en plus et d'épingler les clés. Dans ce cas, le renouvellement des certificats ne pose aucun problème pour HKPK et DNSSEC et en plus tu utilisent ces 2 systèmes en plus de la hiérarchie des CAs.
• si pour la partie 2 tu ne veux/peux pas utiliser de serveur DNS, d'autres types de challenges existent avec d'autres pré-requis (comme un challenge qui nécessite HTTP)

Le cas d’usage standard de LE est trop restrictif pour être utilisable en pratique (mono-serveur, mono-domaine).

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é,…

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)

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é ?

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

"É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.

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.

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é ?

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.

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.

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).

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…

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.

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).

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.

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…

Donc le problème ne vient pas de DNSSec, ça me rassure :)

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…

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.

Je n'ai eu aucun problèmes avec DNSSec et mon client acme-dns-tiny. Quels problèmes as-tu ?

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.

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…

Hello

C'est une bonne remarque.
Sur mon mobile les titres sont souvent sur 2 lignes sur les 3/4 de la partie gauche de l'écran. Sur le dernier quart à droite et sur la hauteur d'une ligne je vois la note du journal.

Je pense qu'en mobile on pourrait profiter d'utiliser le blanc qui se trouve aux 3/4 à droite sur la deuxième ligne pour afficher un signet (comme celui de la notation) avec un résumé du style "nombre de non lus / nombres de commentaires".

Je pense à un signet plus discret que celui de la notation et avec une taille de police plus petite pour que 999/999 passe sur 1 ligne.

J'essaierai ce soir de faire un mockup pour mieux m'expliquer :)

Paypal peut être utilisé sans carte de crédit. Pour ça, il faut ouvrir un compte sur leur site et faire un versement depuis ta banque sur le compte paypal avec les références reçues. Le désavantage est que tu perds plusieurs jours pour que le virement soie pris en compte.

Par contre, tu peux faire des payements sur Internet sans cartes de crédit et sans donner les clés de ses comptes bancaires à PayPal.

Oups: s/autout d'elle/autour d'elle/
Sur la page citée aussi ;)

J'aime bien l'idée d'améliorer Internet :)

Je vois plusieurs services qui pourraient être intéressant et qui pourraient nécessiter pas mal de ressources:

• serveur de tuiles pour OpenStreetMap
• noeud de recherche/cache pour les moteurs de recherches P2P (p.ex. Yacy, archive.org)
• intégration dans des infrastructures nécessitant beaucoup de ressources (j'imagine par exemple Wikipédia, Archive.org, …)
• services de build automatisés pour les projets d'envergures (Debian, Fedora, …)
• service de stockage vidéo / multimédias (gobelin, gitlab, torrent, …)

Après, pour tout ceci, avoir les machines c'est bien, mais la gestion des mises à jour et de chacun des services sera certainement très chronophage.

Je pense qu'il serait intéressant de discuter avec ce genres de projets pour voir s'ils souhaitent investir leur temps dans le maintient de service sur ces machines.

Malheureusement, comme dit plus haut, ce sera juste un moyen d'absorber un peu plus ces déchets sans être une solution pour en diminuer la quantité.

Et sache qu’on attribue généralement à un mot des qualificatifs différents selon son genre grammatical, preuve que le genre des mots nous influence, qu’on le veuille ou non.

Alors j'aimerai bien connaître ces qualificatifs pour le français et l'allemand.

Je suis fracophone d'enfance, mais j'ai dû apprendre l'allemand, comme une bonne partie de la population suisse.

Comme j'ai de gros problèmes pour retenir les choses par cœur, ce genre de qualificatifs pourraient m'aider à me créer des règles pour savoir le genre des noms en allemand.

Pourrais-tu me donner ces qualificatifs pour le français ? Si tu y arrives, j'essaierai de trouver une correspondance avec l'allemand.

Par exemple, si en français, je dis "la soleil" à la place de "le soleil" quels sont ces qualificatifs cachés (quels changements dois-je comprendre) ? Ca pourrait m'aider à mettre en exergue les qualificatifs cachés germanophones qui déterminent que soleil est "die Sonne" et non pas "der Sonne".

Comme tu peux le voir dans les captures d'écran, l'exe contient un "VirtualBox Portable".

L'idée des applications portables est de pouvoir exécuter un logiciel sans avoir besoin de l'installer (juste copier le dossier du logiciel dans un répertoire).

Peut-être que Windows requiert des droits pour écrire dans le dossier Public de la capture d'écran (quoique, vu le nom, ça devrait jouer), mais c'est le seul moment où ce serait nécessaire.

Donc, à essayer avant de dire que ce post est menssongé…

Edit:

En plus, c'est bien indiqué dans l'aricle:

Nota: Si vous êtes dans une session avec des droits limités, le mot de passe administrateur vous sera demandé.

Donc même pas besoin d'essayer ;)

Du point de vue administrateur de forge, je préfère largement limiter au maximum les applications tierces qui viennent ajouter une couche par dessus la forge. Car à la moindre mise à jour de l'application ou de la forge, je risque de perdre l'interopérabilité des 2 outils (ce genre de conflits m'est arrivé fréquemment entre le trio Debian, Redmine et un plugin Redmine qui permettait de gérer git).

Alors que si c'est intégré directement dans le code source de l'application principale, la mise à jour de la forge engendrera moins de bugs. S'il y a un bug, il n'y a qu'une équipe à avertir et qui maitrisera tout le code.

Mon argument était pour opposer la liseuse aux smartphones et tablettes qui ont un écran rétro-éclairé.

Les avantages par rapport au papier, il en existe en effet des dizaines. Celui qui me convainc le plus est d’éviter de continuer la déforestation de la planète pour des livres qui finiront par prendre la poussière dans des bibliothèques.

En même temps, je ne vois pas trop comment systemd pourrait déterminer le moment opportun pour afficher le log ?

Imaginons, que ce soit dès que le processus est lancé: tu verras dans le log des lignes du genres "Starting service…." et tu ne verras pas qu'un peu plus tard le service n'arrive pas à atteindre certains fichiers. Là tu auras l'impression que systemd a menti car il a indiqué le status "OK", alors qu'en réalité le service a échoué.

En fait, le seul cas que je vois pour que systemd puisse t'afficher un retour est le cas où le processus ne peut pas être exécuté (lanceur introuvable par systemd par exemple) ou la configuration du service ne suit pas les attentes de systemd. Il me semble que dans ce cas, systemd renvoie bien des erreurs.

Le livre n'a pas besoin de rétro éclairage à ce que je sache…

Et justement, les liseuses électroniques non plus, grâce à l'encre électronique.

C'est d'ailleurs le "seul" intérêt d'acheter ces machines à la place d'une tablette ou d'un smartphone (l'écran est lisible sans rétro-éclairage et nécessite beaucoup moins d'énergie).

Tiens, la lecture rapide m'a fait lire « travailleuse ». D'ailleurs j'ai dû relire 2 fois ton commentaire pour le comprendre et je m'était dit qu'un féminin tout seul dans ces propos était étrange.

La méthode avec les points centrés bloque la lecture fluide et cette méthode échoue fasse à la lecture rapide… ce n'est pas très efficace.

Bah, s'il en faut au moins un, voici le GTA04.

C'est un téléphone de bidouilleur (tinkerphones, le nouveau nom de la communauté OpenPhoenux autour de cet engin et de quelques autres). Son bootloader est libre, compilable, remplaçable et peut gérer plusieurs OS sur une même carte uSD. Il est encore en cours de production (une dernière production est en cours ou va bientôt commencer, le temps que les composants soient en stock chez le fabricant).

Le constructeur fournit les moyens de modifier tous les logiciels. Il fournit lui-même une version en test de Replicant avec le blob binaire wifi. La communauté Replicant a elle-même une version sans blob binaire (excepté celui du GSM, comme d'habitude).

PS: dans ces téléphones bidouillables, il y a également le Neo900, mais je n'ai pas trop suivit où en était le projet et si Android sera utilisable avec.

Merci pour les retours.

En effet, je n'ai pas pensé à mettre l'information sur les ressources DNS vérifiées, je vais l'ajouter car c'est très important pour correctement configurer son serveur DNS.

Pour l'update-ploicy, je vais aussi le mettre à jour dans l'exemple d'utilisation avec bind9. J'ai cherché un moyen pour créer une règle du style wildcard _acme-challenge.*.example.com, mais ce n'est pas possible.

Du coup, comme j'avais le nez dans ce problème, je n'ai pas pensé à chercher des solutions plus simples. Le problème de self est qu'il oblige à utiliser des CSR avec un seul domaine (et donc de faire un CSR et une configuration acme-dns-tiny par domaine à vérifier).

Je pense que je vais plutôt montrer un exemple de ce style:

key "_acme-challenge" {
    …
};

zone "example.com" {
    type master;
    file "example.com.zone";
    update-policy {
        grant _acme-challenge name _acme-challenge.example.com TXT;
        grant _acme-challenge name _acme-challenge.www.example.com TXT;
    };
};

C'est un peu moins rapide à mettre en place que zonesub s'il y a beaucoup de sous-domaines à vérifier, mais c'est beaucoup plus sécurisé car les autorisations sont restreintes au minimum.

Merci pour SIG(0), je ne connaissais pas ce protocole. Malheureusement, le module dnspython que j'utilise ne l'implémente pas : https://groups.google.com/forum/?hl=fr#!topic/dnspython-users/ZnssFZlA48o

Je répondais surtout à la phrase:

rigolo de voir que quand Apple fait c'est mal mais quand Mozilla fait c'est bien.

Tu ne peux pas dire que Mozilla fait la même chose qu'Apple.

Le premier laisse clairement utiliser son logiciel sans DRM, à la condition de le reconstruire ou d'utiliser une version instable. Le second ne laisse aucun choix.

Et je ne porte pas de jugement sur "mal" ou "bien", c'est surtout 2 cas différents.

Aux dernières nouvelles, Apple empêche d'installer une version alternative de magasin d'application et empêche la recompilation d'iOS pour enlever ces limites.

Ou même sortir ton iPhone, ton windows phone, ton Samsung, ton Sony, ton Tizen, ton OpenMoko, ton N900, ton Open-C, ton n-ième phone à 100€ … et commencer à coder des clients « natifs » pour chacune de ces plateformes (et racheter les nouvelles versions à chaque fois, n'oublie pas d'acheter les licences de développement [pour ton portable et le serveur d'intégration] et d'utilisation des Store).

Franchement, un client natif pour Movim ne peut apporter beaucoup plus que le site Web, si ce n'est une intégration au système de notification et de cache de l'environnement. Mais même pour ces 2 points les navigateurs web modernes sont déjà capable de bien s'intégrer.

Ce qu'il faut surtout comprendre, c'est que Movim est une interface à XMPP, tout le travail de serveur est fait par XMPP (Pubsub, Carbon, MAM, …). En plus, la structure de Movim est telle que le navigateur web a un minimum de travail à faire, car c'est le daemon de Movim qui se charge de communiquer avec les serveurs XMPP (si j'ai bien compris, les parties clientes nécessaires à XMPP sont aussi gérées par le daemon).

Du coup, je vois mal ce que peut apporter un client "natif" en plus sur un téléphone ou une tablette. Mozilla a déjà prouvé que les technologies web pouvaient être utilisées pour faire un système d'exploitation complet pour smartphone (bien que Firefox OS n'a pas eu le succès escompté, des téléphones fonctionnent avec leur système).