oinkoink_daotter a écrit 1695 commentaires

La distrib de chauvounet< il me semble. Du coup, je ne comprends pas trop le thread /o\

Justement, jusqu'à preuve du contraire, ce que font les américains aux personnes physiques ne s'applique pas aux filiales des personnes morales. Sinon Apple, n'aurait pas de soucis avec ses 70myars de dollars qui sont aux frais aux bahamas, l'IRS se serait déjà servie.

L'argent sort de France il est taxe.

Et comment tu gères les virements entre deux filiales de la même boîte entre deux pays ?

La justice qui se dit submergé de boulot, je lui propose un truc: virer les avocats qui deposent ce genre de plainte pour attaques frivoles.

Ca c'est un bon argument marinelepenesque, justement : "le bon sens paysan"… Le truc c'est que sauf à te résoudre à l'arbitraire "ah oui, mais ça non, c'est des conneries, tant pis pour ta gueule", il n'y a pas moyen de ne pas traiter toutes les plaintes. Quitte à prévoir le coup d'après (dénonciation calomnieuse, abus, etc).

Ensuite, il n'y a pas besoin d'un avocat pour déposer une plainte.

Par contre, il y a des policiers qui décident ou non de prendre une plainte. Ca, c'est illégal.

Oui, mais non, ce n'est pas si simple.
Il existe plein de façons pour une cochonnerie de bypasser l'UAC, et un clic malheureux est de toute façon possible (Windows 7 a rendu le truc plus tolérable, genre quand tu bricoles dans program files, il ne te demande pas systématiquement de valider un popup UAC, par exemple si tu crées un répertoire et que tu le renommes ensuite. De mémoire vistouille était relou la dessus).

Donc du coup, les best practices, ca reste quand même de considérer qu'un gars qui a les droits admin est admin et qu'il vaut mieux avoir un compte normal normal et un compte admin considéré admin admin par personne. (pis des comptes nominatifs, des GPO pour l'audit et les logs, une forêt d'admin, … et on va s'arrêter là /o\).

C'est un long article pour expliquer qu'il faut créer une clef dans la BDR qui s'appelle HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoRebootWithLoggedOnUsers de type DWORD à 1. Ce n'est pas la mort, pas spécialement dangereux si tu ne fais pas n'imp (genre la roulette russe à supprimer des clefs au hasard) mais pas nécessairement à la portée de tout le monde.
L'article ne dit pas que c'est dangereux.

Mais tu aurais pu vérifier ça en un clic.

Pour le 1) c'est le cas de tout truc normatif d'origine administrative. Ce n'est pas choquant en soi. On a la même avec le contrôle technique ou les normes anti pollution.
Pour le 2) au delà du fond, sur lequel on note effectivement un mouvement assez généralisé de transfert de responsabilité de l'autorité judiciaire à des machins Administratifs et un renversement de la charge de la preuve sur certaines choses, sur la forme tu prends le problème Hadopi par le mauvais bout.
La logique est :
1. Tu télécharges comme un goret sur ta ligne
2. Tu te fais toper par TMG qui donne ton dossier à Hadopi
3. Comme on est incapable de prouver que tu as fait une contrefaçon car on ne sait pas qui était derrière ta ligne lorsque ça s'est produit, mais qu'on est quand même globalement sûr que ça vient de chez toi
4. On crée un délit de non sécurisation de ton accès internet parce que tu as laissé une contrefaçon se produire depuis ton accès.

Tu n'es pas coupable de contrefaçon mais de non sécurisation, ce qui n'est pas puni des mêmes peines (artillerie lourde d'un côté, contre contravention de 5eme classe et privation d'internet d'un mois en continuant à le payer de l'autre). Sachant que je n'ai jamais rien vu qui dise que tu ne puisses pas te manger la triple peine (amende, coupage d'internet et poursuite au pénal dans un vrai procès) dans tout le fatras législatif qui a été commis à cette occasion.

Je trouve ça à la dois tordu et lumineux.

