Is voicemail dead?

Oh oui, quelle misère. Par chance, je suis encore épargné.

Même actuellement mon opérateur ne me permet pas de désactiver la messagerie vocale.
Je n’aime pas devoir retenir un message vocal plutôt que de trouver au coup d’œil les informations qui m’intéressent dans un texte, et vue cette démocratisation des usages que je constate je sens que je vais déguster …
Un message vocal, c’est une enveloppe fermée, je dois les ouvrir une par une, limité à leur vitesse de lecture, sans possibilité de recherche, pour si elle existe retrouver une information. Rajoutez à cela que des personnes ne savent pas articuler, aïe, ça complique vite la recherche d’une info (essayez de trouver un numéro de train ou d’avion dans un message vocal quand tout autour est bruyant ; si vous vous énervez, vous avez perdu).

Tant que les personnes s’en servent entre eux sauf pour moi, je n’ai aucun souci.

Toutefois, on ne peut pas ignorer les problématiques de confidentialité des données :
Qui stocke, comment, où, et pour combien de temps, et au final, pourquoi ?
Puis qui d’autre peut aussi y avoir accès ? Pareil, pourquoi ? À quelles conditions ?
Comment éviter les appropriations d’identités, assurer le respect de la vie privée, éviter les nombreuses métadonnées supplémentaires, etc ?

Voir aussi l’impact d’une nouvelle techno, je pense ici à Rich Communication Services (RCS) qui offre l’accès à ceci comme le font d’autres applications de messagerie.
Petit aparté, RCS semble être standardisé par la GSMA et libre d’utilisation (on pourrait créer un client et un service pour héberger, mais est-ce suffisant ?) mais intimement liée à Google ; ceci à travers les implémentations de leurs clients sur Android et sur ordinateurs, et aussi lié au stockage des données chez eux ( dans leur service « Jibe ») si l’opérateur de l’utilisateur ne supporte pas ce protocole.
Ceci requiert un appareil compatible avec accès aux données mobiles (je suis conscient qu’avec le temps et le remplacement des terminaux, ce ne sera plus un problème). A-t-on le choix de l’hébergeur comme avec les courriels ? Non il me semble.

Autre point, c’est le risque de voir n’importe quelle conversation transmise à de l’« IA » pour traitement, comme retranscription, production d’un résumé, prise de note, intégration en calendrier, etc.
Tout ceci n’est pas un souci à condition que le traitement est respectueux de la vie privée ; or actuellement ou vu les services utilisés, ce n’est pratiquement pas le cas, aussi bien pour des questions techniques (puissance de calcul nécessaire pour traitement efficacement ou rapide ou économique), que pour l’implication de nombreux acteurs dans la finalité.

PS : au cas où ça serait flou ;-) : oui je n’aime pas du les ordi-téléphones, alias "smartphones", en tout cas sous les formes vendues par Android et iOS.

PS2 : je lis par exemple que Google décide de bloquer l’accès à RCS si le téléphone est "rooté" ou la protection du démarreur modifiée.
(en anglais, mars 2024) https://www.androidauthority.com/google-silently-blocking-rcs-rooted-android-phones-custom-roms-3421652/
On peut en conclure que RCS est profondément intimement lié à Google, ce n’est pas viable en protection de la vie privée.

À faire ultérieurement.

Un article intéressant qui expliquent qu’une solution purement technologique concernant le contrôle parental n’est pas la solution.
Pour information, ils savent de quoi ils parlent car ils sont justement « experts de justice en (sécurité) informatique » (source : leur site professionnel esplori.pro), dans des affaires cybercriminelles liées à la pédocriminalité.

La constellation EURion est le nom donné à un agencement de symboles que l'on trouve sur de nombreux billets de banque depuis 1996. Il est destiné à être détecté par des logiciels de traitement d'image afin d'empêcher le faux-monnayage à l'aide de photocopieur.

Je n’en avais jamais entendu parlé avant, ça fonctionne aussi pour d’autres documents, comme des chèques.

