rakoo a écrit 921 commentaires

Mouais.

Un rapide parcours de la page Wikipédia me fait dire que même avec les indicatifs nationaux, un numéro de téléphone a 15 caractères maximum, dans un alphabet de 10 caractères: ça fait 10¹⁵ combinaisons grand max.

Cette autre page me dit qu'avec un montage de GPU standards, je peux espérer calculer 1 Milliard de ces combinaisons par secondes

Du coup pour avoir la liste de tous les hashs de tous les numéros de téléphones, ça me prendrait 10⁶ secondes, soit un peu moins de 300 heures. Et ça c'est en étant large sur les chiffres.

Note: Textsecure semble utiliser sha-256, et j'ai pas inclus les ASIC parce que je sais pas exactement pour quoi ils sont taillés, mais s'ils font du sha-256 eux aussi…

Note2: même l'auteur sait que c'est pas viable sur le long terme.

Merci pour ce rappel sur la nécessité de bien comprendre ce que veut dire un projet lorsqu'il se dit "NSA-proof".

Il y a d'autres voies pour une application seule (ie sans passer par Tor) de cacher un peu les participants à une conversation:

1. Plutôt que de cacher l'émetteur, cacher le destinataire, comme twister le fait. Les destinataires potentiels doivent alors essayer de déchiffrer tous les messages en espérant qu'il y en ait un pour eux.

2. L'étape d'après: masquer expéditeur et destinataire. Tous les participants du réseau doivent alors essayer de déchiffrer tous les messages pour voir s'il n'y en a pas un pour eux. Ça peut sembler lourd, mais il y a au moins un projet qui tente l'expérience pour voir ce que ça donne: bitmessage.

Un jour trop tard !

C'est couteux parce que chaque caractère doit être lu et interprété. Contraste ça avec les formats qui utilisent des length-prefix, où ton parseur peut sauter tout un tas d'octets (ou plutôt les passer a un autre parseur) si ça ne l’intéresse pas.

Moi ça me fait un peu peur de dépendre du fs pour faire des backups.

Les backups, pour les particuliers en tout cas, c'est typiquement le truc dont tu ne te serviras qu'une fois dans 10 ans après avoir change 10 fois de machine. Tu penses que t'arriveras toujours a lire ton backup dans 10 ans, quand le nouveau système de fichiers mdrfs sera le plus mieux du monde et que tes machines ne sauront plus parler le vieillissant btrfs ?

Moi, si je faisais correctement mes backups, je resterais sur quelque chose qui s’éloigne le moins possible de la hiérarchie dossiers/fichiers (typiquement rdiff-backup, ou a la limite un format bien documenté et facile a comprendre, comme duplicity ou ddar ou bup). Mais ça, c'est quand je ferai les choses proprement.

Bon ben puisque c'est comme ça, voici le torrent pour la vmdebian.

infohash: bd78208b0476521acfc923cfb468a56d7aee5804
sha256sum: 24cc3ef9410ec3807e594b9d6acb9f01823c57d9b345e2d0a200651b3230e592
sha512sum: b2f18f32a5fe8afb863c993a27501350b1c27b710eabba308c6f770d2520a411ea67b00ec3db9a8cc1a6e9825a368bbd611e759ba77cd9d441f3b22303b99bd4

Je t'invite à vérifier ces données pour prouver que je ne fourvoie personne, ou (mieux !) à fournir les torrents vous-mêmes.

