boarf a écrit 36 commentaires

Personnellement, je ne l'interprète pas comme ça. Ce qui est visé, c'est l'utilisation des services Google Play, pas Android lui-même. Il sera toujours possible d'installer de vieilles applications sur Android, juste pas via le Play Store, mais en l'installant via un store alternatif (f-droid, etc.), ou manuellement en important l'apk.
À titre personnel, et sauf oubli de ma part, je trouve ça plutôt une bonne nouvelle d'un point de vue sécurité : en obligeant les applications à utiliser les API récentes, on peut leur accorder des permissions beaucoup plus fines. Par exemple, ça permet de ne donner accès qu'à leur propre stockage sur la carte SD au lieu de fournir un accès complet à tous les fichiers par exemple. Quand les applications ne sont pas libres, ça me paraît important.

(oui, je me suis connecté juste pour la vanne, je sors)

En lisant la page d'accueil du site, j'ai l'impression qu'ils ont juste réinventé la signature d'une information par une autorité… J'ai du mal à voir l'intérêt du service ?

J'ai envie de dire qu'il s'agit d'un accès contraint, à la manière d'un objet connecté : l'objet accède à un moyen de communication en ligne, mais uniquement pour ses besoins propres, et pas à la main de l'utilisateur. Et il me semble que du coup, il sort bien du champ de la proposition.

Disclaimer : je ne suis pas juriste, etc. Mais ci-dessous, une tentative de raisonnement quand même.

Si j'ai bien compris, l'obligation s'applique aux terminaux permettant d'aller sur Internet. Sur une machine sans OS, il n'y a pas possibilité de se connecter au réseau, il n'y a même pas de pile IP disponible ou de drivers pour que les radios fonctionnent. Ce que le fournisseur livre ne rentre donc pas dans la catégorie des terminaux permettant d'aller en ligne.

C'est bien le client final qui, en apportant des modifications substantielles à la machine, la transformera en appareil capable d'aller sur Internet.

… ou alors, ton projet est intégré à une étude sur la capacité des projets open-source à filtrer les contributions amenant des problèmes de sécurité ?

https://linuxfr.org/users/funix/liens/l-universite-du-minnesota-bannie-du-developpement-du-noyau-linux

Bonne journée :P

Autant pour du Bittorrent, où normalement tu partages les fichiers que tu as demandé (je ne connais pas de clients qui s'amusent à télécharger d'eux-mêmes des films de vacances glanés au hasard sur internet), je comprends l'avis rendu par la CJUE.

Mais lire ce journal m'a fait penser à d'autres outils P2P, type Freenet ou autres systèmes de fichiers distribués, où les nœuds relaient entre eux des morceaux de fichiers sans en connaître le contenu à cause du chiffrement qui leur est appliqué. J'imagine que, faute de pouvoir démontrer l'intention de l'utilisateur, celui-ci ne pourrait être considéré comme un contrefacteur (similairement au facteur qui, lui non plus, ne connait pas le contenu des colis qu'il transporte) ?
Tout au plus, on pourrait lui reprocher le "défaut de sécurisation de son accès internet", Hadopi-style ?

C'est marrant, ça me fait penser à un service similaire bien plus vieux : https://sdf.org/
C'est basé sur BSD, et ça fait partie des outils avec lesquels j'ai découvert les systèmes unix (avec Knoppix, à l'époque)…

… c'est rien de neuf, simplement une compilation des mots de passes présents dans d'anciennes fuites. Ensuite, il ne s'agit que des mots de passes, non couplés à l'adresse e-mail ou au non d'utilisateur, autrement dit son usage est plutôt pour du brute-force hors ligne.

Un article un peu plus complet qui décrit ce qu'il y a dans cette fameuse liste rockyou2021.txt: https://chris.partridge.tech/2021/rockyou2021.txt-a-short-summary/

En Chine, depuis des années, il y a la reconnaissance faciale + vérification par douanier à l'arrivée et au départ, et depuis 2 ans, on met le passeport dans un scanner à des bornes, et scan les empreintes digitales (elles sont déjà contenues numériquement dans le passeport depuis une quinzaine d'années normalement)

