Ça date d'août 2016, mais je voulais étudier ça à tête reposée.

Les algorithmiques cryptographiques de chiffrement symétrique découpent les données à chiffrer en blocs de taille identique pour ensuite travailler sur chacun d'eux (et en les liant mais passons). Certains algorithmes, comme Blowfish et 3DES bossent avec des blocs de 64 bits. AES, SEED et Camellia utilisent des blocs de 128 bits. On parle bien de la taille des blocs, pas de la taille de la clé de chiffrement.

La taille des blocs définit la quantité maximale d'information qui pourra être chiffrée de manière sûre avec la même clé : 2^n blocs où n est la taille des blocs. Sauf qu'avec le paradoxe des anniversaires (que je n'ai jamais compris :- ), on tombe à 2^(n/2), ce qui nous donne 256 exaoctets (soit 256 000 pétaoctets soit 256 000 000 téraoctets) avec une taille de blocs de 128 bits (donc on a le temps de voir venir) mais seulement 32 gigaoctets avec une taille de blocs de 64 bits. Il faut donc changer de clé de chiffrement avant cette limite.

Au-delà de cette quantité de données échangées avec la même clé, on peut obtenir des collisions entre deux blocs chiffrés, ce qui révèle le XOR des deux blocs non chiffrés à l'origine des blocs chiffrés qui ont fait collision (dans le cas du mode opératoire CBC, mais ça reste aussi applicable aux autres modes opératoires genre GCM, c'est juste plus compliqué, voir https://blog.imirhil.fr/2016/03/03/chiffrement-donnees.html ). Sauf qu'en pratique, récupérer un XOR de deux blocs non chiffrés, ça ne suffit pas à avoir la version claire des données échangées… Sauf si l'on connaît l'un des deux blocs clairs.

Jusqu'ici, c'est de la crypto habituelle, il n'y a rien de nouveau. À titre d'illustration, depuis 2014, l'ANSSI recommande d'utiliser des algos avec des blocs de 128 bits minimum dans son RGS (annexe B1). Alors en quoi Sweet32 est-il nouveau ? C'est un proof-of-concept qui montre que la faisabilité d'une attaque par collision de blocs chiffrés sur des algos cryptos utilisant des blocs de 64 bits se rapproche : dans un lab, il faut environ 19 heures et 705 Go de données échangées dans un tunnel OpenVPN utilisant Blowfish pour retrouver un secret d'une taille de 16 octets. Toujours dans ce lab, il faut environ 30 à 40 heures et entre 610 et 785 Go de données échangées pour retrouver un secret de 16 octets dans un échange HTTPS chiffré avec 3DES.

Qu'en retenir ? Que la fin des algos avec des tailles de blocs de 64 bits approche mais qu'il y a encore le temps puisque l'attaque pratique montée par les chercheurs de l'INRIA derrière Sweet32 suppose :

• des débits élevés (705 Go échangés en 19 heures, ça nous fait du 10,5 mo/s constant) qui supposent des connexions rapides que ne sont pas encore la norme (et ensuite, il faut être capable d'écouter ces liaisons à fort débit genre capter à distance 100 mbps, ça commence à se voir ;) ) ;
  
  
• que la connexion sera persistante sans être interrompue et que la clé ne changera pas pendant suffisamment longtemps alors qu'OpenVPN, dans son mode TLS, change la clé de session toutes les heures. Les serveurs web positionnent également très souvent une limite en nombre de requêtes qu'un client web peut réaliser dans une même connexion HTTP persistante ;
  
  
• que l'attaquant est en mesure d'écouter l'échange chiffré et qu'il connaisse une partie de l'échange en clair ou qu'il soit en mesure d'injecter des données en boucle, de manière prépondérante, dans ce qui sera échangé de manière chiffrée. Or, les cryptographes nous ont toujours dit, et Snowden nous l'a rappelé, que le chiffrement est sûr uniquement si les extrémités de la communication le sont donc oui, si tu te fais pwned par une iframe bidon et que tu ne constates pas une baisse de ton débit, oui, tu peux avoir mal.
  
  
• Tout ce qui précède suppose une attaque active, ciblée et minutieuse. On ne conduit pas une attaque Sweet32 à grande échelle.

Néanmoins, comme il faut toujours avoir de l'avance en crypto, je trouve que Sweet32 reste un bon rappel qu'il faut dégager les algos de chiffrement avec des tailles de blocs inférieure à 128 bits de tous nos usages : TLS, SSH, VPN, etc. Pour OpenVPN, voir mes notes http://shaarli.guiguishow.info/?r6npkg .

Un journaliste indépendant surveille les avions enregistrés par des régimes autoritaires qui passent par l’aéroport de Genève. Il veut créer « plus de transparence » dans le monde des affaires suisses.

[...] Comme son nom l’indique, son compte Twitter automatique ou « bot », pour « robot », alerte dès qu’un « dictateur » se pose à Genève ou en repart, en postant un tweet sur le compte@GVA_Watchers. Les avions officiels utilisés par les gouvernements considérés comme autoritaires selon l’« indice de démocratie » établi par The Economist en 2015 sont systématiquement signalés sur ce compte Twitter depuis le mois d’avril. [...]

François Pilet a créé ce bot après avoir enquêté sur les allers et venues des avions présidentiels de la famille du président de la Guinée-Equatoriale, Teodoro Obiang Nguema Mbasogo. L’enquête parue dans L’Hebdo utilisait les données collectées par un « spotter », l’un de ces observateurs amateurs d’avions qui surveillent les aéroports, souvent à la recherche de modèles rares. Une antenne utilisait l’ADS-B, un système de surveillance coopératif du trafic aérien, pour recevoir la position de tous les avions qui entraient et sortaient de l’aéroport de Genève.

François Pilet a ensuite mis en place un système qui puisse surveiller tous les avions enregistrés par des gouvernements autoritaires, toujours en comptant sur l’aide de ces « spotters » amateurs. Les messages automatiques précisent quel est le type d’avion, qui sont ses utilisateurs, l’heure et la date du vol.

[...]

Evidemment, les allées et venues d’un avion ne disent pas grand-chose sur la vie d’un dirigeant ni sur ses liens avec la Suisse. La présence de nombreuses institutions internationales sont autant de raisons « légitimes » pour un chef d’Etat de s’y rendre, et un avion officiel peut se déplacer sans que le dirigeant en question soit à l’intérieur. Les tweets précisent d’ailleurs à chaque fois qu’il s’agit d’avions « utilisés par » tel ou tel dirigeant. Mais le pari du journaliste est de créer plus de transparence sur les activités des dirigeants étrangers, d’ouvrir un peu ce « monde très secret » pour éventuellement se mettre sur la piste d’informations plus importantes dans des dossiers de blanchiment d’argent.

« Je crois qu’à chaque fois qu’on voit un avion venir de Guinée-Equatoriale, on devrait y réfléchir, explique-t-il au site The Verge. Pourquoi ce type vient ici ? Est-il ici pour des raisons diplomatiques, parce que des représentants de son pays sont invités à des débats politiques ? Ou viennent-ils simplement cacher l’argent qu’ils ont volé à leur peuple ? » En France, le fils de Teodoro Obiang fait l’objet d’une enquête pour détournements de fonds publics, mais la Suisse n’a pas lancé de procédure alors que l’argent y a transité. Le régime équato-guinéen est réputé être l’un des plus corrompus au monde.

Vache, ce projet. :O

Via https://twitter.com/Elsa_Trujillo_/status/788298883994648577 via https://twitter.com/bortzmeyer

Un chercheur du MIT a fabriqué une intelligence artificielle qui publie des tweets inspirés des discours de Donald Trump. Ce n’est pas la première fois que des « bots » s’invitent dans la campagne présidentielle américaine.

[...]

En fin de compte, « ce qui ressort est un langage peu naturel, imprévisible, parfois peu compréhensible – ce qui veut dire que c’est une assez bonne imitation de l’homme en question », ironise le magazine spécialisé Wired. Donald Trump se révèle en fait être un modèle assez pratique pour concevoir ce type de bot, assure le chercheur. « Il s’interrompt beaucoup et fait pas mal de digressions, a-t-il souligné dans les colonnes de la MIT Technology Review. Il tend à utiliser un langage assez simpliste. »

[...]

L’équipe d’Hillary Clinton a elle-même créé Text Trump, un bot qui fonctionne sur mobile. Ce programme envoie aux personnes qui le demandent des textos contenant des citations de Donald Trump – des vraies cette fois – soigneusement sélectionnées pour nuire au candidat. L’utilisateur peut l’interroger sur différentes thématiques, et le bot lui renvoie une citation, source à l’appui, en lien avec le sujet.

Dans la même veine, une agence de communication a de son côté créé un bot pour Facebook Messenger, qui dialogue avec l’internaute et lui envoie des citations de Donald Trump, en lui donnant des liens vers les sources permettant de vérifier leur authenticité.

[...] Le chercheur d’Oxford Philip Howard, qui s’intéresse à la « propagande computationnelle », a analysé les tweets publiés autour du débat entre les deux candidats à la présidentielle américaine, rapporte la BBC. Selon ses travaux, 32,7 % des tweets pro-Trump, soit près d’un tiers, seraient en fait l’œuvre de bots, contre 22,3 % des tweets pro-Clinton.

Intéressant.

Gros casse-tête du soir.

On a un OpenVPN fonctionnel, qui gère IPv4, IPv6, TCP et UDP. Le tout avec deux instances c'est-à-dire deux processus OpenVPN distincts. Voir https://wiki.arn-fai.net/technique:vpn . Pour une raison sur laquelle je reviendrais plus tard, on décide d'éclater IPv4 et IPv6. On se retrouve donc avec 4 processus OpenVPN (udp v4, udp v6, tcpv4, tcpv6). Pour une autre raison, on a besoin de dupliquer ça, pour se bind() sur deux IP. On se retrouve donc avec 8 processus OpenVPN, 4 par IP, 2 udp v4, 2 udpv6, 2 tcpv4, 2 tcpv6.

On remarque un truc curieux : quand les 8 VPN sont en cours d'exécution, il n'est pas possible de se connecter à l'un d'eux : on obtient un AUTH_FAILED. Notre script lancé à la connexion d'un client (avec la directive « client-connect » d'OpenVPN) sort avec un code de retour = 2. On lance le script manuellement, avec les droits de l'utilisateur openvpn, ofc : ça fonctionne. On ajoute des affichages de debug et on constate que le script échoue sur la condition suivante :

    if ! echo "$common_name" | grep '^[a-zA-Z][a-zA-Z0-9_-]*$'; then
        log notice "Bad common name $common_name"
        return 1
    fi

On remarque que le echo fonctionne. C'est donc le « | grep » qui foire.

On remarque aussi qu'il suffit de n'avoir que 7 processus OpenVPN, n'importe lesquels et ça fonctionne. C'est vraiment le 8e processus qui fait foirer l'ensemble.

On remarque que si l'on ne réduit pas les privilèges, c'est-à-dire qu'on laisse OpenVPN s'exécuter en root, alors on n'a aucun problème.

Johndescs et b4n émettent l'hypothèse qu'une limite quelconque a été dépassée. J'avions aussi compris mais ulimit retourne « unlimited ». Du coup, quelle limite a été dépassée ? On remarque que les processus OpenVPN sont tous exécutés dans une même slice systemd. Ils sont les seuls à l'être. Si l'on change d'init ou que l'on lance nos 8 OpenVPN depuis le shell, on constate que nos 8 procesus OpenVPN cohabitent sans problèmes.

On regarde la templated unit systemd fournie dans le package OpenVPN (/lib/systemd/system/openvpn@.service ) :

LimitNPROC=10

Ho bah ça alors. On compte : 8 processus OpenVPN, 1 script, 1 echo, ça fait bien 10. Le shell ne peut donc pas se forker pour écraser son code par celui de grep.

Il suffit d'augmenter cette limite et c'est tout bon. \o/

Ensuite, on lit la doc' : https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LimitCPU= . « LimitNPROC » est l'équivalent de « ulimit -u ». Il ne s'agit donc pas d'une limite par slice ou quoi que ce soit, juste une bonne vieille limite par utilisateur.

Je trouve vraiment dommage de n'avoir aucune indication dans les logs qu'une limite a été dépassée. Ça rend houleux le debug… :(

ÉDIT DU 26/10/2016 À 01H55 : « LimitNPROC » apparaît dans l'unit systemd OpenVPN livré dans le paquet de Debian Stretch, pas celui de Debian Jessie. FIN DE L'ÉDIT.