Note: je fais ça pour soulager vos serveurs (bittorrent c'est quand même sacrément bon, mangez-en plus!), pas pour piller. Si je fais mal, n'hésitez pas à me le dire.

Tu es peut-être anti-bitcoin, mais moi je ne vois pas ce qu'on peut reprocher au protocole dans l'histoire. La majeure partie de l'affaire est due à la confiance que les clients avaient en Mt. Gox.

la finance complètement libre, sans règles

C'est peut-être ça l'erreur: considérer que bitcoin est (pour le moment) autre chose qu'un jeu de roulette géant.

les Dollars et les Euros […] il y a un peu plus de protection qu'avec les Bitcoins

Dans la mesure ou on a à gauche une monnaie reconnue comme telle et de l'autre côté un machin qui n'a pas plus de valeur aux yeux de la loi qu'un Simflouz, oui, c'est normal que les protections ne soient pas les mêmes.

La morale de l'histoire, pour moi, c'est surtout comme pour la fermeture de Silk Road: la confiance c'est quelque chose qu'on ne prend pas à la légère, et la technique n'est pas forcément à blâmer.

OS moyenâgeux

Ah oui, bien sur. La on a de l'argument.

"Windowsien, dégage! Tu n'es pas le bienvenu."

Chacun a sa définition du Libre et de l'open source, mais quand on le fait c'est pas pour partager a la base ?

Pourquoi tu grognes ?

T'as lu la conversation ? La supposée facilité avec Windows est vendue dans l'interview, pas sur le site.

Ce n'est pas un nouveau réseau social libre. C'est une nouvelle application pour le même réseau social: XMPP.

Pour le moment toutes les applications ne peuvent pas communiquer entre elles parfaitement (notamment pour ce qui est microblogage), mais le gros avantage d'avoir plusieurs implémentations est de penser a plus de choses en même temps et de voir plus de problèmes. Le but final est que toutes les applications soient capables de faire la même chose et qu'on puisse passer de l'une a l'autre sans encombre.

Du coup, si toutes les applications (Movim, SàT, Jappix, Buddycloud et autres) pouvaient parler les mêmes XEP ça serait cool. La route est encore un peu longue, malheureusement.

Exact, j'ai oublié de préciser: je parle du repo officiel F-Droid. Le développeur peut faire son propre repo et garder le contrôle sur ce qui en sort.

De plus, qu'est ce qui t'assure que la version que tu télécharges sur le GooglePlay est bien celle signée par le développeur?

Parce que le code est Open Source (toutes les réserves sur ce genre d'arguments s'appliquent, bien sur).

Maintenant, qu'est-ce qui m'assure que l'application Play Store ne va pas installer d'autres applications en plus dans mon dos ? Rien, c'est vrai.

Je suis totalement pour la possibilité de choisir la source de ses logiciels. Je remarque d'ailleurs que la dépêche ne parle pas de "Comment installer F-Droid": il suffit d'installer l'apk de F-Droid. Ça requiert donc les droits d'installer des logiciels tiers, droit qui n'est pas donne partout, malheureusement.

Ceci étant dit, il faut bien comprendre ce que l'on fait: en utilisant un store alternatif (ça vaut pour tous) qui compile les applications pour nous, il faut bien se rendre compte qu'on dépend de ce store pour la sécurité des applications, vu qu'il n'y a aucun moyen simple pour le créateur de l'application de vérifier que ce qui est distribué est bien son application et pas un machin tout plein de portes dérobées. A l'inverse, un store qui autorise les applications pas open-source permet au développeur de compiler son application, de la signer et de distribuer ce binaire signe par lui-même. Le store n'est la que pour distribuer (et au passage récolter des statistiques).

En résumé: F-Droid est bien pour chercher les applications open-source et respectueuses des libertés, mais il introduit un intermédiaire dans la chaine de sécurité.

Parce que son service est HTTP1.1 pour le moment, et qu'il est peut-être plus simple d'avoir un reverse proxy HTTP2<->HTTP1.1 générique pour faire l'interface. Dans ce cas, s'il fait tourner ce proxy chez lui, le certificat qui l’intéresse est celui du proxy et plus celui du serveur.

La raison officielle a du sens: pouvoir dedupliquer le contenu pour les clients qui accèdent aux mêmes ressources derrière le proxy. Ça ne me choquerait pas qu'un proxy d'entreprise fasse ça, par exemple.

Tiens justement, Android va faire quelque chose de similaire dans Kit Kat:

• les applications auront le droit d'écrire dans leur dossier
• elles pourront lire hors de leur dossier, mais pas y écrire. Pour le faire, il faudra passer par l'application centrale qui gère tout, le Storage Access Framework

Les plus pressés ont compris ça comme ON NE POURRA PLUS ÉCRIRE SUR LA CARTE SD, mais en fait je trouve que c'est un design assez sympa pour protéger le système des applications malveillantes, et qui permet en plus d'offrir un accès unifié aux documents dans ton cloud.

La source peut être temps réel si elle le veut, pshb conseille de pinger le hub lorsqu'il y a du neuf, et c'est pas compliqué a implémenter.

Un point que j'aime beaucoup avec Twitter est le cotés temps réel qui n'est pas du tout présent dans les flux RSS

Ça demande un peu d'installation, mais PubSubhubbub répond justement à ce problème.

Je me permets de glisser une référence à sup, l'inspiration de notmuch, et qui a l'avantage de couvrir tout (indexation + ui) par défaut.

Les communications, c'est pas que SMTP, c'est aussi XMPP. Avec Prosody que j'utilise, voici les bouts de config intéressants pour du TLS/SSL:

modules_enabled = {
...
                "tls"; -- Assez explicite
...
}

-- These are the SSL/TLS-related settings. If you don't want
-- to use SSL/TLS, you may comment or remove this
ssl = {
        key = "/chemin/vers/ma/cle.key";
        certificate = "/chemin/vers/ma/cle.crt";
}

-- Force certificate authentication for server-to-server connections?
-- This provides ideal security, but requires servers you communicate
-- with to support encryption AND present valid, trusted certificates.
-- NOTE: Your version of LuaSec must support certificate verification!
-- For more information see http://prosody.im/doc/s2s#security

s2s_secure_auth = true

-- Many servers don't support encryption or have invalid or self-signed
-- certificates. You can list domains here that will not be required to
-- authenticate using certificates. They will be authenticated using DNS.

s2s_insecure_domains = { "gmail.com", "ddg.gg", "juick.com" }

-- Even if you leave s2s_secure_auth disabled, you can still require valid
-- certificates for some domains by specifying a list here.

s2s_secure_domains = { "jabber.org" }

-- Pinnage de certificats, pour tous ceux qui ne veulent pas se soumettre à la cabale PKIstique mondiale
s2s_trusted_fingerprints = {
        --["jabber.org"] = "11:C2:3D:87:3F:95:F8:13:F8:CA:81:33:71:36:A7:00:E0:01:95:ED";
        --["matthewwild.co.uk"] = {
                --"FD:7F:B2:B9:4C:C4:CB:E2:E7:48:FB:0D:98:11:C7:D8:4D:2A:62:AA";
                --"CF:F3:EC:43:A9:D5:D1:4D:D4:57:09:55:52:BC:5D:73:06:1A:A1:A0";
        --};
        ["superhorse.se"] = "71:E6:7E:1E:DA:1F:01:E9:56:94:2C:52:D0:B5:86:07:F6:3D:7F:83";
        ["ddg.gg"] = "2A:72:69:C0:E4:36:1C:B4:98:05:D5:72:AC:CB:B9:E4:00:65:D7:30"
}

Globalement, spécifier que le TLS est voulu et le chemin vers ses certificat et clé, et on a un serveur sécurisé. Pour tester, je ne peux que recommander xmpp.net.

Avec l'excellent OpenSMTPD, voici les bouts importants pour une config qui permet d'activer le TLS:

pki pkiname certificate "/chemin/vers/mon/certificat.crt"
pki pkiname key "/chemin/vers/ma/cle.key"

listen on lo
listen on eth0 tls-require auth-optional pki pkiname hostname "mon.hostname.du.feu.de.dieu"

Testé sur www.checktls.com, le score est à 100% (modulo mon certificat qui n'est signé par personne de connu). Note: auth-optional est facultatif, mais c'est comme ça que c'est chez moi de toute façon.

ce n'est que mon avis à moi

Bon, on peut digresser alors :)

Pour moi HTTP est un protocole qui a été pense pour le stateless, et qui est simple a utiliser dans ces cas la. C'est d'ailleurs une solution bien pratique au mobile dans le cas de XMPP: plutot que d'essayer de garder une socket ouverte tout le temps, un client peut communiquer de temps en temps avec le serveur pour récupérer le dernier statut de la session (lire ce post).

Au fil du temps, HTTP est devenu de plus en plus axé session (surtout dans les usages), ce qui le travestit de plus en plus (le point d'orgue étant pour moi websocket, qui fonctionnellement n'est rien de plus que TCP. Ah si, ça permet de contourner tous les pare-feu nazis qui n'acceptent que le HTTP sur le port 80).

La solution la plus propre est pour moi d'utiliser un protocole qui fait ce qu'on a envie de faire (par exemple XMPP ou BEEP, qui permet de faire une communication full-duplex). Mais malheureusement c'est a l’opposé total de la vie réelle et des utilisateurs qui veulent le minimum de changements nécessaires pour avoir accès aux nouvelles fonctionnalités… et quelque part ils ont raison.

Dans tous les cas, j'ai beaucoup de mal à imaginer une situation dans laquelle le comportement POST-redirect-POST est utile

Il me semblait que la force de HTTP était d’être stateless. Tant que le serveur ne t'a pas dit que tout s'est bien passe correctement, pour moi, tu devrais considérer que tu dois recommencer de zéro. Ca veut dire que le seul truc que tu changes, c'est l'url. Mais c'est juste mon avis.

Oui, pardon, la partie sur la redondance peut être vue sur wikipedia.

Pour faire simple, quand ton solveur DNS va faire la requête, il va récupérer plusieurs A/AAAA possibles, chacun avec suffisamment d'indicateurs pour que les clients ne tapent pas sur la même machine en même temps, tout en restant suffisamment simple pour que le mécanisme de caches de DNS ne pose pas trop de problèmes. En gros, du load-balancing de base.

Remplace XMPP par HTTP, c'est presque pareil (La différence est qu'en XMPP il y a besoin de 2 ports différents pour que ça marche, en HTTP un seul suffit).

Les connexions anonymes sont possibles et c'est bien pratique. Je m'en étais servi pour construire une passerelle IRC -> XMPP. Le truc, c'est combien de clients XMPP permettent de faire des choses anonymes facilement ? Quand je dis facilement c'est pas plus qu'un clic supplémentaire ou un flag à passer à la ligne de commande. Juste pour info, comment je rejoins un salon anonymement avec SàT ?

La remarque de devnewton venait justement du fait qu'utiliser le protocole dans un mode autre que celui pensé par défaut (authentifié dans le cas XMPP, anonyme dans le cas IRC) demandait une intervention manuelle, parfois lourde. Et justement, le mode par défaut de XMPP est celui demandé par devnewton.

Ça rejoint partiellement la décentralisation.

Juste par esprit de contradiction, j'ai envie de dire non: la décentralisation technique fait que c'est résistant aux pannes, la décentralisation administrative fait que c'est résistant aux potentiels délires humains, mais aucun des deux n'empêche pas de faire du commerce.

Il est possible de faire un service centralisé qui n'utilise pas les données à des fins commerciales (ce que fait officiellement DuckDuckGo, on verra s'ils tiennent leurs promesses), tout comme je peux vendre des données que je récolte sur un réseau social décentralisé ("Aujourd'hui sur Twister").

La seule chose qui pourra empêcher la réutilisation commerciale des données, c'est la confiance dans les autres qui sont dans le réseau. Et ça c'est plus un problème humain que technologique.