Je pense que le truc est notamment ciblé contre le mode training des caisses. Ça correspond avec le machin W9 que j'ai vu il y a quelques semaines. Sur les caisses il y a(vait) un mode d’entrainement pour les caissiers dont le but est de permettre aux gens de maniper la machine sans fusiller la caisse. Toute l'idée est de faire en sorte que la machine puisse passer en mode training sans l'afficher en gros sur le ticket de caisse. Ce qui permet d'oublier certaines écritures en tapotant une séquence de touches ou en tournant une clef pour passer d'un mode à l'autre .

Et ça, ça ne se gère pas avec une écriture en ROM ou une imprimante.

Pas toujours, surtout en première instance.

Dernier exemple en date à ma connaissance : le parquet qui se pourvoit en cassation suite à relaxe en appel des "responsables" d'un groupe facebook qui indiquait la position des radars en Aveyron. Le parquet estime que c'est un dispositif de contournement de (…) au titre de l'article R413-15 du code de la route (sur les avertisseurs de radar). Il me semble pourtant qu'il était bien prévu dans les débats que ça ne touche que les devices.
référence : http://www.ladepeche.fr/article/2015/09/25/2184559-proces-des-antiradars-de-facebook.html

M'enfin, on va voir aussi ce que ça va donner lors du procès Marine Le Pen (s'il y en a un) sur les photos publiées dernièrement. L'instruction est a priori aujourd'hui adossée à un texte fait pour lutter contre le happy slapping (images violentes visibles par un mineur).

Par contre, à ma connaissance, une chose est sûre, on ne peut pas poursuivre sur un truc qui n'est pas dans la lettre.

Pour que le procédé commence à être un peu pertinent, il faudrait signer le hash avec du RSA/DSA/ECDSA et s'arranger pour que l'utilisateur ne puisse pas facilement récupérer la clé, sachant que la partie privée de la clé est tout de même sur sa machine…

Mettre des clefs dans un HSM évalué au niveau kivabien, ce n'est pas non plus terra incognita. On fait ça tous les jours avec des cartes à puces ou des TPM. A ma connaissance, récupérer des clefs privées dans des CAM ou des TPMs, ça ne se fait pas bien et abouti dans la majorité des cas à un truc pété.

Non, parce que le but principal du HTTPS, c'est le chiffrement de la communication (l'authentification est là pour être sûr qu'on chiffre avec la bonne personne).

Oula, non. Le chiffrement et l'authent (de la partie serveur) sont à égalité. Comme tu le dis, ça sert à savoir qu'on chiffre bien avec l'entité avec qui on croit chiffrer.

Tu n'as qu'à autorisé les mails uniquement valides DKIM et pour un domaine DNSSEC, en plus, ça introduit la signature de la clef par l'état (pour le .fr, via l'intermédiaire de l'AFNIC).

Tu ne vas plus être embêté par les mails /o\

Ca marche dans une maison pas super récente, ça ?
Quand je vois la galère pour des boîtiers CPL, je me dis que ce n'est pas gagné…

C'est bien possible que le bidule en question à l'installation demande de faire la liste des machins qui consomment et qu'il demande alors que tout est arrêté de les allumer l'un après l'autre pour enregistrer un "profil de consommation" de courant par périphérique ?

Peut-être. En tous cas, s'il n'a ni générateur d'aléa crypto ni mémoire (pour faire de l'anti-rejeu), il n'y aura aucune sécurité (un simple redémarrage et paf).

En même temps, personne n'a écrit ça (au moins pour la mémoire). Pour le générateur d'aléa, ne connaissant pas le système, je ne sais pas dire (je vois peut-être un soucis avec les nonce?).

Certes, mais toute la sécurité informatique repose in fine sur un algo crypto. S'il est mal utilisé, c'est mort.

D'où l'intérêt de bien l'utiliser. Mais on boucle, là.

Normalement, ils ont même interdiction d'y toucher.

Mais le coup de "des gens compétents ont regardé", je n'y crois pas: des gens compétents ont regardé certainement, mais l'organisation a t-elle permis de prendre en compte leurs remarques ? Leur a t-elle même permis de les faire entendre ?

Je pense que tu as raté deux trois trucs dans la LPM.

