D'abord, des problèmes physiques : il faut d'abord faire un design électronique qui tienne la route en terme d'électronique et qui passe dans le boîtier final. Ensuite il faut qu'il soit réalisable par un fondeur (chaque lot produit coûte très cher, car les appareils des fondeurs sont cher et que ca prend beaucoup de temps pour les paramétrer).
Typiquement, le design de la carte GTA04A5 semble bon, mais la soudure du CPU et de la RAM échoue dans 60% de cas.
Enfin, même s'il est réalisable, on peut découvrir des bugs matériels uniquement à l'usage. L'OpenMoko avait des problèmes de grésillements dans le micro dans ses premieres versions, il me semble qu'il y avait aussi des interférences entre les ondes produites par les différents modules et le lecteur SD.
Ensuite, il y a des soucis logiciels dus au monde ARM: comme il n'existe pas de procédure de démarrage standard et de découverte de matériel, comme dans x86, chaque firmware et noyau est extrêmement lié au matériel auquel il est destiné. Heureusement pour le démarreur il existe des projets libres comme U-Boot et, depuis quelques temps, le noyau Linux est capable de démarrer sur plusieurs matériels différents grâce aux DeviceTree qui simplifient la definition du matériel présent dans une configuration.
Pour le noyau, Golden Delicious a décidé de pousser upstream un max de patch, mais apparemment ils n'arrivent pas à tout faire intégrer. Grâce à ce travail, ils sont ensuite capable de faire un rootfs Debian et de l'exécuter sur la machine.
Onlyoffice se comporte exactement pareil avec les uns et les autres.
Il semble que OnlyOffice ne soit pas capable d'éditer des fichiers OpenDocument (d'après cette dépêche), donc je ne comprend pas bien, comment il peut se comporter exactement pareil avec un format ou l'autre.
Ensuite, LibreOffice aussi sait très bien se comporter avec les deux standards tant que MS Office ne modifie pas les fichiers.
Ce qui serait plus intéressant, ce serait de savoir comment OnlyOffice gère les documents au format OOXML quand ceux-ci ont été modifiés par MS Office ? Et dans la même idée, est-ce que MS Office est capable de bien traiter les documents créés par OnlyOffice ?
L'interopérabilité sans problèmes serait une réelle plus value, mais, personnellement, je pense que c'est une chimère car les développeurs logiciels sont souvent tentés d'ajouter des comportements non standard que ce soit par stratégie marketing ou par le souhait de fournir des solutions aux utilisateurs rapidement.
Merci pour la nouvelle, il y a juste une coquille : OpenDocument n'est pas « de la Document Foundation », mais du consortium OASIS (d'ailleurs la Document Foundation est bien plus récente que le format OpenDocument ;) ).
D'ailleurs, pour ces formats de fichier, il existe une autre solution intégrée à ownCloud et NextCloud: Collabora Online. Cette solution si je me souviens bien utilise le backend de LibreOffice (ce projet est bien celui de la Document Foundation).
Justement, Conversation (un client XMPP pour Android) supporte OMEMO pour le chiffrement de bout en bout depuis quelques versions, mais il fallait l'activer manuellement, puis autoriser les signatures des périphériques un à un.
Comme cette démarche est difficile en pratique, et ils viennent de sortir une version (1.15) qui apporte une amélioration intéressante dans ce sens: ils proposent d'activer un chiffrement par défaut pour tous les périphériques tant qu'aucune authentification n'a été réalisée.
Quand le processus d'authentification est réalisé (par le scan d'un QR Code [obtenu par un autre canal sécurisé] au lieu du contrôle manuel et fastidieux des signatures [obtenu par le même canal XMPP]), ils considèrent que l'utilisateur est capable d'authentifier les périphériques des contacts authentifiés et ne chiffrent plus que pour ces périphériques.
Je trouve la démarche intéressante, car il permet de ne pas tomber dans un modèle où tout est chiffré sans authentification réelle des utilisateurs, mais il permet quand même aux utilisateurs sans capacités à réalisé l'authentificaiton (soit de sa part, soit de la part du contact) d'avoir le minimum du chiffrement.
Désolé si ce n'est pas très claire, j'ai lu leur explication du principe ce matin plus ou moins en vitesse et je ne suis pas sûr d'avoir tout compris. Je vous conseille donc de lire leur post original qui détaille plus la situation actuelle et la solution intermédiaire qu'ils ont mis en place.
Merci je vais aller voir les différents clients ptete que l'un ou l'autre permet de passer par d'autres port.
Ne cherche pas, ça n'existe pas, car le protocole ACME ne pourra pas vérifier que tu es l'administrateur système (voir ma réponse plus bas).
J'ai déjà un reverse proxy mais pour plusieurs raisons je l'ai remplacé, pour certains services, par un accès direct via un des autres ports web.
Le reverse proxy n'est qu'un bonus, il n'est pas nécessaire. Tu peux garder tes sites accessibles sur d'autres ports, ça ne pose aucun problème.
Il faut savoir qu'un certificat Let's Encrypt n'est utilisable que sur les ports 80, 443, 8080, 8443. Si on utilise des autres ports pour raison X ou Y, firefox bloque et je suppose que ses bêtes compères pareil.
Non, ce n'est pas vrai: les certificats ne définissent pas les ports sur lesquels ils peuvent être utilisés. Par exemple, pour mon serveur, j'utilise les certificats Let's Encrypt sur les ports : 25, 587, 5222, 5269, 5280, 443, 486, … Un certificat n'est qu'un document signé par une autorité de certification. Ce document contient principalement la clé publique utilisée par ton domaine et une date de validité, c'est quasiment tout.
C'est leur choix de bloquer la possibilité de choisir les ports, c'est leur choix de foutre une limite de trois mois, c'est un projet de mozzila dont comme par hasard firefox force a utiliser des certificats trusté.
De un, ce n'est pas Mozilla qui gère ce projet d'après le site letsencrypt.org : "Linux Foundation Collaborative Projects".
De deux, Mozilla ne t'empêche pas d'utiliser des certificats auto-signés: il faut juste ne pas activer HSTS, car dans ce cas, il est nécessaire d'avoir une configuration TLS correcte (sinon, ce n'est pas une configuration de type Strict-Transport-Security), ce qui requiert un certificat signé par une autorité de confiance reconnue par les navigateurs.
Le but de la vérification par HTTP est de vérifier automatiquement que tu maîtrises la configuration du serveur web qui pointe sur le domaine demandé (et donc que ce domaine t'appartienne bien).
Si tu es incapable de maîtriser cette configuration sur le service web standard (ports 80 et 443), alors le protocole ACME considère que tu n'es pas le maître de ce serveur et il n'a pas d'autre moyen de le faire automatiquement.
Si ACME autorise la vérification avec un autre port, alors n'importe quel employé qui a un accès non-root sur un serveur peut créer des certificats frauduleux: en effet, tous les ports plus grand que 1000 (comme les ports 8080 et 80443), si je me souviens bien, peuvent être utilisés par n'importe quel utilisateur de la machine. Dans ce cas, ACME ne peut pas certifier que c'est bien l'administrateur système qui demande la certification.
L'automatisation de la certification demande en effet une préparation non-évidente pour l'auto-hébergement, mais ce n'est pas non plus insurmontable (voire les solutions que j'ai donné plus haut).
Ah et bien sûr, il ne faut pas que ton client ACME touche à la configuration de ton service web.
Il parraît qu'il y a des options pour ça avec le client certbot (que je n'utilise pas), il faut lire son manuel.
Il y a plein de clients ACME alternatifs qui permettent de récupérer les certificats sans toucher au serveur web. Je pense qu'acme-tiny devrait faire l'affaire dans ce cas (en plus il n'a besoin que d'accéder à ta clé Let's Encrypt et aux CSR).
PS: Surtout n'utlise pas chmod 777 pour la protection de tes fichiers, ils seront tous accessibles si quelqu'un arrive à s'introduire sur tes serveurs.
PS2: Tu peux faire un dossier partagé par serveur, rien ne t'oblige de mettre tous les certificats dans le même dossier partagé…
Désolé, je n'avais pas vu que c'était bien le NAT ton problème.
Dans ce cas, il faut:
Pointer tous tes domaines et sous-domaines sur l'adresse IP publique
Configurer le NAT pour envoyer toutes les connexions entrantes sur les ports 80 et 443 vers ton serveur 1
Configurer le service web du serveur 1 pour écouter chaque domaine et sous-domaines sur les ports 80 et 443
Utiliser le serveur 1 pour demander des certificats à Let's Encrypt pour chacun des domaines et sous domaines
Quand les certificats sont reçu, tu peux soit:
demander au serveur 1 de pousser les bons certificats sur chacun de tes autres serveurs (l'avantage est que le serveur 1 sait quand il crée les certificats, par contre le désavantage est qu'il doit avoir un accès sur chacun des serveurs)
dire à chacun de tes autres serveurs d'aller chercher les nouveaux certificats sur le serveur1 (le désavantage est que les autres serveurs doivent récupérer assez souvent les certificats pour être sûr d'avoir le dernier, l'avantage est que chaque serveur aura ses propres droits sur le serveur 1 et le serveur 1 ne peut pas toucher aux autres serveurs)
En bonus, si tu maitrises suffisamment ton service web sur le serveur 1, tu peux l'utiliser comme reverse proxy : si une requête est faite sur les URLs utilisées par Let's Encrypt, il répond lui-même à la requête, dans les autres cas, il renvoie les requêtes vers les bons servuers. Comme ça, tu peux utiliser tout tes domaines avec les ports standards web.
Si tu maitrises ton serveur DNS et que tu peux le configurer pour autoriser des modifications automatiques des zones (avec des clés TSIG par exemple), tu peux tout faire sur ce serveur en utilisation la vérification par entrées DNS fournie par Let's Encrypt.
Est-ce que tu as ces problèmes à cause d'un NAT qui gère les 3 serveurs ? Dans ce cas, une solution serait aussi d'utiliser un réseau IPv6 que Let's Encrypt sait utiliser.
Si Let's Encrypt t'ennuie autant, personne ne te force à utiliser leurs services et ça ne sert strictement à rien de leur cracher dessus: le problème des NAT existe depuis bien avant et il complexifie beaucoup d'autres services également (XMPP, P2P,…) sans que ce soit de leur faute.
QtMoko était un projet complet d'OS pour smartphone utilisant Qt Embedded pour faire tout l'affichage sur le framebuffer de l'OpenMoko (et autres périphériques). Ily a peut être encore de la dic qui pourrait etre intéressante : http://qtmoko.sf.net
PS: j'ai mis officiel entre guillemet car il peut y avoir des tas d'images possibles de Debian: du desktop avec GNOME, KDE, … aux images de serveurs, selon plusieurs architectures processeurs… C'est pas pour rien qu'ils se disent universel :)
Désolé, je voulais écrire NFS effectivement. Quel est l'intérêt d'itiliser l'image «officielle» de Debian sur Docker Hub ?
Debootstrap est aussi un outil officiel de Debian et il construit directement tout le nécessaire pour en faire une image docker par simple import. Vous aurez en plus l'avantage de ne charger Debian qu'une fois depuis Internet et vous pouvez préparez directement les fichiers systèmes spécifiques à vos besoins.
Comme ça, vous pouver directement créer la ligne NTFS dans fstab sans avoir d'erreur. Si jamais, il faut utiliser des entrées bind dans fstab (ou mount avec le type bind) au lieu de faire des liens symboliques entre deux montages différents.
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.
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é:
A la main, sur une machine à l'abris, 1 fois (sauf si tes clés sont corrompues):
Créer 2 paires de clés privées / publiques
Créer 1 CSR pour 1 la première paire de clés
De manière automatisable (et régulièrement au moins tous les 89 jours):
S'inscrire sur un serveur ACME avec la seconde paire de clé crée (pas celle du CSR!)
Demander des challenges DNS pour son CSR au serveur ACME
Recevoir les challenges et ajouter 1 ressource TXT par domaine avec un identifiant qui peut être calculé par toi et par le serveur ACME
Optionnel: attendre que les mises à jour DNS soient effectives
Demander au serveur ACME de vérifier les challenges sur tes serveurs DNS
Récupérer ton certificat quand les challenges sont tous validés
Récupérer le certificat intermédiaire qui a généré ton certificat
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):
Aller récupérer les nouveaux certificats
Installer les certificats là où les services les chercheront
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é ?
"É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.
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…
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.
[^] # Re: smartphone et OS
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Les mobiles libres ont du plomb dans l’aile et les systèmes d’exploitation ne vont pas mieux. Évalué à 4.
En fait, il existe pas mal de problèmes.
D'abord, des problèmes physiques : il faut d'abord faire un design électronique qui tienne la route en terme d'électronique et qui passe dans le boîtier final. Ensuite il faut qu'il soit réalisable par un fondeur (chaque lot produit coûte très cher, car les appareils des fondeurs sont cher et que ca prend beaucoup de temps pour les paramétrer).
Typiquement, le design de la carte GTA04A5 semble bon, mais la soudure du CPU et de la RAM échoue dans 60% de cas.
Enfin, même s'il est réalisable, on peut découvrir des bugs matériels uniquement à l'usage. L'OpenMoko avait des problèmes de grésillements dans le micro dans ses premieres versions, il me semble qu'il y avait aussi des interférences entre les ondes produites par les différents modules et le lecteur SD.
Ensuite, il y a des soucis logiciels dus au monde ARM: comme il n'existe pas de procédure de démarrage standard et de découverte de matériel, comme dans x86, chaque firmware et noyau est extrêmement lié au matériel auquel il est destiné. Heureusement pour le démarreur il existe des projets libres comme U-Boot et, depuis quelques temps, le noyau Linux est capable de démarrer sur plusieurs matériels différents grâce aux DeviceTree qui simplifient la definition du matériel présent dans une configuration.
Pour le noyau, Golden Delicious a décidé de pousser upstream un max de patch, mais apparemment ils n'arrivent pas à tout faire intégrer. Grâce à ce travail, ils sont ensuite capable de faire un rootfs Debian et de l'exécuter sur la machine.
Je dois vous laisser, je reviendrai plus tard.
[^] # Re: positionnement
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Intégration de ownCloud avec OnlyOffice. Évalué à 2.
Il semble que OnlyOffice ne soit pas capable d'éditer des fichiers OpenDocument (d'après cette dépêche), donc je ne comprend pas bien, comment il peut se comporter exactement pareil avec un format ou l'autre.
Ensuite, LibreOffice aussi sait très bien se comporter avec les deux standards tant que MS Office ne modifie pas les fichiers.
Ce qui serait plus intéressant, ce serait de savoir comment OnlyOffice gère les documents au format OOXML quand ceux-ci ont été modifiés par MS Office ? Et dans la même idée, est-ce que MS Office est capable de bien traiter les documents créés par OnlyOffice ?
L'interopérabilité sans problèmes serait une réelle plus value, mais, personnellement, je pense que c'est une chimère car les développeurs logiciels sont souvent tentés d'ajouter des comportements non standard que ce soit par stratégie marketing ou par le souhait de fournir des solutions aux utilisateurs rapidement.
# OpenDocument
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Intégration de ownCloud avec OnlyOffice. Évalué à 9.
Merci pour la nouvelle, il y a juste une coquille : OpenDocument n'est pas « de la Document Foundation », mais du consortium OASIS (d'ailleurs la Document Foundation est bien plus récente que le format OpenDocument ;) ).
D'ailleurs, pour ces formats de fichier, il existe une autre solution intégrée à ownCloud et NextCloud: Collabora Online. Cette solution si je me souviens bien utilise le backend de LibreOffice (ce projet est bien celui de la Document Foundation).
[^] # Re: Wire
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Silence : XMPP, chiffrement et méta‐données. Évalué à 2.
Justement, Conversation (un client XMPP pour Android) supporte OMEMO pour le chiffrement de bout en bout depuis quelques versions, mais il fallait l'activer manuellement, puis autoriser les signatures des périphériques un à un.
Comme cette démarche est difficile en pratique, et ils viennent de sortir une version (1.15) qui apporte une amélioration intéressante dans ce sens: ils proposent d'activer un chiffrement par défaut pour tous les périphériques tant qu'aucune authentification n'a été réalisée.
Quand le processus d'authentification est réalisé (par le scan d'un QR Code [obtenu par un autre canal sécurisé] au lieu du contrôle manuel et fastidieux des signatures [obtenu par le même canal XMPP]), ils considèrent que l'utilisateur est capable d'authentifier les périphériques des contacts authentifiés et ne chiffrent plus que pour ces périphériques.
Je trouve la démarche intéressante, car il permet de ne pas tomber dans un modèle où tout est chiffré sans authentification réelle des utilisateurs, mais il permet quand même aux utilisateurs sans capacités à réalisé l'authentificaiton (soit de sa part, soit de la part du contact) d'avoir le minimum du chiffrement.
Désolé si ce n'est pas très claire, j'ai lu leur explication du principe ce matin plus ou moins en vitesse et je ne suis pas sûr d'avoir tout compris. Je vous conseille donc de lire leur post original qui détaille plus la situation actuelle et la solution intermédiaire qu'ils ont mis en place.
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 5.
Ne cherche pas, ça n'existe pas, car le protocole ACME ne pourra pas vérifier que tu es l'administrateur système (voir ma réponse plus bas).
Le reverse proxy n'est qu'un bonus, il n'est pas nécessaire. Tu peux garder tes sites accessibles sur d'autres ports, ça ne pose aucun problème.
Non, ce n'est pas vrai: les certificats ne définissent pas les ports sur lesquels ils peuvent être utilisés. Par exemple, pour mon serveur, j'utilise les certificats Let's Encrypt sur les ports : 25, 587, 5222, 5269, 5280, 443, 486, … Un certificat n'est qu'un document signé par une autorité de certification. Ce document contient principalement la clé publique utilisée par ton domaine et une date de validité, c'est quasiment tout.
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 6.
De un, ce n'est pas Mozilla qui gère ce projet d'après le site letsencrypt.org : "Linux Foundation Collaborative Projects".
De deux, Mozilla ne t'empêche pas d'utiliser des certificats auto-signés: il faut juste ne pas activer
HSTS, car dans ce cas, il est nécessaire d'avoir une configuration TLS correcte (sinon, ce n'est pas une configuration de typeStrict-Transport-Security), ce qui requiert un certificat signé par une autorité de confiance reconnue par les navigateurs.Le but de la vérification par HTTP est de vérifier automatiquement que tu maîtrises la configuration du serveur web qui pointe sur le domaine demandé (et donc que ce domaine t'appartienne bien).
Si tu es incapable de maîtriser cette configuration sur le service web standard (ports 80 et 443), alors le protocole ACME considère que tu n'es pas le maître de ce serveur et il n'a pas d'autre moyen de le faire automatiquement.
Si ACME autorise la vérification avec un autre port, alors n'importe quel employé qui a un accès non-root sur un serveur peut créer des certificats frauduleux: en effet, tous les ports plus grand que 1000 (comme les ports 8080 et 80443), si je me souviens bien, peuvent être utilisés par n'importe quel utilisateur de la machine. Dans ce cas, ACME ne peut pas certifier que c'est bien l'administrateur système qui demande la certification.
L'automatisation de la certification demande en effet une préparation non-évidente pour l'auto-hébergement, mais ce n'est pas non plus insurmontable (voire les solutions que j'ai donné plus haut).
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 4. Dernière modification le 06 novembre 2016 à 20:46.
Ah et bien sûr, il ne faut pas que ton client ACME touche à la configuration de ton service web.
Il parraît qu'il y a des options pour ça avec le client certbot (que je n'utilise pas), il faut lire son manuel.
Il y a plein de clients ACME alternatifs qui permettent de récupérer les certificats sans toucher au serveur web. Je pense qu'acme-tiny devrait faire l'affaire dans ce cas (en plus il n'a besoin que d'accéder à ta clé Let's Encrypt et aux CSR).
PS: Surtout n'utlise pas chmod 777 pour la protection de tes fichiers, ils seront tous accessibles si quelqu'un arrive à s'introduire sur tes serveurs.
PS2: Tu peux faire un dossier partagé par serveur, rien ne t'oblige de mettre tous les certificats dans le même dossier partagé…
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 4. Dernière modification le 06 novembre 2016 à 20:35.
Désolé, je n'avais pas vu que c'était bien le NAT ton problème.
Dans ce cas, il faut:
En bonus, si tu maitrises suffisamment ton service web sur le serveur 1, tu peux l'utiliser comme reverse proxy : si une requête est faite sur les URLs utilisées par Let's Encrypt, il répond lui-même à la requête, dans les autres cas, il renvoie les requêtes vers les bons servuers. Comme ça, tu peux utiliser tout tes domaines avec les ports standards web.
Pour t'aider pour le reverse proxy, tu peux regarder ce lien : https://blog.bandinelli.net/index.php?post/2016/10/19/Pound-Let-s-Encrypt-%3A-un-service-pour-tout-r%C3%A9gler
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 5.
Si tu maitrises ton serveur DNS et que tu peux le configurer pour autoriser des modifications automatiques des zones (avec des clés TSIG par exemple), tu peux tout faire sur ce serveur en utilisation la vérification par entrées DNS fournie par Let's Encrypt.
Est-ce que tu as ces problèmes à cause d'un NAT qui gère les 3 serveurs ? Dans ce cas, une solution serait aussi d'utiliser un réseau IPv6 que Let's Encrypt sait utiliser.
Si Let's Encrypt t'ennuie autant, personne ne te force à utiliser leurs services et ça ne sert strictement à rien de leur cracher dessus: le problème des NAT existe depuis bien avant et il complexifie beaucoup d'autres services également (XMPP, P2P,…) sans que ce soit de leur faute.
[^] # Re: Pour de l'embarqué
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message rendu graphique sur le framebuffer. Évalué à 2.
QtMoko était un projet complet d'OS pour smartphone utilisant Qt Embedded pour faire tout l'affichage sur le framebuffer de l'OpenMoko (et autres périphériques). Ily a peut être encore de la dic qui pourrait etre intéressante : http://qtmoko.sf.net
[^] # Re: Créer sa propre image docker
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Docker montage local/NFS. Évalué à 2.
PS: j'ai mis officiel entre guillemet car il peut y avoir des tas d'images possibles de Debian: du desktop avec GNOME, KDE, … aux images de serveurs, selon plusieurs architectures processeurs… C'est pas pour rien qu'ils se disent universel :)
[^] # Re: Créer sa propre image docker
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Docker montage local/NFS. Évalué à 2.
Désolé, je voulais écrire NFS effectivement. Quel est l'intérêt d'itiliser l'image «officielle» de Debian sur Docker Hub ?
Debootstrap est aussi un outil officiel de Debian et il construit directement tout le nécessaire pour en faire une image docker par simple import. Vous aurez en plus l'avantage de ne charger Debian qu'une fois depuis Internet et vous pouvez préparez directement les fichiers systèmes spécifiques à vos besoins.
# Créer sa propre image docker
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Docker montage local/NFS. Évalué à 2.
J'essaierai à votre place de créer directement vous même une image docker en utilisant debootstrap et docker import: https://docs.docker.com/engine/userguide/eng-image/baseimages/
Comme ça, vous pouver directement créer la ligne NTFS dans fstab sans avoir d'erreur. Si jamais, il faut utiliser des entrées bind dans fstab (ou mount avec le type bind) au lieu de faire des liens symboliques entre deux montages différents.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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) . En réponse au message Let's Encrypt en prod en entreprise. É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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's Encrypt en prod en entreprise. É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…
# Dans un signet sous la notation du contenu
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Indication de nouveaux commentaires à côté du titre du contenu. Évalué à 2 (+0/-0).
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 :)
[^] # Re: vive Paypal
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Paypal en a marre que l’on dise que c’est nul. Évalué à 3.
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.