Note (Français/French) : cet article est une aide mémoire sur l’utilisation de nftables nft, toutefois par habitude je l’ai rédigé en anglais, je m’en suis rendu compte un peu tard, juste avant publication pour quelque chose qui allait être en privé.

Note: this article is just a reminder how to use some nftables instructions.

Use option --handle/-a for displaying handles, which are required for deleting or for insertion for examples.

Create chain, named banned for example, but don’t use hook and priority:

nft create chain inet filter banned

Before it can be inserted, look for the handle to insert before, for example in the main chain INPUT from the table filter from the inet (IPv4 + IPv6) family:

nft --handle list chain inet filter INPUT

Note: it is possible to look through the whole table with this command nft --handle list table inet filter, but then all its chains are also displayed.

Add a jump statement to this newly created chain with the handle previously acquired from above command (replace "${HANDLE}"):
Notes:

• this command adds a comment, it is only to display with list actions;
• the double quotes are required for multiple worded comment, so when invoking nft, use single quotes or escape characters.

nft insert rule inet filter INPUT handle "${HANDLE}" jump banned comment '"lookup on the banned list"'

Now there is a jump statement to this newly chain, however the later is empty after creation.
Here how to add an IP address, either IPv4 or IPv6, or even a range, in this list, with a drop action:
Note: so see a number of packets, the counter statement is added

nft add rule inet filter banned ip saddr "${IP_ADDR_OR_RANGE}" counter drop

Same than previously, here how to display banned IP addresses, with their dedicated counters:

nft --handle list chain inet filter banned

It is also possible to allow an IP address, just replace the drop action by accept; however, because computation is done once a rule is matching, it is almost always better to insert a rule, nft insert rule […] instead of nft add rule […], so it appears at the top of the target chain:

nft insert rule inet filter banned ip saddr "${IP_TO_ALLOW}" counter accept

Combien de fois y ai-je pensé ? Une bonne solution serait ainsi de ne pas dépendre d’une seule source.

Ainsi, ne dépendez pas d’une solution externe qui demande ainsi de multiples formes d’authentifications ; utilisez par exemple KeePassXC qui est un gestionnaire hors-ligne, chiffré « simplement » avec une phrase de passe.
Et ensuite, sauvegardez bien votre base de mot de passe régulièrement tout en vous aidant de la stratégie de sauvegarde « 3-2-1 »
https://www.nextinpact.com/article/30278/109000-quest-ce-que-strategie-sauvegarde-3-2-1

Si vous avez un serveur distant, auquel vous pouvez facilement vous connecter par mot de passe uniquement (en cas de nécessité), vous aurez de nouveau accès à vos identifiants.
Une clef USB ou un disque dur externe chez quelqu’un d’autre de votre famille est très facile à mettre en place, mais plus difficile à gérer pour garder à jour votre base KeePass.

Pour résumé en très simple, le fait que Google et d’autres services d’envois de courriels ne publient pas la clef privée pour DKIM (Domain Keys Identified Mail) après chaque changement permet ainsi de continuer de vérifier l’authenticité des courriels bien des années après leurs envois.
Pour rappel, le but d’origine de DKIM est de permettre de vérifier l’authenticité de la source du courriel lors de sa réception, une solution contre le spam.

Sauf que si un courriel peut être authentifié bien des années après, les utilisateurs peuvent être victimes « d’extorsion et de chantage » lorsque leurs courriels auront été volés par n’importe quel moyen.
De plus, il se peut qu’au bout de plusieurs années, même si la clef DKIM a été changée de nombreuses fois, que des personnes malveillantes arrivent à recréer la clef privée utilisée légitiment à un moment donnée. Et ainsi, ils pourront forger de nouveaux courriels postdatés, qui ainsi seront authentiques aux yeux des personnes qui souhaitent vérifier.
Donner ainsi la clef privée permettra de pouvoir nier l’authenticité d’un courriel, ne laissant le rôle de vérification de DKIM qu’au moment de la transmission.