De mémoire, pour m'être un peu renseigné sur le passeport biométrique il y a quelques années, il y a deux catégories d'informations sur la puce :
- l'état civil et la photo sont lisibles en déchiffrant à partir d'une clé calculable en lisant la MRZ (bande de texte noir avec plein de chevrons sur fond blanc sous la photo)
- les autres informations biométriques (empreintes digitales principalement, mais les états peuvent en choisir/ajouter d'autres) ne sont lisibles que par le pays émetteur.

Résultat, en Chine ils t'imposent une prise d'empreinte sur leurs machines avant de passer l'immigration, puisqu'ils ne peuvent pas lire directement celles sur le passeport. Et donc, ils gardent une belle base de données centralisée d'empreintes.

Effectivement, il n'existe pas en IPv6 de broadcast au sens IPv4, utilisant une adresse de broadcast basée sur l'adresse réseau (masque des hôtes à 1).
Mais la fonctionnalité est présente sous forme de multicast, et en l'occurrence l'adresse multicast ff02::1 permet de toucher toutes les machines présentes sur le lien local.

Intéressant comme outil !

Par contre, mettre des éléments interprétables comme du SQL ou des scripts bash directement dans le qr-code… t'as pas peur d'un petit malin ? les injections c'est vite arrivé…

Et si vous préférez lire, il y a aussi les fabuleuses aventures de Kalon et celles de Morgoth. Ça date un peu mais j'ai adoré !

Whatsapp (qui est chiffré sur une client lourd et non webapp, soit dit en passant, bonus par rapport aux mails)

Je ne vois pas en quoi le modèle de menace diffère. Quelle différence entre :
- une application web qui te pousse un javascript dont l'origine est authentifiée par l'utilisation de TLS, pour que le client puisse chiffrer une donnée avant de l'envoyer au serveur de l'éditeur ;
- et un client lourd, dont l'origine est authentifiée par la signature du package l'éditeur, qui chiffre une donnée avant de l'envoyer au serveur de l'éditeur ?

Dans les deux cas, l'accès aux données en clair peut avoir lieu par les scénarios suivants :
1. le terminal est compromis, et donc l'appel aux primitives de chiffrement est détourné, ou la mémoire directement observée, etc. ;
2. l'éditeur, malicieux, introduit un changement dans le code exécuté chez le client (mise à jour du javascript, de l'application mobile) pour se faire envoyer les clés ou la donnée elle-même en clair ;
3. l'éditeur, de bonne foi, se fait cependant poutrer infiltrer par un tiers qui opère le changement mentionné en 2., et donc tu comptes sur les compétences de l'éditeur en matière de gestion de la sécurité de son infrastructure.

Du coup, sur le point de la principale critique mentionnée dans le nourjal initial, j'aurais tendance à être d'accord avec la réponse apportée par ProtonMail : c'est valable pour tout service qui n'est pas sous ton contrôle. Client lourd ou non.

Je ne suis pas certain que toutes ces infos viennent du navigateur. Les API WebRTC (et non Websocket) permettent d'accéder potentiellement aux adresses locales, mais pas aux adresses MAC il me semble.

Il est bien plus probable que ce scan ait été effectué par le NAS lui-même, qui en a uploadé les résultats sur le cloud de son constructeur. Quand un client se connecte sur le site donné (discover.machin), le service en ligne fait le rapprochement entre les deux sur la base de l'adresse IP publique de l'accès résidentiel.

Quant aux coordonnées géographiques… certainement un coup de GeoIP sur l'IP publique, encore.

Ce serait rigolo de voir le comportement du service avec deux réseaux privés partageant une même IP publique…

À mon sens, c'est moins universel qu'un « avatar automatique » : ça marche très bien pour les populations utilisant nativement l'alphabet ASCII ou proche (les parties latines d'Unicode, hors ASCII, autorisées par l'AFNIC par exemple), mais les utilisateurs d'alphabets grecs, cyrilliques, etc. seraient lésés dans le sens où la plupart des domaines, y compris légitimes, seraient colorés. Il ne faut pas oublier que chez eux, c'est l'inverse (on utilise le 'o' ASCII pour imiter un 'ο' (omicron))…

Ayant été professionnellement confronté à cette problématique, je n'ai jamais trouvé de solution simple pour nos clients. Mais pour nous « geeks », je me suis dit que le salut tient dans une représentation visuelle du nom de domaine basée sur le hash cryptographique de celui-ci, mis à disposition par exemple par une ​extension du navigateur. Un peu le même mécanisme que les avatars automatiques qu'on peut trouver sur les forums.

Pas du tout, c'est bien plus simple que cela, et ce n'est pas une activité fondamentalement malveillante et recherchée par les antivirus (qui soit dit en passant utilisent pour certains la même technique) :
1. modifier les paramètres du profil firefox pour rediriger les flux sur un proxy, ainsi que la base des certificats d'autorités de confiance pour y insérer une autorité propre au logiciel : dans les deux cas c'est facile, une simple base SQLite ou un fichier json à aller modifier ;
2. installer sous forme de service un proxy avec interception SSL.
3. observation des flux et injection dans les pages des éléments désirés
4. …
5. Profit!