Oui, mais en même temps, AES-GCM est prouvé comme étant sûr, fait partie de la suite B, a un overheard et une latence minimum. Faut juste pas faire n'importe quoi avec les IV (ne pas les réutiliser) et un autre truc avec le pattern d'authent.

Encore une fois, personne ici ne connait les trade off qui ont donné lieu à ça dans le contexte global du système. Par exemple, on me demanderait de faire un truc comme ça avec comme but de faire évaluer le bazar EAL4+ avec des exigences fortes de résistances face à l'environnement (supputation, je n'ai pas vu la cible), je ne trouverais pas déconnant de partir sur une techno genre TPM ou carte à puce. Pas dit du tout que ce soit capable de faire du CBC ni que ce soit la bonne solution.

C'est déjà l'approche retenue sur les compteurs actuels.

Il n'y a aucune mention de AES-GCM dans le document en question… leur recommandation c'est AES-CBC avec CBC-MAC.

Non, mais il y a un truc sur les modes compteur. Encore une fois, les jugements définitifs sur un protocole crypto sans savoir pourquoi c'est la et comment c'est géré, c'est dangereux.

C'est mon experience en tant que professionnel dans le milieu, oui.

Ben ça a bien changé (en bien). Stuxnet est passé par la et la LPM aussi.

En lisant le reste de la spec, il est loin d'etre clair que la clef change avant que le compteur repasse par la case zero; Je ne me souviens plus non plus s'il (re)commence a zero ou pas a chaque fois qu'il perd le jus…

Y a intérêt que la clef change avant que les compteurs bouclent, sinon effectivement ça doit faire comme les modes compteurs, avec les XOR de deux chiffrés, tu obtiens les XOR des deux clairs.
Par contre, je ne vois pas comment il pourrait recommencer à 0 avec les même clef sans que ça fasse péter les compteurs de rejeu, donc ça ne pourrait pas marcher.
Cela dit, dans les deux cas, c'est typiquement ce genre de choses que l'ANSSI devrait regarder.

dans tous les cas c'est sub-optimal.

De ton point de vue peut-être, mais il y a tout un tas de paramètres qui peuvent entrer en jeu. Ptet qu'il n'y a pas de générateur d'aléas digne de ce nom, peut-être que le circuit crypto du compteur est trop con, peut-être que le système n'a pas besoin de ça.

La propriete d'un IV en crypto c'est 'que sa valeur ne doit pas etre predictible pour un adversaire au moment de l'operation de chiffrement'. La ce n'est clairement pas le cas… c'est au mieux un 'nonce'/sel.

Sur le protocole crypto lui même peut-être (et encore), mais un système ne se résume pas à un algo crypto.

Et si par construction, tu sais que tu ne réutilises pas ton IV, il est où le problème ?

Au final c'est clairement pas brillant: AES-128 GCM …

Pourquoi ?
C'est très probablement(*) compliant avec les recommandations de l'Agence disponibles ici jusqu'au moins 2030.

avec un IV qui est tout sauf un IV; 96bits total dont seulement 32bits qui changent… et c'est un frame-counter.

Pourquoi ? Est ce qu'il se répète sur une crypto période ?

Fail!

Pourquoi ? Tu ne penses sérieusement pas qu'un truc comme ça est fait à la one again par quatre gus dans un garage sans supervision de personne du niveau kivabien ?

(*) je n'ai rien vu d'évident dans le doc ANSSI qui dirait le contraire.

Le S4 mini, lui, est resté quelque part en 4.4.2, sans patch pour Stagefright.

Par contre, ce genre de "smartphone" de merde ne sont évidemment jamais mis à jour par leurs fabricant (qui préfèrent vendre des nouveaux téléphones, et tant pis pour les failles du type stagefright…),

Ca c'est malheureusement aussi commun chez les gros fabricants. Et le fait de les prendre en pack opérateur (très commun) rend le suivi encore plus hasardeux.

Ils ont aussi, sous iOS, un safari recarossé pour coucher avec leur système de gestion de bookmarks, qu'ils appellent Firefox.