Pour ceux qui souhaitent continuer de garantir l’authenticité de leurs courriels, ils peuvent utiliser des outils dédiés pour, comme GnuPG, de leur plein gré, et non de façon implicite choisie uniquement par leurs hébergeurs ou le service envoyeur.

Du coup, j’ai aussi du boulot à faire de mon côté …

Un article de sensibilisation aux arnaques (“scam”) par courriel, en se servant de chantage concernant un (improbable) accès à votre compte et ordinateur et ainsi à vos données personnelles, contenant des "vidéos compromettantes".
Comme l’article l’explique correctement, ces arnaques ne sont pas ciblées, et ainsi ne peuvent pas être véridiques car n'étant pas ciblé ils n’ont donc aucune des données qu’ils prétendent avoir sur vous.
Et comme pour chaque chantage, il ne faut absolument pas payer ; sans plagier entièrement l’article, ils expliquent que rien n’empêchent ces maîtres chanteurs de revenir, car il n’y aura aucun moyen de vérifier qu’ils ne garderont pas une copie de vos données et qu’ils supprimeront leurs virus (qui je rappelle n'existent pas), et ainsi augmenter leurs enchères.

En conclusion, ayez une solution antivirus à jour (même les gratuites bien connues sont efficaces), ainsi qu’un système à jour principalement sur les mises à jour de sécurité.
Et concernant les chantages, il existe des aides pour bien vous informer (c’est dans l’article aussi).

Merci aux auteurs de cet article pour avoir créer une liste de ces arnaques et la maintenir à jour tout en étant très pédagogique sur le recul à prendre face à de tels courriels (et ils sont nombreux).

EDIT : je copie depuis cet articles des liens vers des pages de journaux français, parlant d'un français présumé coupable arrêté une fois son retour en avion en France :

• Le Monde : https://www.lemonde.fr/pixels/article/2019/09/13/sextorsion-un-francais-arrete-apres-une-vaste-tentative-de-chantage-par-e-mail_5509981_4408996.html
• Le Figaro : https://www.lefigaro.fr/flash-actu/cyberescroquerie-un-francais-interpelle-pour-une-vaste-arnaque-20190913
  Malheureusement, il est loin d’être le seul, et ces arnaques existent depuis le début de l’internet, et même bien avant.

Déjà lu, mais lien gardé pour lectures des différents articles conseillés pour approfondir la recherche :

• l'interview d'un des développeurs de GnuPG : https://www.april.org/vie-privee-en-2013-pourquoi-quand-comment-par-werner-koch
• ou bien un très bon article de Dan Goodin expliquant comment contourner (et non pas casser) la crypto : http://arstechnica.com/security/2013/09/spooks-break-most-internet-crypto-but-how/
• ou encore celui de Peter Bright sur les vraies capacités de la NSA : http://arstechnica.com/security/2013/09/of-course-nsa-can-crack-crypto-anyone-can-the-question-is-how-much/
• Voir aussi l'article de Matthew Green qui fait le tour des techniques connues et inconnues pour déchiffrer le trafic TLS : http://blog.cryptographyengineering.com/2013/12/how-does-nsa-break-ssl.html

Et comme l'indique l'auteur : « Tout cela n'était que des solutions techniques car cet article se focalise sur l'aspect technique des choses. Mais, évidemment, le problème de fond est politique et c'est dans des changements politiques profonds qu'il faut chercher les vraies solutions. Il n'est pas normal qu'il faille être expert en crypto pour avoir une vie privée ! »

Article très détaillé et très bien expliqué sur la mise en place d'un service DoT et DoH (respectivement DNS over TLS et DNS over HTTPS) et sur son fonctionnement, avec en prime des outils pour vérifications, analyse, suivi de l'état du système.
Merci encore à Bortzmeyer.

Même avec un client officiel, des vulnérabilités demeurent suite à l’abandon du support pour ce jeu, permettant ainsi à des personnes malveillantes d’exploiter des failles qui ne seront jamais réparées, même si le client est toujours distribué par l’éditeur.
La suppression des noms de domaines malveillants n’est qu’une répit de quelques instants, tout au mieux.

Avec GCC 7.3 :
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline

Rien à cacher ? C’est ce qui arrive quand le délit est la simple consultation d’un site Web, ce qui se détermine par une simple requête HTTP, ou ce qui arrive lorsque la présomption d’innocence disparaît.

Un récapitulatif suite à toute la conversation dans cette ML (Mailing List).
@TODO

En vulgarisé (enfin le plus que je peux tout en restant cohérent), il y a deux failles liées, nommées “Metldown” et “Spectre”.

La première, nommée “Metldown”, permet de contourner la protection des données offerte par l’isolation de la zone mémoire de chacun des processus, en s’appuyant sur une faiblesse découverte au niveau physique du processeur lui-même.
Pour l’instant, on considère que cette faille touche mes processeurs dits « modernes », principalement de marque Intel, depuis près de 10 ans.

Quant à la seconde, “Spectre”, elle est assez proche de Meltdown, mais serait plus dévastatrice.

Concernant un peu de contexte, les détails de ces failles sont sous embargo (jusqu’à aujourd’hui, 4 janvier 2018, ou jusqu’au 9).

Ainsi, il est important de mettre à jour pour corriger en partie ces failles, mais vu que cela touche la partie physique du système, il risque d’être nécessaire de changer de matériel … (petit conseil personnel, regardez ailleurs que chez Intel)

Autres sources, un peu partout :
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
Autre domaine pour Spectre, site web identique : https://spectreattack.com/
https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html

Le patch sous Linux, avec l’option X86_BUG_CPU_INSECURE dans la configuration du noyau : https://github.com/torvalds/linux/commit/a89f040fa34ec9cd682aed98b8f04e3c47d998bd#diff-678874d00bf0df04f6f427f16f1dea36R902

En français https://www.nextinpact.com/news/105909-failles-securite-et-kpti-intel-publie-courte-reponse-fin-embargo-9-janvier.htm
En français https://www.numerama.com/tech/318251-faille-critique-sur-les-processeurs-intel-quelles-seront-les-consequences.html
En français https://www.numerama.com/tech/318576-meltdown-et-spectre-7-questions-pour-comprendre-les-failles-critiques-sur-les-processeurs.html

Ensemble d’actualités concernant le piratage dont a été victime Equifax (Equifax est une agence « dont la mission est de rassembler [des] informations […] sur les personnes souscrivant des crédits »).

Ce qui choque dans cette affaire, c’est le fait que l’entreprise cherche à nier ses erreurs, en les collant sur le dos de tiers, tout en ayant mis du retard à indiquer la fuite (découverte en interne le 29 juillet) pour prendre le temps de vendre des actions ou créer des lois.
« Il y a des torgnoles qui se perdent ! »

Voir aussi l’article (fr) sur NextINpact : https://www.nextinpact.com/news/105125-piratage-dequifax-jusqua-143-millions-victimes-donnees-tres-sensibles-derobees.htm

(Article en anglais)

Et voilà, une seule erreur, et c’est la catastrophe pour tout le monde ! Pourquoi ? parce que c’est le genre de risques qu’il y a avec tous ces services super centralisés.
Aujourd’hui, la flemme de décrire la faille (j’écris surtout pour garder les liens), mais en gros, ça s’appelle "CloudBleed", car ça a le même soucis que HeartBleed, c’est une zone mémoire prise aléatoirement.

En français, sur NextINpact : https://www.nextinpact.com/news/103421-cloudbleed-importante-fuite-donnees-chez-cloudflare-changez-vos-mots-passe.htm
En français, sur LinuxFR : https://linuxfr.org/users/pied/journaux/ho-la-belle-prise-chez-cloudflare
En anglais : https://bugs.chromium.org/p/project-zero/issues/detail?id=1139