Si je comprends bien, il s'agit d'une sorte de VNC sur HTTP/Websocket.
Je fais le même genre de chose avec NoVNC (mais pas par application, uniquement des sessions utilisateurs complètes, type bureau à distance).

Le plus de la solution présentée ici (par rapport à un bureau complet), c'est la possibilité de ne publier qu'une application, façon Citrix. Une question me taraude : quid de la sécurité ? à ma connaissance sous Citrix, il est presque toujours possible de sortir de l'environnement de l'application initiale (parmi les techniques basiques, afficher la boîte de dialogue d'ouverture de fichier de l'application, et depuis l'explorateur présenté lancer cmd.exe)…

Pourquoi l'urgence de l'action est systématiquement présentée pour sortir le pouvoir judiciaire de l'affaire ? La justice serait-elle incapable d'agir promptement ?

Erreur ! on a créé un acte pour ça : l'ordonnance en référé. Cela permet à un juge d'agir rapidement (mesures conservatoires), et de juger l'affaire sur le fond plus calmement ensuite.

Honnêtement, quand ce genre de site est mis en ligne, qu'il soit retiré dans l'heure qui suit sa détection ou qu'il le soit douze heures après, je ne crois pas que le risque de remplir les rangs des groupes terroristes soit plus élevé.

Je voudrais faire remarquer qu'Heartbleed est une faille concernant uniquement la fonction heartbeat de TLS. Les fondamentaux de la cryptographie ne sont pas remis en cause.

Ça commençait bien en disant « de nombreux services et protocoles basés sur SSL/TLS risquent d'être touchés […] », la suite en revanche n'est pas correcte :

• DNSSEC n'est pas basé sur TLS (il y a juste signature de la réponse, mais pas de canal de communication chiffré) et n'est donc pas vulnérable (à Heartbleed) ;
• Les services d'horodatage/tiers de confiance utilisent effectivement de la cryptographie asymétrique, mais une opération de signature/scellement est une opération sur l'objet et non sur le canal, n'utilise donc pas TLS et n'est donc pas remis en cause par Heartbleed ;
• Radius transporte en clair par défaut, effectivement Diameter est vulnérable s'il est utilisé avec TLS mais il peut également utiliser IPSec (d'après wikipedia, je ne suis pas un expert ès Radius).
• sur les suivants, par contre, c'est correct ou peut l'être.

Oui mais dans la chaîne de signature apparaît une sous-CA inconnue. C'est plus louche que d'avoir un certificat racine direct.

De ce que je constate avec les alertes Certpatrol lors de ma navigation quotidienne, aucun certificat n'est signé directement par une autorité racine. Il y a toujours un intermédiaire, ça permet de ne jeter que cette branche en cas de compromission. Les CA racines ne signent que des sous-CA. Et chacune de ces sous-CA peut signer n'importe quel certificat.

Edit : et ces sous-CA ne sont que rarement connues à l'avance par les navigateurs, etc. Donc une sous-CA ne peut être par définition "louche", sauf si elle se nomme clairement "Sous-CA pas de la NSA veuillez regarder ailleurs SVP".

Même réponse, cela rajoute une sous-CA qu'il faut justifier dans la chaîne de certification.

Revenons au cas qu'on retrouve 99.999 % du temps, du coup : très peu de gens contrôlent que la chaîne de confiance n'a pas changé. Et le navigateur (et plus globalement les implémentations de SSL/TLS) ne facilite pas le travail : dès lors qu'il remonte la chaîne à une AC connue, il valide l'authenticité et la considère comme vraie. Il ne demande pas son avis à l'utilisateur, la confiance est imposée.

Ce sont à mon sens les deux problèmes de SSL : la confiance imposée par l'implémentation, et le fait que n'importe quelle CA/sous-CA puisse signer un certificat pour n'importe quel nom.

C'est marrant, mais ça me rappelle drôlement le réseau de Swift, utilisé par le monde de la banque et de la finance. Un réseau, sur des lignes dédiées, avec VPN au-dessus pour authentifier tous les participants.

Je pense que ce serait intéressant d'indiquer quels lecteurs permettent de passer outre les DRM de PDF. Par exemple, dans Okular, il y a une option permettant (entre autres) d'imprimer même si le PDF l'interdit (http://docs.kde.org/stable/en/kdegraphics/okular/configgeneral.html "Obey DRM limitations"). Je n'ai pas retrouvé cette option dans evince.

Je suis d'accord, sauf pour le cookie : sur un site où on a besoin d'identifier l'utilisateur, je vois mal comment s'en passer (toutefois, les cookies externes sont effectivement inutiles).