Je préfère ma méthode : https://blog.imirhil.fr/2014/04/29/dechiffrer-plusieurs-luks.html
Elle n’est pas passwordless mais n’en nécessite qu’un seul pour déverrouiller tous les disques et elle a l’avantage de ne pas avoir la clef de déverrouillage en clair sur un support, même USB :P
Une banque ou GDF va demander à ta grand-mère d'installer un raspberry pi chez elle ou de souscrire un abonnement sur cozycloud.com pour pouvoir échanger des données
Elle peut aussi te fournir gratuitement un cozy minimaliste par défaut, en te laissant le choix d’utiliser un autre cozy (auto-hébergé, hébergé ou prestataire) si tu le souhaites.
Ça semble raisonnable. Plus que la position officiel de Cozy
Je ne vois pas l’incompatibilité avec les 2…
Que ton Cozy soit chez toi, chez un partenaire ou hébergé en propre par CozyCloud, le fonctionnement décrit plus haut reste le même : récupérer toutes tes données, les mettre sur ton Cozy pour y faire de la « small data » personnelle.
et ça ça fait un peu peur :
Nous avons par ailleurs la possibilité d’auditeur ces données et donc de savoir lesquelles sont copiées et partagées.
Le « nous » est à prendre au sens « les utilisateurs ». L’intégralité des accès et émissions de données est logguée dans le Cozy de l’utilisateur, qui peut y accéder pour voir si une application fait un usage abusif ou interdit des données.
L’hébergeur/partenaire n’a pas accès à ces logs (légalement et contractuellement en tout cas, techniquement un tiers technique fait tout ce qu’il veut, il a accès aux machines :P)
Quand des frangins ne sont pas d’accords, ils demandent aux parents de trancher.
Qu’ils aient 4 millions d’euro ou des nèfles, ça ne change pas grand chose au problème, ça reste des parents qui cherchent la meilleure décision pour la famille (et pas que pour eux-mêmes).
DKIM, SPF & DMARC n’autorisent qu’une vérification a priori de la validité d’un mail. C’est impossible de s’en servir pour une vérification a posteriori (ie comme preuve future), sauf à conserver la preuve de la validité de la vérification de ces mécanismes lors de la réception.
Ce qui sur le papier me semble encore plus impossible qu’une validation a priori certifiée. Il faudrait sauvegarder l’état du DNS (SPF, DKIM, DMARC, MX, IP…), des clefs DKIM utilisées, des IP de réception, du registre du personnel, du propriétaire du domaine… le tout de manière certifiée elle-aussi.
On peut en effet très bien imaginer recevoir un mail légitime qui passe l’ensemble des validations à l’instant T, mais qui ne peut plus être vérifié à l’intant T+1 (changement de clef DKIM ou de SPF suite à refonte de l’infra informatique par exemple).
Ou inversement un mail illégitime à l’instant T mais dont l’attaquant fera le nécessaire le jour où il aura besoin de s’assurer de la validité de cette preuve (usurpation DNS, etc).
Si tu as de la compilation reproductible, oui.
Sinon, tu peux avoir 2 checksums différents mais le même binaire quand même (même versions de libs, même version d’application, mais un truc qui a changé entre les 2, par exemple la date de build dans une entête d’archive…).
C’est un problème à part entière et même Debian ne parvient pas encore au 100% reproductible.
Tu n'a pas compris que quand on fait du packaging, on versionne ne le packaging en plus du logiciel. Si tu fais une construction alors tu passe de 1.0.0-n à 1.0.0-$((n+1)).
C’est exactement mon propos.
Tu vas te retrouver chaque jour avec une v1.0.n+1 dont tu n’as absolument aucune idée si c’est techniquement une vraie v1.0.n+1 (une lib a bougé depuis) ou juste une v1.0.0 rebuildé (aucune modif de lib).
Et donc si tu dois la pousser à tes utilisateurs ou non.
On remarque qu'il y a des paquets qui sont mis à jour un grand nombre de fois. Donc non, en une semaine tu peux très bien avoir plusieurs mise à jour d'un même paquet.
Je ne vois pas le rapport avec ce que j’annonce.
Oui bien sûr que OpenSSL va se prendre une maj de sécu par jour voire plus.
Ce n’est pas une raison pour que le paquet de Firefox ou de FreeCAD le soit justement !!! Et c’est même un comportement que tu ne souhaites absoluement pas avoir…
Actuellement, si OpenSSL publie 5 maj de sécu en 1 semaine, je maj 5 fois OpenSSL. Et c’est tout !!!
Avec Snap, comme ma dépendance foireuse est dans quasi toutes mes applications, ça va soit me laisser à poil jusqu’à ce que le mainteneur du snap décide d’intégrer la version d’OpenSSL corrigée, soit ça va me faire aussi 5 maj de mon appli snap.
En pratique, là où aujourd’hui un fix de sécu se résume à upgrader une seule lib et à oublier cette faille définitivement, snap va être une bouse infecte qui va nécessiter de se poser la question de quelles applications intègrent quelles versions de OpenSSL, de mettre à jour l’ensemble de tes applications impactées, et à devoir surveiller ton système avec une très longue traîne de faille le temps que tous tes mainteneurs snap aient fait leur travail d’intégration.
Et c'est ce que tu as eu en vrai déjà maintenant. Tu peut très bien avoir eu une dépendance qui à modifié le comportement de freecad (plantage, ralentissement, accélération, etc) et c'est une version différente sauf que c'est invisible et complexe à reproduire.
Sur des fixs de sécurité, c’est quasi impossible, et en tout cas ça ne vaut clairement pas la chandelle du risque de sécurité introduit par snap.
Tu échanges un potentiel risque de régression jamais atteint en pratique ou qu’à la marge, contre un risque avéré de dépréciation progressive des bibliothèques installées sur ta machine et donc soumises à faille de sécurité.
Il n'y a que les sysadmin qui se permettent de faire des mises à jour à l'arrache des dépendances en espérant que ça va passer parce que leur système doit être toujours à jour quitte à ce que les services lancé dessus soient down
Je met à jour chaque jour à gros coup de apt dist-upgrade, je n’ai connu qu’un seul down de prod (à l’arrivée de systemd).
apt est très robuste de ce côté et Debian suffisamment soigneux avec ses paquets pour éviter le dawa.
Au contraire, tu maitrises cette partie. Tant que tu ne fais de pull, ton environnement local sera fige. C'est le contraire d'apt, ou un simple apt upgrade fait que justement, un meme binaire peut avoir des comportements differents suivant les jours. Le cas est rare certes, mais la reproductibilité est clairement une force des containers.
On s’en tape de la reproductibilité si c’est pour monter une armée de botnet en 1 mois. La sécu avant tout SVP…
C'est ce que tu as deja en prod. Vraiment.
Non, je n’ai pas ça en prod. Je n’ai pas 180 versions de FreeCAD. Si FreeCAD ne bouge pas, il n’est pas mis à jour.
L'avantage, c'est qu'au moins, tu délivres des configs cohérentes a tes utilisateurs, des configs que tu peux tester et reproduire.
Et de grosse terrachiés de bugs et failles non corrigés…
Encore une fois, les ppa pourront detecter ce genre de dependance et relancer une build. Le mainteneur n'aura rien a faire.
Et donc ? Les Snap deviennent un apt dist-upgrade remote ?
Intérêt par rapport à APT si mon FreeCAD est mis-à-jour 1 jour sur 2 avec des dépendances non maîtrisées ? Ça casse complètement l’intérêt que vous vendez de Snap là…
Snap n’est intéressant que si tes utilisateurs passent leur vie à poil sur leurs machines… Comme Docker, Go et plus généralement tout ce qui cherche à figer plus ou moins définitivement l’environnement, ce qui est un énorme problème de sécurité et une véritable bombe à retardement dégoupillée…
On va juste bien rigoler au prochain Heartbleed ou random-42 like tient…
La containerisation est intéressante pour le dev, ça c’est indéniable.
Ça évite de péter son système principal et ça permet de conserver des environnements stables même si on développe sur plusieurs environnements en parallèle (du genre des projets qt4 et qt5).
Ou d’installer aux forceps de vieilles ou trop récentes versions de dépendances.
Pour savoir si tu as besoin de reconstruire tu as montré la commande. C'est automatisable encore une fois.
Ce n’est actuellement pas du tout le cas et c’est un problème compliqué à résoudre.
Tu lances ta commande, tu obtiens un binaire. Est-ce le même qu’hier ? Tu es incapable de le dire. As-tu buildé une v1.0.0 ou une de tes dépendances a-t-elle bougée et tu as alors compilé une v1.0.1 malgré que tu aies indiqué v1.0.0 dans ton fichier de build ?
La seule manière viable de procéder est de générer la liste des dépendances dynamiquement chaque jour, de vérifier si elle a bougé depuis hier (hint : c’est statistiquement le cas) et si c’est le cas, de lancer un nouveau build du snap en incrémentant sa révision, snap qui ne partage potentiellement plus grand chose comme dépendances par rapport à la version d’il y a 1 semaine.
Et alors tu t’éloignes bien loin de la joie annoncée en début de journal de la stabilité et maîtrise de ton système…
Pour l’exemple de FreeCAD, ça donne par exemple plus de 180 versions sur 1 an, dont les dépendances divergent rapidement passées 1 semaine d’écart.
Juste ça en prod, tu oublies. Vraiment.
Les autres manières de procéder impliquent le gel sur un terme plus ou moins long des dépendances et donc d’exposer ses utilisateurs à des failles ou des bugs.
On imagine assez bien un mainteneur n’upgradant ses dépendances qu’avec une nouvelle release upstream de l’application principale, laissant un trou béant entre deux. Et à l’inverse assez mal le mainteneur de FreeCAD se dire « Oh , un heartbleed sauvage apparaît. FreeCAD snap, en avant ! ».
Et c’est totalement compréhensible, il est responsable de la maintenance de FreeCAD. Ni de OpenSSL, ni de la libc, ni de DBus !!!
Sur 1 an et avec 52 dépendances non installées sur 432, 178 mise-à-jours, soit 1 jour sur 2.
La plus grosse, le 09/11/2015 (release Debian 8.2.0 je dirais), 254 dépendances modifiées, suivi du 03/02/2016 (Debian 8.4) avec 115 dépendances.
35 jours (soit 1 semaine sur 2 environ) avec plus de 10 mises-à-jour.
Ça ne change pas grand chose au fait que le mainteneur Snap de FreeCAD soit ne va plus avoir de vie sociale pour suivre les correctifs et décider de livrer une nouvelle version ou non, soit va livrer tous les 2 jours un Snap rebuildé « au cas où » à l’arrache à partir de l’état courant des dépôts Debian sans maîtrise de ce qu’il livre réellement.
Tu as une source pour affirmer que tout va être rebuilde tous les jours ou tu affirmes juste sans aucune idee de comment ca va marcher en pratique ?
Vu la tonne de dépendances remontée par FreeCAD, c’est au doigt mouillé mais je ne dois pas être loin du compte. La probabilité d’avoir une maj de version sur une des dépendances chaque jour est à mon avis proche de 1.
J’ai vérifié sur mon système, les dates où apt m’a fait une mise-à-jour d’une des dépendances :
Sur 365 jours, 2015-06-02 au 2016-06-06 : 226 mises-à-jour.
Et encore, ça ne concerne que les dépendances actuellement installées sur mon système, il m’en manque 52 sur les 432.
Mais je te concède sans soucis le jour sur 3 qui ne connaît pas de mise-à-jour…
Dans tous les cas, ça confirme bien le problème : tu vas devoir livrer chaque jour un paquet Snap FreeCAD sous peine de rendre obsolètes tes utilisateurs…
Et avec un enfer de dépendances différentes chaque jour.
Mon script y va peut-être avec de gros doigts, mais je compte 86 jours avec plus de 10 dépendances modifiés, 7 avec plus de 100 dépendances et même 2 journées avec plus de 400. Qui s’est mis à jour et pourquoi ?
Heu… si l'equivalent des ppa vont tres certainement gérer ca proprement, comme les ppa le font deja pour les .deb en fait.
Les PPA n’ont justement pas à gérer ça. Si libssl est mis à jour, FreeCAD n’a pas à être rebuildé. On ne rebuild FreeCAD que si FreeCAD change de version upstream (et on en profite au passage pour upgrader un coup les dépendances si nécessaires).
Alors que le snap va devoir être rebuildé sur chaque changement de version de FreeCAD, mais aussi de n’importe laquelle de ses dépendances, y compris récursives.
Reconstruire les images, c'est le boulot des ppa d'ubuntu. Le boulot du mainteneur, c'est de vérifier que toutes les dépendances sont bien decrites dans le format du paquet, c'est tout.
C’est effectivement le taff actuel des PPA. Ce n’est pas du tout le même genre ni volume de travail qui attend un mainteneur Snap.
Si tu es mainteneur PPA, tu n’as pas à te soucier de la maintenance de tes dépendances, si tu es mainteneur snap si.
Pour les mainteneurs et pour les developpeurs, il n'y aura qu'une seule version a prendre en compte pour les rapports de bugs, ce qui va sincèrement simplifier les choses.
Ça ne changera strictement rien, voire ça sera encore pire.
Tu vas te retrouver avec des bugs sur la version 1.0.0 du snap qui contient un jeu de dépendances potentiellement totalement différente de la version 1.0.1.
Reproductibilité proche du néant, bissect impossible, etc.
C'est tout a fait possible et il faut évidemment le faire de manière automatisée comme déjà indique au dessus. C'est la valeur ajoutee de snap.
Pas vraiment en pratique.
Parce que ça signifie (et c’est particulièrement visible chez Docker) des Go de téléchargement chaque jour pour chaque utilisateur final…
Et aussi d’avoir des systèmes de notification si une dépendance bouge (c’est un problème difficile à résoudre et qui nécessite… de recoder un équivalent à APT !).
Si je prend l’exemple de FreeCAD, c’est (sorry pour le spam…) :
Rien que la détection d’un changement de version dans au moins une de ces dépendances pour éviter de reconstruire une image alors qu’il n’y a pas de changement, ça va être un enfer. Le yaml ne gère absolument pas ce cas actuellement et rebuildera à tous les coups sans possibilité de savoir s’il faut incrémenter la version ou non.
Autant te dire que c’est chaque jour que ton snap doit être reconstruit et poussé chez tes utilisateurs… Ils vont légèrement faire la gueule. Surtout que FreeCAD lui n’a absolument pas changé de version.
En plus si tu veux maintenir un snap pour plusieurs versions de FreeCAD, tu te tires juste une énorme balle dans le pied en terme de gestion…
Concrètement, je pense qu'avoir une version support long terme d'un paquet, va simplement consister a spécifier une branche du repo git du projet
Je ne te suis pas là… Pour l’utilisateur final, ça sera effectivement suivre my-application.latest ou my-application.esr.
Mais pour le mainteneur de l’image, c’est suivre tous les lib-xxx.{latest,esr} et reconstruire les images en conséquence.
Choisir de rester sur une version de firefox qui ne beneficie d'aucun support de la part du mainteneur ne me parait pas être une bonne pratique.
Oui et non. S’il y a des problèmes de sécurité non corrigé, il faut évidemment éviter d’utiliser cette application.
On imagine assez bien que si le mainteneur de Firefox considère avoir assez de temps disponibles pour suivre les mises-à-jour de Firefox (globalement 1 ou 2 par mois), il n’a décemment pas assez de temps pour suivre les variations de toutes les dépendances de Firefox :
Si une seule de ces dépendances bougent, en particulier pour raison de sécurité, le mainteneur doit reconstruire une image… Autant te dire que c’est juste impossible à faire…
Et du coup, tu peux vouloir rester sur un Firefox 44, toujours maintenu par le mainteneur de Firefox, mais plus maintenu par le mainteneur du container parce qu’il est dans l’impossibilité de continuer à suivre X versions de Firefox (il passe déjà sa vie à refaire des images pour la dernière version, il ne va pas en passer une 2nde pour une autre…).
La responsabilité vient de l'empaqueteur qui lors d'une mise à jour de sécurité d'une dépendance doit mettre à jour la dépendance
J’avais raté ce gros détail au passage. C’est justement là-dessus que snap et docker rendent les choses infectes.
Actuellement sous Debian, si la libc6 est impactée par une maj de sécurité, c’est au mainteneur de libc6 de faire le correctif et de déployer sa nouvelle version. Il n’y a donc qu’un seul travail à faire pour patcher l’ensemble de ta distribution.
En plus, étant un patch de sécurité, les risques de régression applicatives restent rares, les mainteneurs des applications n’auront à agir qu’en cas de réels problèmes de compatibilités.
Sous snap/docker, cette étape ne suffit plus et il faut que le mainteneur de chaque application corrige ses dépendances, rebuild ses images et les redéploie. La faille de sécurité va avoir une longue traîne avant correction, les images peu/pas maintenue allant rester à poil longtemps.
.deb = 1 mainteneur, toutes les applications fixées.
.snap/.docker = n+1 mainteneurs (1 lib + n container) = n applications fixées
Oula ça c'est toi qui l'affirme. Le bug peu impacter le design, la correction peu avoir des effets de bords mal maitrisé,…
Pour des correctifs de sécurité, non. Ou en tout cas ce n’est pas censé se produire, sauf bug de sécu très intrusif.
Une redbuild d'une image ne demande pas nécessairement de monté de version
Upstream si.
Avec les .deb, la plupart des dépendances sont indiquées en >=, donc la mise-à-jour de sécurité ne nécessite pas de mise-à-jour de l’application.
Par exemple firefox 46.0.1-1 sous Debian déclare libc6 (>= 2.17), utilisant actuellement libc6 2.22-9. Un bug critique dans la libc fera que Debian déploiera libc6 2.22-10, ce qui ne nécessitera aucune mise-à-jour de Firefox, la version déclarées étant compatible avec la version installée. Firefox restera donc en version 46.0.1-1.
Avec snap ou docker, la version de ton image doit être décorrélée de la version de ton application.
En effet, si tu livres une image firefox 46.0.1-1 + libc6 2.22-9 en version 1.0.0, une correction sur la libc nécessite de monter de version ton image, puisque tu livreras une image firefox 46.0.1-1 + libc6 2.22-10 versionnée 1.0.1. Et ce sont toutes tes images contenant libc6 2.22-9 qui vont devoir se prendre une montée de version.
Côté upstream, j’imagine assez mal le mainteneur maintenir chaque image firefox XXX + libc6 last-stable-compatible, il y a de fortes chances qu’il s’en tienne à uniquement firefox last-stable + libc6 last-stable-compatible. Tu peux donc te retrouver avec un saut de version non contrôlé de Firefox (du genre tu es resté à firefox 44 en prod) pour pouvoir gérer un bug critique sur la libc…
Un véritable enfer à gérer en perspective…
Tout le problème est justement là.
Ce n’est pas de la responsabilité de l’utilisateur d’une image docker/snap/vagrant/whatever de reconstruire l’image. Et donc il est à 100% dépendant d’un fix upstream. Fix qui arrivera de toute façon trop tard, s’il arrive un jour.
Un bug OpenSSL, c’est quelques heures avant d’avoir un fix et au mieux 24h pour qu’il soit dispo dans la distribution de ton choix et donc toutes tes applications à l’abri, sans montée de version de l’application elle-même donc sans gros risque de régression.
Avec la containeurisation ambiante, il faudra attendre que toutes tes applications aient été reconstruites et redéployées, avec généralement une montée de version (je vois mal l’upstream se taper un rebuild de 4 ou 5 versions différentes juste pour y changer libssl.so) donc des régressions potentielles.
Si tu es safe en moins d’un mois, je te tire mon chapeau…
L'autre problème auquel nous sommes confrontés en tant que communauté c'est la disparité des bibliothèques et des versions qui peuvent exister entre les systèmes des membres d'une même communauté. Ces disparités peuvent engendrer des problèmes de compatibilité notamment lorsque les logiciels sont en développements actifs.
J’ai une question à ce sujet, parce que j’ai l’impression que snap va avoir exactement le même problème que docker à ce niveau. Comment se passe les mises-à-jour de sécurité en cas de faille dans une des bibliothèques utilisées par les snap ?
Les « problèmes » de compatibilité étant généralement dus à la mise à disposition d’une unique version des bibliothèques pour toutes les applications, ça facilite aussi grandement le travail en cas de faille, puisqu’il suffit de mettre à jour uniquement la bibliothèque pour protégér l’ensemble du système.
Sur snap, si je lis entre les lignes, ça signifie que les bibliothèques se retrouvent dupliquées, potentiellement en version différente entre chaque application, donc qu’aucune mise-à-jour de sécurité n’est possible et qu’il faut attendre le bon vouloir des mainteneurs d’une application pour être mis à l’abri. Et qu’en plus de ça, en cas de faille de sécurité, c’est l’ensemble des applications de ton système qu’il faut mettre à jour.
Comment ? Parce que par définition, l'ARP ne sort pas du LAN.
L’ARP ne sort pas du LAN, mais le poisonning peut venir d’en dehors du LAN.
Aucun de ces projets ne parle d'ARP, sauf si j'ai loupé un truc.
Ce n’est pas de l’ARP spoofing à proprement parlé, mais ça fait des trucs tout aussi dégeu sur plus ou moins toutes les couches du réseau (TCP, DNS, routage, web, JS…).
J’ai aussi oublié, dans le cadre de Google justement, le programme MUSCULAR, et sa célèbre image du bidouillage de la NSA sur le LAN de Google en vue de se placer sur les nœuds d’interco des datacenters (corrigé depuis par Google via du chiffrement y compris en échange interne). Donc non, ton LAN n’est pas plus safe que le reste :)
Ça, ça ne dépend que de toi. Par exemple, Google prévient quand il ne sait pas faire de TLS (enfin, c'est en cours de dépoiement).
C’est une rustine qui n’a aucun sens technique.
Tu ne peux PAS savoir à l’avance si chiffrement il y aura ou non.
Ce n’est pas parce que le message précédent a été chiffré que le tien le sera.
Tu peux tomber sur un MX différent, non sécurisé.
Tu peux tomber sur un bout de réseau soumis à STARTTLS-drop (par exemple via un routeur turc) alors que les précédents étaient clean.
Tu peux tomber pile au moment où les admins sys du destinataire se sont gauffrés sur la config du serveur, en ont mis un nouveau mal configuré, ont une panne qui fera que tu passeras sur leur secondaire bien moins sécurisé, etc.
Bref, ce n’est pas parce que tu vois un cadenas rouge que ça partira en clair, et inversement un cadenas vert ne te garantit absolument pas que ça sera chiffré.
Le seul moyen de réellement t’assurer de la sécurité… c’est d’avoir déjà envoyé ton mail !
Donc, pourquoi tu parle de ARP poisining ?
Parce que tu peux faire du ARP poisining même en dehors de ton LAN ?
Qu'ils interceptent le trafic avec l'aide des transitaires, je veux bien. Mais qu'il viennent faire de l'ARP poisining chez moi, j'ai comme un doute.
Faut arrêter les conneries : d'accord les CA ne sont pas terribles, mais dire que ça n'apporte aucune sécurité est du mensonge (il y a un différence énorme quand même entre signé par soit même et signé par une CA reconnue comme relativement fiable par ton navigateur ou OS, nier cette différence et dire que les CA accepteront Mallory tranquille est du pur troll)
Dans le cas de SMTP (et uniquement dans ce cas), les CA sont sans intérêt.
La présence des MX et de STARTTLS, qui ne sont PAS authentifiés (sauf si MX protégé par DNSSec ET MTA émetteur vérifiant DNSSec ET ne fallbackant pas en clair en cas d’erreur, soit 0.0000001% des cas), casse toute possibilité de confiance en SMTP+STARTTLS. Le seul intérêt est de chiffrer (un tiers autre que le serveur en face n’accédera pas aux données), non d’authentifier (je cause avec le bon tiers).
Si tu es en position de faire du MITM, alors tu ne t’attaqueras pas au certificat, mais tu usurperas un MX ou tu vireras STARTTLS (93% du trafic SMTP, y compris vers Google, est downgradé en plain/text si tu es en Turquie par exemple).
Pas convaincu, il y a vraiment des algos trop faciles à casser pour ne pas les virer, ça donne juste un faux sentiments de sécurité. Qu'on soit plus tolérant qu'en HTTPS, je comprends, mais sinon il vaut mieux faire un fallback en clair, quitte à avoir une alerte à ce niveau pour s'en rendre compte.
Le problème est que justement, on n’a AUCUN alerte.
Et il vaudra toujours mieux avoir du chiffrement, aussi pourri soit-il que pas de chiffrement du tout.
Il y a DNSSEC pour ça
Oui, mais combien le déploie ?
Si tu n'as pas confiance dans ton lan, ce n'est pas SMTP le problème.
Là on cause MTA vers MTA, donc c’est tout sauf du LAN.
La NSA s’amuse à faire ce genre de truc niveau réseau mondial.
Une attaque passive n’est pas facilitée ou non par le CN ou SAN du certificat. Le simple fait d’avoir du chiffrement suffit (et du coup il vaut mieux ne pas faire de vérification et avoir une couche de chiffrement que de faire la vérif et de fallback en clair).
Si on est actif, SMTP est fucked de base :
DNS spoof pour hijacker le MX
ARP spoof pour hijacker le serveur
Pas de vérification du domaine et des CA
STARTTLS non authentifié (dropper les paquets contenant « STARTTLS » suffit à faire une downgrade attack vers plain/text, très utilisé en Turquie par exemple (96% du traffic se fait downgrader)).
Oui mais ça n’a aucun intérêt en terme de sécurité.
L’interdiction de vérifier la chaîne de certification fait que n’importe qui peut fournir un certificat contenant un CN ou SAN valide pour le domaine en question (et conduira au mieux à renvoyer en plain/text par derrière si tu fais la vérification du CN/SAN, ce qui est encore pire…).
D'autre part, ma réelle inquiétude est de savoir jusqu'où Google compte aller. Il n'y a qu'un pas à franchir entre afficher une alerte parce que le serveur du correspondant n'utilise pas du tout TLS, et parce qu'il utilise un certificat auto-signé
Sois rassuré sur ce point, Google ne peut tout simplement pas virer les connexions qui utiliseraient un certificat auto-signé. Ils ne peuvent même pas bloquer un certificat qui ne correspondrait pas au domaine en question.
Parce qu’on ne sait pas valider un certificat pour STARTTLS.
Et que les RFC sont très claires (par exemple RFC 7672, on ne doit chercher à vérifier ni la chaîne de certification ni le domaine).
Le domaine tout simplement parce qu’on ne sait pas décider quoi valider.
Comme on passe par les MX, un domaine @xxx.fr peut avoir un MX en yyy.fr.
On s’attend à quoi quand on va lancer la connexion STARTTLS dans le certificat ? xxx.fr ou yyy.fr ?
Se pose aussi le problème (et en particulier pour Google lui-même justement) qu’un même serveur mail peut servir X domaines différents (c’est le cas des serveurs de Google, ils hébergent @lemonde.fr par exemple), et que le certificat présenté peut ne pas être valide pour le domaine du destinataire (si tu écris à @lemonde.fr, tu recevras un certificat en mx.google.com).
Et la chaîne de confiance non plus n’est pas vérifiable. Le RFC 7672 indique bien
SMTP client MTAs cannot be expected to be configured with a suitably complete set of trusted public CA
Ici, c’est surtout parce que SMTP est opportuniste. Si l’établissement de la connexion TLS échoue, l’émetteur retente avec une connexion plain/text.
On a donc intérêt à être le plus laxiste possible et à autoriser tout et n’importe quoi (y compris SSLv2/SSLv3, RC4, DES ou pire, un certificat expiré, de domaine invalide ou de CA inconnue) afin d’obtenir au moins la sécurité du tuyau (la sécurité du destinataire n’est pas possible avec SMTP sans DNSSec et TLSA) plutôt que pas de sécurité du tout.
Google ne peut donc pas se permettre de blacklister un serveur qui aurait un certificat invalide (self-signed ou domaine invalide).
Let’s Encrypt n’a aucun intérêt ici, la chaîne de validation ne peut ni ne doit être vérifié.
Un certificat auto-signé fera parfaitement l’affaire sans diminuer la sécurité, sauf à intégrer DNSSec et DANE/TLSA, mais alors Let’s Encrypt devient un enfer sur Terre, puisque RFC 7672 indique qu’on ne peut pinner que sur le certificat ou sur la clef (CA ou intermédiaire explicitement interdits sur SMTP), qui sont par défaut renouvelés tous les 90j et posent donc de gros problèmes d’intégration avec DNSSec.
Oui et non.
Il te signale qu’il n’a jamais vu ce serveur et demande donc à (re)vérifier la clef.
Tu peux simplifier la vérification (et la rendre indépendante de l’IP) via SSHFP et ton DNS.
Du point de vue réseau, un hidden service n’a même plus d’IP (c’est tout le but de la manœuvre). Donc pas de soucis ni de risque particulier, même sur une connexion avec IP changeante ou redémarrage du client Tor.
(De base SSH n’est de toute façon pas impacté par un changement d’IP)
[^] # Re: Debian Wheezy / Hibernation: Retour d'expérience
Posté par Aeris (site web personnel) . En réponse au journal Volumes logiques et chiffrement : vos solutions ?. Évalué à 6.
Je préfère ma méthode : https://blog.imirhil.fr/2014/04/29/dechiffrer-plusieurs-luks.html
Elle n’est pas passwordless mais n’en nécessite qu’un seul pour déverrouiller tous les disques et elle a l’avantage de ne pas avoir la clef de déverrouillage en clair sur un support, même USB :P
[^] # Re: Vision stratégique
Posté par Aeris (site web personnel) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 2.
Elle peut aussi te fournir gratuitement un cozy minimaliste par défaut, en te laissant le choix d’utiliser un autre cozy (auto-hébergé, hébergé ou prestataire) si tu le souhaites.
[^] # Re: Vision stratégique
Posté par Aeris (site web personnel) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à -1. Dernière modification le 21 juillet 2016 à 11:08.
Je ne vois pas l’incompatibilité avec les 2…
Que ton Cozy soit chez toi, chez un partenaire ou hébergé en propre par CozyCloud, le fonctionnement décrit plus haut reste le même : récupérer toutes tes données, les mettre sur ton Cozy pour y faire de la « small data » personnelle.
Le « nous » est à prendre au sens « les utilisateurs ». L’intégralité des accès et émissions de données est logguée dans le Cozy de l’utilisateur, qui peut y accéder pour voir si une application fait un usage abusif ou interdit des données.
L’hébergeur/partenaire n’a pas accès à ces logs (légalement et contractuellement en tout cas, techniquement un tiers technique fait tout ce qu’il veut, il a accès aux machines :P)
[^] # Re: La version officielle
Posté par Aeris (site web personnel) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à -2.
Quand des frangins ne sont pas d’accords, ils demandent aux parents de trancher.
Qu’ils aient 4 millions d’euro ou des nèfles, ça ne change pas grand chose au problème, ça reste des parents qui cherchent la meilleure décision pour la famille (et pas que pour eux-mêmes).
# Totalement impossible
Posté par Aeris (site web personnel) . En réponse au journal authentification et certification de contenu de courriel ?. Évalué à 7. Dernière modification le 07 juin 2016 à 18:28.
DKIM, SPF & DMARC n’autorisent qu’une vérification a priori de la validité d’un mail. C’est impossible de s’en servir pour une vérification a posteriori (ie comme preuve future), sauf à conserver la preuve de la validité de la vérification de ces mécanismes lors de la réception.
Ce qui sur le papier me semble encore plus impossible qu’une validation a priori certifiée. Il faudrait sauvegarder l’état du DNS (SPF, DKIM, DMARC, MX, IP…), des clefs DKIM utilisées, des IP de réception, du registre du personnel, du propriétaire du domaine… le tout de manière certifiée elle-aussi.
On peut en effet très bien imaginer recevoir un mail légitime qui passe l’ensemble des validations à l’instant T, mais qui ne peut plus être vérifié à l’intant T+1 (changement de clef DKIM ou de SPF suite à refonte de l’infra informatique par exemple).
Ou inversement un mail illégitime à l’instant T mais dont l’attaquant fera le nécessaire le jour où il aura besoin de s’assurer de la validité de cette preuve (usurpation DNS, etc).
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 5.
Si tu as de la compilation reproductible, oui.
Sinon, tu peux avoir 2 checksums différents mais le même binaire quand même (même versions de libs, même version d’application, mais un truc qui a changé entre les 2, par exemple la date de build dans une entête d’archive…).
C’est un problème à part entière et même Debian ne parvient pas encore au 100% reproductible.
C’est exactement mon propos.
Tu vas te retrouver chaque jour avec une v1.0.n+1 dont tu n’as absolument aucune idée si c’est techniquement une vraie v1.0.n+1 (une lib a bougé depuis) ou juste une v1.0.0 rebuildé (aucune modif de lib).
Et donc si tu dois la pousser à tes utilisateurs ou non.
Je ne vois pas le rapport avec ce que j’annonce.
Oui bien sûr que OpenSSL va se prendre une maj de sécu par jour voire plus.
Ce n’est pas une raison pour que le paquet de Firefox ou de FreeCAD le soit justement !!! Et c’est même un comportement que tu ne souhaites absoluement pas avoir…
Actuellement, si OpenSSL publie 5 maj de sécu en 1 semaine, je maj 5 fois OpenSSL. Et c’est tout !!!
Avec Snap, comme ma dépendance foireuse est dans quasi toutes mes applications, ça va soit me laisser à poil jusqu’à ce que le mainteneur du snap décide d’intégrer la version d’OpenSSL corrigée, soit ça va me faire aussi 5 maj de mon appli snap.
En pratique, là où aujourd’hui un fix de sécu se résume à upgrader une seule lib et à oublier cette faille définitivement, snap va être une bouse infecte qui va nécessiter de se poser la question de quelles applications intègrent quelles versions de OpenSSL, de mettre à jour l’ensemble de tes applications impactées, et à devoir surveiller ton système avec une très longue traîne de faille le temps que tous tes mainteneurs snap aient fait leur travail d’intégration.
Sur des fixs de sécurité, c’est quasi impossible, et en tout cas ça ne vaut clairement pas la chandelle du risque de sécurité introduit par snap.
Tu échanges un potentiel risque de régression jamais atteint en pratique ou qu’à la marge, contre un risque avéré de dépréciation progressive des bibliothèques installées sur ta machine et donc soumises à faille de sécurité.
Je met à jour chaque jour à gros coup de apt dist-upgrade, je n’ai connu qu’un seul down de prod (à l’arrivée de systemd).
apt est très robuste de ce côté et Debian suffisamment soigneux avec ses paquets pour éviter le dawa.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 5.
On s’en tape de la reproductibilité si c’est pour monter une armée de botnet en 1 mois. La sécu avant tout SVP…
Non, je n’ai pas ça en prod. Je n’ai pas 180 versions de FreeCAD. Si FreeCAD ne bouge pas, il n’est pas mis à jour.
Et de grosse terrachiés de bugs et failles non corrigés…
Et donc ? Les Snap deviennent un apt dist-upgrade remote ?
Intérêt par rapport à APT si mon FreeCAD est mis-à-jour 1 jour sur 2 avec des dépendances non maîtrisées ? Ça casse complètement l’intérêt que vous vendez de Snap là…
Snap n’est intéressant que si tes utilisateurs passent leur vie à poil sur leurs machines… Comme Docker, Go et plus généralement tout ce qui cherche à figer plus ou moins définitivement l’environnement, ce qui est un énorme problème de sécurité et une véritable bombe à retardement dégoupillée…
On va juste bien rigoler au prochain Heartbleed ou random-42 like tient…
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 3.
La containerisation est intéressante pour le dev, ça c’est indéniable.
Ça évite de péter son système principal et ça permet de conserver des environnements stables même si on développe sur plusieurs environnements en parallèle (du genre des projets qt4 et qt5).
Ou d’installer aux forceps de vieilles ou trop récentes versions de dépendances.
Ce n’est actuellement pas du tout le cas et c’est un problème compliqué à résoudre.
Tu lances ta commande, tu obtiens un binaire. Est-ce le même qu’hier ? Tu es incapable de le dire. As-tu buildé une v1.0.0 ou une de tes dépendances a-t-elle bougée et tu as alors compilé une v1.0.1 malgré que tu aies indiqué v1.0.0 dans ton fichier de build ?
La seule manière viable de procéder est de générer la liste des dépendances dynamiquement chaque jour, de vérifier si elle a bougé depuis hier (hint : c’est statistiquement le cas) et si c’est le cas, de lancer un nouveau build du snap en incrémentant sa révision, snap qui ne partage potentiellement plus grand chose comme dépendances par rapport à la version d’il y a 1 semaine.
Et alors tu t’éloignes bien loin de la joie annoncée en début de journal de la stabilité et maîtrise de ton système…
Pour l’exemple de FreeCAD, ça donne par exemple plus de 180 versions sur 1 an, dont les dépendances divergent rapidement passées 1 semaine d’écart.
Juste ça en prod, tu oublies. Vraiment.
Les autres manières de procéder impliquent le gel sur un terme plus ou moins long des dépendances et donc d’exposer ses utilisateurs à des failles ou des bugs.
On imagine assez bien un mainteneur n’upgradant ses dépendances qu’avec une nouvelle release upstream de l’application principale, laissant un trou béant entre deux. Et à l’inverse assez mal le mainteneur de FreeCAD se dire « Oh , un heartbleed sauvage apparaît. FreeCAD snap, en avant ! ».
Et c’est totalement compréhensible, il est responsable de la maintenance de FreeCAD. Ni de OpenSSL, ni de la libc, ni de DBus !!!
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 3.
Aller, je m’autocorrige un peu, mon script était un peu violent. La version correcte.
apt-rdepends freecad -f Depends | grep -v "^ " | sort -u | xargs -I {} zgrep "status installed {}:amd64" /var/log/dpkg* | awk -F: '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -rnSur 1 an et avec 52 dépendances non installées sur 432, 178 mise-à-jours, soit 1 jour sur 2.
La plus grosse, le 09/11/2015 (release Debian 8.2.0 je dirais), 254 dépendances modifiées, suivi du 03/02/2016 (Debian 8.4) avec 115 dépendances.
35 jours (soit 1 semaine sur 2 environ) avec plus de 10 mises-à-jour.
Ça ne change pas grand chose au fait que le mainteneur Snap de FreeCAD soit ne va plus avoir de vie sociale pour suivre les correctifs et décider de livrer une nouvelle version ou non, soit va livrer tous les 2 jours un Snap rebuildé « au cas où » à l’arrache à partir de l’état courant des dépôts Debian sans maîtrise de ce qu’il livre réellement.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 5.
Vu la tonne de dépendances remontée par FreeCAD, c’est au doigt mouillé mais je ne dois pas être loin du compte. La probabilité d’avoir une maj de version sur une des dépendances chaque jour est à mon avis proche de 1.
J’ai vérifié sur mon système, les dates où apt m’a fait une mise-à-jour d’une des dépendances :
apt-rdepends freecad -f Depends | grep -v "^ " | xargs -I {} zgrep {} /var/log/dpkg* | awk -F: '{print $2}' | awk '{print $1}' | sort -uSur 365 jours, 2015-06-02 au 2016-06-06 : 226 mises-à-jour.
Et encore, ça ne concerne que les dépendances actuellement installées sur mon système, il m’en manque 52 sur les 432.
Mais je te concède sans soucis le jour sur 3 qui ne connaît pas de mise-à-jour…
Dans tous les cas, ça confirme bien le problème : tu vas devoir livrer chaque jour un paquet Snap FreeCAD sous peine de rendre obsolètes tes utilisateurs…
Et avec un enfer de dépendances différentes chaque jour.
Mon script y va peut-être avec de gros doigts, mais je compte 86 jours avec plus de 10 dépendances modifiés, 7 avec plus de 100 dépendances et même 2 journées avec plus de 400. Qui s’est mis à jour et pourquoi ?
Les PPA n’ont justement pas à gérer ça. Si libssl est mis à jour, FreeCAD n’a pas à être rebuildé. On ne rebuild FreeCAD que si FreeCAD change de version upstream (et on en profite au passage pour upgrader un coup les dépendances si nécessaires).
Alors que le snap va devoir être rebuildé sur chaque changement de version de FreeCAD, mais aussi de n’importe laquelle de ses dépendances, y compris récursives.
C’est effectivement le taff actuel des PPA. Ce n’est pas du tout le même genre ni volume de travail qui attend un mainteneur Snap.
Si tu es mainteneur PPA, tu n’as pas à te soucier de la maintenance de tes dépendances, si tu es mainteneur snap si.
Ça ne changera strictement rien, voire ça sera encore pire.
Tu vas te retrouver avec des bugs sur la version 1.0.0 du snap qui contient un jeu de dépendances potentiellement totalement différente de la version 1.0.1.
Reproductibilité proche du néant, bissect impossible, etc.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 5. Dernière modification le 06 juin 2016 à 13:21.
Pas vraiment en pratique.
Parce que ça signifie (et c’est particulièrement visible chez Docker) des Go de téléchargement chaque jour pour chaque utilisateur final…
Et aussi d’avoir des systèmes de notification si une dépendance bouge (c’est un problème difficile à résoudre et qui nécessite… de recoder un équivalent à APT !).
Si je prend l’exemple de FreeCAD, c’est (sorry pour le spam…) :
coreutils debconf debconf-2.0 debianutils dpkg fontconfig fontconfig-config fonts-dejavu-core fonts-freefont fonts-freefont-ttf fonts-liberation fonts-lyx freecad gcc-6-base install-info iso-codes liba52-0.7.4 libaa1 libasound2 libasound2-data libass5 libasyncns0 libatk1.0-0 libatk1.0-data libaudio2 libaudit1 libaudit-common libavahi-client3 libavahi-common3 libavahi-common-data libavc1394-0 libavcodec57 libavcodec-extra57 libavutil55 libbasicusageenvironment1 libblas3 libblas-common libblas.so.3 libbluray1 libboost-atomic1.58.0 libboost-chrono1.58.0 libboost-date-time1.58.0 libboost-filesystem1.58.0 libboost-program-options1.58.0 libboost-python1.58.0 libboost-regex1.58.0 libboost-signals1.58.0 libboost-system1.58.0 libboost-thread1.58.0 libbsd0 libbz2-1.0 libc6 libcaca0 libcairo2 libcap2 libcap2-bin libcddb2 libcdio13 libchromaprint0 libcoin80v5 libcomerr2 libcroco3 libcrystalhd3 libcups2 libdatrie1 libdb5.3 libdbus-1-3 libdc1394-22 libdca0 libdirectfb-1.2-9 libdrm2 libdvbpsi10 libdvdnav4 libdvdread4 libebml4v5 libegl1-mesa libegl1-x11 libevdev2 libexpat1 libfaad2 libffi6 libflac8 libfontconfig1 libfreeimage3 libfreerdp-cache1.1 libfreerdp-client1.1 libfreerdp-codec1.1 libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1 libfreerdp-gdi1.1 libfreerdp-locale1.1 libfreerdp-primitives1.1 libfreerdp-utils1.1 libfreetype6 libfribidi0 libgbm1 libgcc1 libgcrypt20 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libgfortran3 libgl1 libgl1-mesa-glx libgl2ps1 libglapi-mesa libgles1 libgles1-mesa libgles2 libgles2-mesa libglib2.0-0 libglu1 libglu1-mesa libgme0 libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2 libgraphite2-3 libgroupsock8 libgsm1 libgssapi-krb5-2 libgstreamer1.0-0 libgstreamer-plugins-base1.0-0 libgtk2.0-0 libgtk2.0-common libgudev-1.0-0 libharfbuzz0b libhogweed4 libice6 libicu55 libidn11 libilmbase12 libinput10 libinput-bin libiso9660-8 libjasper1 libjbig0 libjpeg62-turbo libjs-jquery libjs-jquery-ui libjson-c3 libjs-sphinxdoc libjs-underscore libjxr0 libk5crypto3 libkate1 libkeyutils1 libkrb5-3 libkrb5support0 liblapack3 liblapack.so.3 liblcms2-2 liblircclient0 liblivemedia52 liblua5.2-0 liblzma5 libmad0 libmatroska6v5 libmng1 libmodplug1 libmp3lame0 libmpcdec6 libmpeg2-4 libmtdev1 libmtp9 libmtp-common libncurses5 libncursesw5 libnettle6 libnuma1 liboce-foundation10 liboce-modeling10 liboce-ocaf10 liboce-ocaf-lite10 liboce-visualization10 libogg0 libopencore-amrnb0 libopencore-amrwb0 libopenexr22 libopenjp2-7 libopenjpeg5 libopus0 liborc-0.4-0 libp11-kit0 libpam0g libpam-modules libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpcre16-3 libpcre3 libphonon4 libpixman-1-0 libpng16-16 libproxy1v5 libproxy-tools libpulse0 libpulse-mainloop-glib0 libpyside1.2 libpython2.7 libpython2.7-minimal libpython2.7-stdlib libpython-stdlib libqt4-dbus libqt4-declarative libqt4-designer libqt4-help libqt4-network libqt4-opengl libqt4-script libqt4-scripttools libqt4-sql libqt4-svg libqt4-test libqt4-xml libqt4-xmlpatterns libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5widgets5 libqt5x11extras5 libqtassistantclient4 libqtcore4 libqtdbus4 libqtgui4 libqtwebkit4 libquadmath0 libraw1394-11 libraw15 libreadline6 libresid-builder0c2a librsvg2-2 librtmp1 libsamplerate0 libschroedinger-1.0-0 libsdl1.2debian libsdl-image1.2 libselinux1 libsemanage1 libsemanage-common libsepol1 libshiboken1.2v5 libshine3 libshout3 libsidplay2 libslang2 libsm6 libsnappy1v5 libsndfile1 libsndio6.1 libsoqt4-20 libsoxr0 libspeex1 libspeexdsp1 libspnav0 libsqlite3-0 libssh2-1 libssh-gcrypt-4 libssl1.0.2 libstdc++6 libswresample2 libsystemd0 libtag1v5 libtag1v5-vanilla libtasn1-6 libtcl8.6 libthai0 libthai-data libtheora0 libtiff5 libtinfo5 libtk8.6 libtwolame0 libudev1 libupnp6 libusageenvironment3 libusb-1.0-0 libustr-1.0-1 libuuid1 libva1 libva-drm1 libva-x11-1 libvcdinfo0 libvlc5 libvlccore8 libvncclient1 libvo-amrwbenc0 libvorbis0a libvorbisenc2 libvpx3 libwacom2 libwacom-common libwavpack1 libwayland-client0 libwayland-server0 libwebp5 libwebpmux1 libwinpr-crt0.1 libwinpr-crypto0.1 libwinpr-dsparse0.1 libwinpr-environment0.1 libwinpr-file0.1 libwinpr-handle0.1 libwinpr-heap0.1 libwinpr-input0.1 libwinpr-interlocked0.1 libwinpr-library0.1 libwinpr-path0.1 libwinpr-pool0.1 libwinpr-registry0.1 libwinpr-rpc0.1 libwinpr-sspi0.1 libwinpr-synch0.1 libwinpr-sysinfo0.1 libwinpr-thread0.1 libwinpr-utils0.1 libwrap0 libx11-6 libx11-data libx11-xcb1 libx264-148 libx265-79 libxau6 libxcb1 libxcb-composite0 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-present0 libxcb-randr0 libxcb-render0 libxcb-render-util0 libxcb-shape0 libxcb-shm0 libxcb-sync1 libxcb-util0 libxcb-xfixes0 libxcb-xkb1 libxcb-xv0 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxerces-c3.1 libxext6 libxfixes3 libxft2 libxi6 libxinerama1 libxkbcommon0 libxkbcommon-x11-0 libxkbfile1 libxml2 libxmu6 libxpm4 libxrandr2 libxrender1 libxshmfence1 libxslt1.1 libxss1 libxt6 libxtst6 libxvidcore4 libxxf86vm1 libzipios++0v5 libzvbi0 libzvbi-common lsb-base mime-support passwd phonon phonon-backend phonon-backend-vlc pyside-tools python python2.7 python2.7:any python2.7-minimal python:any python-collada python-cycler python-dateutil python-lxml python-matplotlib python-matplotlib-data python-numpy python-numpy-abi9 python-pivy python-ply python-pyparsing python-pyside python-pyside.phonon python-pyside.qtcore python-pyside.qtdeclarative python-pyside.qtgui python-pyside.qthelp python-pyside.qtnetwork python-pyside.qtopengl python-pyside.qtscript python-pyside.qtsql python-pyside.qtsvg python-pyside.qttest python-pyside.qtuitools python-pyside.qtwebkit python-pyside.qtxml python-qt4 python-qt4-gl python-six python-tz qdbus qtbase-abi-5-5-1 qtchooser qtcore4-l10n readline-common sensible-utils shared-mime-info sip-api-11.3 ttf-bitstream-vera tzdata ucf vlc vlc-data vlc-nox x11-common xkb-data zlib1gRien que la détection d’un changement de version dans au moins une de ces dépendances pour éviter de reconstruire une image alors qu’il n’y a pas de changement, ça va être un enfer. Le yaml ne gère absolument pas ce cas actuellement et rebuildera à tous les coups sans possibilité de savoir s’il faut incrémenter la version ou non.
Autant te dire que c’est chaque jour que ton snap doit être reconstruit et poussé chez tes utilisateurs… Ils vont légèrement faire la gueule. Surtout que FreeCAD lui n’a absolument pas changé de version.
En plus si tu veux maintenir un snap pour plusieurs versions de FreeCAD, tu te tires juste une énorme balle dans le pied en terme de gestion…
Je ne te suis pas là… Pour l’utilisateur final, ça sera effectivement suivre
my-application.latestoumy-application.esr.Mais pour le mainteneur de l’image, c’est suivre tous les
lib-xxx.{latest,esr}et reconstruire les images en conséquence.[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 4. Dernière modification le 06 juin 2016 à 12:35.
Oui et non. S’il y a des problèmes de sécurité non corrigé, il faut évidemment éviter d’utiliser cette application.
On imagine assez bien que si le mainteneur de Firefox considère avoir assez de temps disponibles pour suivre les mises-à-jour de Firefox (globalement 1 ou 2 par mois), il n’a décemment pas assez de temps pour suivre les variations de toutes les dépendances de Firefox :
coreutils debconf debconf-2.0 debianutils file-rc firefox fontconfig fontconfig-config fonts-dejavu-core fonts-freefont fonts-liberation gcc-6-base initscripts init-system-helpers insserv libasound2 libasound2-data libatk1.0-0 libatk1.0-data libaudit1 libaudit-common libavahi-client3 libavahi-common3 libavahi-common-data libbz2-1.0 libc6 libcairo2 libcomerr2 libcups2 libdatrie1 libdbus-1-3 libdbus-glib-1-2 libevent-2.0-5 libexpat1 libffi6 libfontconfig1 libfreetype6 libgcc1 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libglib2.0-0 libgmp10 libgnutls30 libgraphite2-3 libgssapi-krb5-2 libgtk2.0-0 libgtk2.0-common libharfbuzz0b libhogweed4 libhunspell-1.3-0 libice6 libicu55 libidn11 libjbig0 libjpeg62-turbo libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 liblzma5 libncurses5 libncursesw5 libnettle6 libp11-kit0 libpam0g libpam-modules libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpcre3 libpixman-1-0 libpng16-16 libprocps5 libselinux1 libsemanage1 libsemanage-common libsepol1 libsm6 libsqlite3-0 libstartup-notification0 libstdc++6 libsystemd0 libtasn1-6 libthai0 libthai-data libtiff5 libtinfo5 libustr-1.0-1 libuuid1 libx11-6 libx11-data libx11-xcb1 libxau6 libxcb1 libxcb-render0 libxcb-shm0 libxcb-util0 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxi6 libxinerama1 libxml2 libxrandr2 libxrender1 libxt6 lsb-base mount passwd perl-base procps sensible-utils shared-mime-info startpar sysvinit-core sysvinit-utils sysv-rc ttf-bitstream-vera ucf util-linux x11-common zlib1gSi une seule de ces dépendances bougent, en particulier pour raison de sécurité, le mainteneur doit reconstruire une image… Autant te dire que c’est juste impossible à faire…
Et du coup, tu peux vouloir rester sur un Firefox 44, toujours maintenu par le mainteneur de Firefox, mais plus maintenu par le mainteneur du container parce qu’il est dans l’impossibilité de continuer à suivre X versions de Firefox (il passe déjà sa vie à refaire des images pour la dernière version, il ne va pas en passer une 2nde pour une autre…).
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 5.
J’avais raté ce gros détail au passage. C’est justement là-dessus que snap et docker rendent les choses infectes.
Actuellement sous Debian, si la libc6 est impactée par une maj de sécurité, c’est au mainteneur de libc6 de faire le correctif et de déployer sa nouvelle version. Il n’y a donc qu’un seul travail à faire pour patcher l’ensemble de ta distribution.
En plus, étant un patch de sécurité, les risques de régression applicatives restent rares, les mainteneurs des applications n’auront à agir qu’en cas de réels problèmes de compatibilités.
Sous snap/docker, cette étape ne suffit plus et il faut que le mainteneur de chaque application corrige ses dépendances, rebuild ses images et les redéploie. La faille de sécurité va avoir une longue traîne avant correction, les images peu/pas maintenue allant rester à poil longtemps.
.deb = 1 mainteneur, toutes les applications fixées.
.snap/.docker = n+1 mainteneurs (1 lib + n container) = n applications fixées
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 7. Dernière modification le 06 juin 2016 à 12:00.
Pour des correctifs de sécurité, non. Ou en tout cas ce n’est pas censé se produire, sauf bug de sécu très intrusif.
Upstream si.
Avec les .deb, la plupart des dépendances sont indiquées en
>=, donc la mise-à-jour de sécurité ne nécessite pas de mise-à-jour de l’application.Par exemple
firefox 46.0.1-1sous Debian déclarelibc6 (>= 2.17), utilisant actuellementlibc6 2.22-9. Un bug critique dans la libc fera que Debian déploieralibc6 2.22-10, ce qui ne nécessitera aucune mise-à-jour de Firefox, la version déclarées étant compatible avec la version installée. Firefox restera donc en version46.0.1-1.Avec snap ou docker, la version de ton image doit être décorrélée de la version de ton application.
En effet, si tu livres une image
firefox 46.0.1-1 + libc6 2.22-9en version1.0.0, une correction sur la libc nécessite de monter de version ton image, puisque tu livreras une imagefirefox 46.0.1-1 + libc6 2.22-10versionnée1.0.1. Et ce sont toutes tes images contenantlibc6 2.22-9qui vont devoir se prendre une montée de version.Côté upstream, j’imagine assez mal le mainteneur maintenir chaque image
firefox XXX + libc6 last-stable-compatible, il y a de fortes chances qu’il s’en tienne à uniquementfirefox last-stable + libc6 last-stable-compatible. Tu peux donc te retrouver avec un saut de version non contrôlé de Firefox (du genre tu es resté àfirefox 44en prod) pour pouvoir gérer un bug critique sur la libc…Un véritable enfer à gérer en perspective…
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 10. Dernière modification le 06 juin 2016 à 10:29.
Tout le problème est justement là.
Ce n’est pas de la responsabilité de l’utilisateur d’une image docker/snap/vagrant/whatever de reconstruire l’image. Et donc il est à 100% dépendant d’un fix upstream. Fix qui arrivera de toute façon trop tard, s’il arrive un jour.
Un bug OpenSSL, c’est quelques heures avant d’avoir un fix et au mieux 24h pour qu’il soit dispo dans la distribution de ton choix et donc toutes tes applications à l’abri, sans montée de version de l’application elle-même donc sans gros risque de régression.
Avec la containeurisation ambiante, il faudra attendre que toutes tes applications aient été reconstruites et redéployées, avec généralement une montée de version (je vois mal l’upstream se taper un rebuild de 4 ou 5 versions différentes juste pour y changer libssl.so) donc des régressions potentielles.
Si tu es safe en moins d’un mois, je te tire mon chapeau…
Ça rejoint un peu ce qui est dit dans ce post : https://blog.seboss666.info/2015/04/la-situation-deplorable-des-administrateurs-systeme/
# Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 9. Dernière modification le 06 juin 2016 à 09:46.
J’ai une question à ce sujet, parce que j’ai l’impression que snap va avoir exactement le même problème que docker à ce niveau. Comment se passe les mises-à-jour de sécurité en cas de faille dans une des bibliothèques utilisées par les snap ?
Les « problèmes » de compatibilité étant généralement dus à la mise à disposition d’une unique version des bibliothèques pour toutes les applications, ça facilite aussi grandement le travail en cas de faille, puisqu’il suffit de mettre à jour uniquement la bibliothèque pour protégér l’ensemble du système.
Sur snap, si je lis entre les lignes, ça signifie que les bibliothèques se retrouvent dupliquées, potentiellement en version différente entre chaque application, donc qu’aucune mise-à-jour de sécurité n’est possible et qu’il faut attendre le bon vouloir des mainteneurs d’une application pour être mis à l’abri. Et qu’en plus de ça, en cas de faille de sécurité, c’est l’ensemble des applications de ton système qu’il faut mettre à jour.
Est-ce que je me trompe ?
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 1. Dernière modification le 20 février 2016 à 21:08.
L’ARP ne sort pas du LAN, mais le poisonning peut venir d’en dehors du LAN.
Ce n’est pas de l’ARP spoofing à proprement parlé, mais ça fait des trucs tout aussi dégeu sur plus ou moins toutes les couches du réseau (TCP, DNS, routage, web, JS…).
J’ai aussi oublié, dans le cadre de Google justement, le programme MUSCULAR, et sa célèbre image du bidouillage de la NSA sur le LAN de Google en vue de se placer sur les nœuds d’interco des datacenters (corrigé depuis par Google via du chiffrement y compris en échange interne). Donc non, ton LAN n’est pas plus safe que le reste :)
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 1. Dernière modification le 20 février 2016 à 17:41.
C’est une rustine qui n’a aucun sens technique.
Tu ne peux PAS savoir à l’avance si chiffrement il y aura ou non.
Ce n’est pas parce que le message précédent a été chiffré que le tien le sera.
Tu peux tomber sur un MX différent, non sécurisé.
Tu peux tomber sur un bout de réseau soumis à STARTTLS-drop (par exemple via un routeur turc) alors que les précédents étaient clean.
Tu peux tomber pile au moment où les admins sys du destinataire se sont gauffrés sur la config du serveur, en ont mis un nouveau mal configuré, ont une panne qui fera que tu passeras sur leur secondaire bien moins sécurisé, etc.
Bref, ce n’est pas parce que tu vois un cadenas rouge que ça partira en clair, et inversement un cadenas vert ne te garantit absolument pas que ça sera chiffré.
Le seul moyen de réellement t’assurer de la sécurité… c’est d’avoir déjà envoyé ton mail !
Parce que tu peux faire du ARP poisining même en dehors de ton LAN ?
Turmoil https://nsa.imirhil.fr/pages?filter=turmoil&size=10
Turbine https://nsa.imirhil.fr/pages?filter=turbine&size=10
Discoroute https://nsa.imirhil.fr/pages?filter=discoroute&size=10
Quantum https://nsa.imirhil.fr/pages?filter=quantum&size=10
Foxacid https://nsa.imirhil.fr/pages?filter=foxacid&size=10
[^] # Re: cacert ?
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 2.
Dans le cas de SMTP (et uniquement dans ce cas), les CA sont sans intérêt.
La présence des MX et de STARTTLS, qui ne sont PAS authentifiés (sauf si MX protégé par DNSSec ET MTA émetteur vérifiant DNSSec ET ne fallbackant pas en clair en cas d’erreur, soit 0.0000001% des cas), casse toute possibilité de confiance en SMTP+STARTTLS. Le seul intérêt est de chiffrer (un tiers autre que le serveur en face n’accédera pas aux données), non d’authentifier (je cause avec le bon tiers).
Si tu es en position de faire du MITM, alors tu ne t’attaqueras pas au certificat, mais tu usurperas un MX ou tu vireras STARTTLS (93% du trafic SMTP, y compris vers Google, est downgradé en plain/text si tu es en Turquie par exemple).
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 1.
Le problème est que justement, on n’a AUCUN alerte.
Et il vaudra toujours mieux avoir du chiffrement, aussi pourri soit-il que pas de chiffrement du tout.
Oui, mais combien le déploie ?
Là on cause MTA vers MTA, donc c’est tout sauf du LAN.
La NSA s’amuse à faire ce genre de truc niveau réseau mondial.
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 2.
Une attaque passive n’est pas facilitée ou non par le CN ou SAN du certificat. Le simple fait d’avoir du chiffrement suffit (et du coup il vaut mieux ne pas faire de vérification et avoir une couche de chiffrement que de faire la vérif et de fallback en clair).
Si on est actif, SMTP est fucked de base :
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 1. Dernière modification le 15 février 2016 à 11:29.
Oui mais ça n’a aucun intérêt en terme de sécurité.
L’interdiction de vérifier la chaîne de certification fait que n’importe qui peut fournir un certificat contenant un CN ou SAN valide pour le domaine en question (et conduira au mieux à renvoyer en plain/text par derrière si tu fais la vérification du CN/SAN, ce qui est encore pire…).
# Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 8. Dernière modification le 15 février 2016 à 00:03.
Sois rassuré sur ce point, Google ne peut tout simplement pas virer les connexions qui utiliseraient un certificat auto-signé. Ils ne peuvent même pas bloquer un certificat qui ne correspondrait pas au domaine en question.
Parce qu’on ne sait pas valider un certificat pour STARTTLS.
Et que les RFC sont très claires (par exemple RFC 7672, on ne doit chercher à vérifier ni la chaîne de certification ni le domaine).
Le domaine tout simplement parce qu’on ne sait pas décider quoi valider.
Comme on passe par les MX, un domaine @xxx.fr peut avoir un MX en yyy.fr.
On s’attend à quoi quand on va lancer la connexion STARTTLS dans le certificat ? xxx.fr ou yyy.fr ?
Se pose aussi le problème (et en particulier pour Google lui-même justement) qu’un même serveur mail peut servir X domaines différents (c’est le cas des serveurs de Google, ils hébergent @lemonde.fr par exemple), et que le certificat présenté peut ne pas être valide pour le domaine du destinataire (si tu écris à @lemonde.fr, tu recevras un certificat en mx.google.com).
Et la chaîne de confiance non plus n’est pas vérifiable. Le RFC 7672 indique bien
Ici, c’est surtout parce que SMTP est opportuniste. Si l’établissement de la connexion TLS échoue, l’émetteur retente avec une connexion plain/text.
On a donc intérêt à être le plus laxiste possible et à autoriser tout et n’importe quoi (y compris SSLv2/SSLv3, RC4, DES ou pire, un certificat expiré, de domaine invalide ou de CA inconnue) afin d’obtenir au moins la sécurité du tuyau (la sécurité du destinataire n’est pas possible avec SMTP sans DNSSec et TLSA) plutôt que pas de sécurité du tout.
Google ne peut donc pas se permettre de blacklister un serveur qui aurait un certificat invalide (self-signed ou domaine invalide).
Let’s Encrypt n’a aucun intérêt ici, la chaîne de validation ne peut ni ne doit être vérifié.
Un certificat auto-signé fera parfaitement l’affaire sans diminuer la sécurité, sauf à intégrer DNSSec et DANE/TLSA, mais alors Let’s Encrypt devient un enfer sur Terre, puisque RFC 7672 indique qu’on ne peut pinner que sur le certificat ou sur la clef (CA ou intermédiaire explicitement interdits sur SMTP), qui sont par défaut renouvelés tous les 90j et posent donc de gros problèmes d’intégration avec DNSSec.
[^] # Re: quid de la verification de l'identité
Posté par Aeris (site web personnel) . En réponse au message Exposer SSH via un service tor, bonne ou mauvaise idée ?. Évalué à 1.
Oui et non.
Il te signale qu’il n’a jamais vu ce serveur et demande donc à (re)vérifier la clef.
Tu peux simplifier la vérification (et la rendre indépendante de l’IP) via SSHFP et ton DNS.
[^] # Re: quid de la verification de l'identité
Posté par Aeris (site web personnel) . En réponse au message Exposer SSH via un service tor, bonne ou mauvaise idée ?. Évalué à 3.
Du point de vue réseau, un hidden service n’a même plus d’IP (c’est tout le but de la manœuvre). Donc pas de soucis ni de risque particulier, même sur une connexion avec IP changeante ou redémarrage du client Tor.
(De base SSH n’est de toute façon pas impacté par un changement d’IP)