Ça fait longtemps que je me pose la question SMSSecure versus TextSecure et encore plus depuis l'arrêt du support SMS de TextSecure. Aeris a fait une partie du boulot de comparaison. À lire. J'ai mélangé article et commentaire dans la synthèse ci-dessous.

« TextSecure/Signal, depuis la suppression du mode SMS, réclame l’utilisation de GCM pour l’échange de données entre utilisateurs. Ce système nécessite de passer par le Google Play, et donc d’avoir un compte Google.

Je me vois mal demander à mes correspondants d’installer une application nécessitant la création d’un compte chez Google et l’utilisation d’une plate-forme que je cherche à éviter par tous les moyens et qui est connue pour fonder l’ensemble de son modèle commercial sur le viol de la vie privée de ses utilisateurs et la revente de leurs informations personnelles.

[...]

TextSecure renforce aussi encore l’hégémonie de Google sur l’ensemble de la planète et va à l’encontre des bonnes pratiques en matière de téléphonie (data déconnectée le plus possible)

[...]

Le fonctionnement des SMS permet de n’utiliser que des réseaux français pour véhiculer l’information, et à ma connaissance uniquement via des réseaux (2, celui de l’émetteur puis du destinataire) pour lesquels les correspondants ont souscrit des contrats de vente français où les tribunaux français sont compétents en cas de litige.

Le fonctionnement par le canal des données, lui, fait partir vos données dans la nature, généralement via une multitude d’intermédiaires américains (les 2 FAI des correspondants, tous les prestataires intermédiaires, WhisperSystems, Google et sûrement encore 10 ou 12 autres) et avec lesquels vous n’avez signé aucun contrat sinon de nébuleuses conditions générales d’utilisations incompréhensibles. Dans tous les cas, la justice française n’y aura pas son mot à dire, à la limite la justice californienne, si vous parvenez à la saisir…

[ NDLR : d'autant plus que la NSA et la DGSE|I, c'est pas le même budget ni les mêmes possibilités techniques ]

[...]

TextSecure va reposer sur l’Internet « standard » (TCP/IP, routeurs, câbles transatlantiques…) pour transporter vos données, tout pile exactement le même chemin que votre navigation internet sous surveillance de la NSA et des boîtes noires françaises. Bref, quand vous allez envoyer un message à quelqu’un, certes son contenu va être protégé, mais un nombre important de services vont être au courant de vos échanges, et avec un peu de (mauvaise) volonté, pourraient réussir à corréler les méta-données collectées et à reconstruire votre graphe de relation, dans le but de vous placez plus de pub… ou de vous surveiller ! C’est ce que fait la NSA à longueur de temps, et ça a l’air plutôt efficace…

[...]

WhisperSystems ou Google connaissent l’ensemble des échanges réalisés avec l’application, alors que via SMSSecure, chaque opérateur ne connaît que les couples émetteurs/destinataires qui ont un bout sur leur réseau. Par exemple Bouygues ignorera tout de tes communications avec un de tes amis qui est chez Orange si tu es chez Free. [...] Il faudrait en effet compromettre chaque opérateur téléphonique (SFR, Bouygues, Free, Orange) pour reconstituer l’ensemble de ton graphe social, alors qu’une sonde juste devant GCM suffit pour tout ramasser sans risque de trou dans la raquette.

[...]

SMSSecure, lui, passe par le réseau GSM classique (voix & SMS) pour faire circuler l’information. Même si on sait que ce réseau n’est pas complètement fiable non plus, la surveillance y est bien plus complexe et coûteuse à mettre en place, en plus de ratisser beaucoup moins large et de nécessiter la coopération (volontaire ou non) des opérateurs téléphoniques. On est finalement beaucoup plus proche de la surveillance ciblée que de la surveillance de masse. On reste en plus sur un réseau 100% français, ce qui en soit n’est pas forcément une marque de confiance mais reste quand même statistiquement plus sûr que de voir son petit paquet réseau faire 42× le tour du monde pour atteindre votre correspondant à 10m de vous, et vous permettrait de vous retourner contre votre opérateur en cas de dérive.

[...]

TextSecure nécessite aussi du coup d’avoir la 3G d’allumée en permanence pour être joignable.

Si vous coupez la 3G, plus de réception de messages sécurisés, avec le risque que votre correspondant repasse en clair pour vous joindre à tout prix via un SMS classique…

Le fait d’avoir la data allumée en continu fait que vous allez aussi devoir lutter pour configurer correctement votre téléphone pour qu’il n’explose pas votre forfait (je n’ai que 50Mo de données par mois par exemple) ou ne viole votre vie privée, la plupart des applications grand public adorant juste transmettre vos informations (de géolocalisation en particulier) à qui veut bien l’entendre. Certaines n’ont parfois même pas l’option « communication en Wifi seulement », et vous n’aurez alors d’autres choix que de la désinstaller ou de dégueuler votre vie privée (ou votre forfait)…

[ NDLR : afwall+ (http://shaarli.guiguishow.info/?32zfLA) résout ces problèmes mais oui, il faut une configuration manuelle ]

[...]

La friction de l’échange de clef n’est déjà pour moi pas un argument recevable, automatiser cette partie revient à laisser un trou grand ouvert dans la raquette. Comment en effet s’assurer qu’on communique réellement bien avec la bonne personne via la data si on automatise cette partie ?

[ NDLR : donc SMSSecure est moins user-friendly, du coup ]

[...]

Hmmm, néanmoins Snowden continue de préférer Signal (voir un de ses tweets récents), et l'EFF met d'avantage en avant les applications fournis par WhisperSystems. [...] Signal est intéressant pour la protection de la voix (pas possible avec SMSSecure) et pour son support iOS. »

Très bien vulgarisé et illustré, à lire impérativement.

« Le monde des développeurs
Vous avez bien dit « en clair » ?

Au début du monde était le stockage du mot de passe en clair dans la base de données. Ça ne dérange pas grand monde, seuls les administrateurs du site en question peuvent y avoir accès, et tout le monde sait à quel point ces personnes sont fiables… [...] Tout le monde sait aussi qu’un site, ça n’a qu’une seule vocation : se faire trouer et finir dans la nature. [...] En plus, les utilisateurs ont généralement la très fâcheuse tendance de réutiliser tout le temps le même mot de passe partout, la compromission d’un compte d’un site risque donc de compromettre au passage l’ensemble des comptes de l’ensemble des plate-formes de l’utilisateur…

Et le Dieu des chatons inventa le hachage

Pour éviter de compromettre le mot de passe des utilisateurs, le développeur a alors inventé les fonctions de hachage. Par l’utilisation de fonctions bien choisies, on va « masquer » le mot de passe réel par son équivalent haché. Une fonction de hachage a la propriété intéressante d’être unidirectionnelle : on sait calculer le haché d’un mot de passe donné, mais on ne sait pas retrouver le mot de passe d’origine à partir d’un haché.

Du coup, si à la place de stocker le mot de passe en clair P dans une base de données on y stocke son haché H = f(P), on empêche un attaquant de pouvoir remonter au mot de passe d’origine si il était compromis[...]

[...]

Le sel, c’est la vie

Avec l’amélioration des processeurs, les fonctions de hachage sont globalement de moins en moins robustes. On sait en effet calculer de plus en plus rapidement des quantités astronomiques de hachés, parfois même avec du matériel dédié, les ASIC. La monnaie électronique Bitcoin est même basée sur ce genre de matériel capable de calculer jusqu’à 20THs soit 20 mille milliards de doubles SHA-256 à la seconde pour environ $5000.

C’est assez problématique pour la protection des mots de passe, puisque si une liste de mots de passe hachés se retrouvaient dans la nature, il suffirait de s’offrir un de ces petits jouets et de lui faire générer des milliards de milliards de hachés : si un haché H trouvé correspond à un des hachés dans la base, on a donc trouvé le mot de passe P d’un des utilisateurs. Les utilisateurs ayant la fâcheuse tendance à utiliser toujours les mêmes types de mot de passe (0000, 123456, password, la date d’anniversaire ou le nom du chat), on a même une probabilité non nulle d’avoir plusieurs utilisateurs utilisant le même mot de passe qui vont donc avoir le même haché et qui vont donc tous tombés en même temps…

On peut donc grandement améliorer la sécurité en utilisant un sel cryptographique avant de calculer le haché du mot de passe. Plutôt que de le calculer directement (H = f(P)), on va lui ajouter en tête une chaîne de caractères totalement aléatoire propre à chaque utilisateur (H = f(v | P)). On stocke donc dans la base le couple (v, H), ce qui permet par calcul de f(v | Psaisi) = H = f(v | P) de s’assurer de l’authenticité d’un utilisateur. Ça n’a l’air de rien comme ça, mais ce petit détail change tout.

Déjà, un même mot de passe utilisé par plusieurs utilisateurs va être associé à des sels différents, et donc générer un haché différent.

[...]

En prime, on complexifie aussi le travail d’un attaquant. Sans sel, l’attaquant pouvait simplement générer des hachés à la pelle et rechercher dans la base s’il trouvait une correspondance [ NDLR : rainbow table ]. S’il conserve la même technique avec un sel, même s’il trouvait par hasard un haché dans la base, il faudrait en plus que le mot de passe qu’il va pouvoir associer commence exactement par le sel correspondant à l’utilisateur, ce qui est statistiquement plus que très fortement improbable (et inversement proportionnel à la longueur du sel utilisé). Il va donc devoir changer de tactique et s’attaquer à chaque utilisateur successivement : je prend le sel v de l’utilisateur, je génère des tonnes de hachés de v | P, si ça me donne un H de la base, j’ai le mot de passe P de l’utilisateur v.

La dérivation de clef, c’est mieux

On l’a vu précédemment, les puissances de calcul augmentent de plus en plus, et un attaquant vraiment motivé pourrait toujours trouver les ressources nécessaires pour calculer rapidement des hachés, par exemple via l’utilisation d’un botnet ou d’ASIC dédiés à cette tache. On peut donc augmenter encore plus le coût d’une attaque via de la dérivation de clef ou l’utilisation de fonctions de hachage robuste à l’attaque par du matériel dédié (ASIC).

Par exemple, scrypt est un algorithme demandant un compromis vitesse/mémoire : vous ne pouvez être rapide que si vous lui fournissez une grosse quantité de mémoire. À l’inverse de SHA-256 qui s’implémente uniquement par des portes logiques et peut donc être massivement accéléré par du matériel dédié, scrypt est très difficile à implémenter efficacement dans du matériel, l’installation d’une zone mémoire importante (interface avec une barrette de RAM par exemple) étant relativement complexe et restera de toute façon bien plus lent en temps d’accès qu’une simple porte ET.
À titre d’exemple, on sait faire des ASIC calculant à 10THs du SHA-256, mais les meilleurs ASIC scrypt du marché atteignent péniblement le GHs pour le double du prix, soit une efficacité 20.000× plus faible. En utilisant ce type de fonction « matériel-résistant » plutôt que du SHA-2 par exemple, on se met à l’abri d’une future attaque massive sur la base.

Ces fonctions robustes au matériel ne sont pas légions, il faut donc trouver une astuce pour durcir les autres fonctions de hachage qui elles peuvent être accélérées par du matériel. Une astuce simple consiste à enchaîner plusieurs fois la fonction de hachage (H = f(f(…f(v | P)…))) (en réalité, l’algorithme est plus complexe mais le principe reste le même). Plus on enchaînera d’appels de fonction de hachage, plus l’algorithme sera lent à calculer et pénalisera fortement un attaquant.

On calcule le nombre de tour n à réaliser en fonction de l’état de l’art de la cryptographie de manière à ce qu’un calcul complet prenne de l’ordre de 100ms, suffisamment peu pour être handicapant pour l’utilisateur réel (qui devra attendre ce temps à chacune de ses tentatives d’authentification) mais extrêmement pénalisant pour un attaquant (il ne peut plus calculer que quelques hachés par seconde).

[...]

Les plus connus des algorithmes de dérivation de clef sont PBKDF2 (qui présente l’intérêt de prendre en plus en paramètre la fonction de hachage à utiliser), scrypt, et bcrypt. En terme de paramètres recommandés, PBKDF2(SHA-256) est au alentour de 10.000 tours (~100ms), bcrypt devrait être utilisé avec un cost factor d’au moins 10 (~100ms) et scrypt avec les paramètres N=16384, r=8, p=1 (16Mo de mémoire, ~100ms).

[...]

Le monde des utilisateurs

Comme vu précédemment, si vous utilisez un mot de passe trop faible ou trop commun, un attaquant pourra déjà avoir pré-calculé des pilées de hachés et trouvera votre mot de passe très rapidement. Si en plus vous utilisez le même mot de passe partout, la compromission d’un seul site fera tomber l’ensemble de vos sites, votre nom d’utilisateur ou votre adresse de courriel allant être elle aussi la même partout.

Vous devez donc vous assurer que vous utilisez sur chaque site un mot de passe différent, et si possible un mot de passe différent de tous les utilisateurs du site (pour ne pas être compromis vous aussi si les administrateurs du site ont mal fait leur travail et qu’une autre personne utilisait le même mot de passe que vous et se retrouve compromise).
La seule manière de faire est donc de générer des mots de passe aléatoires et suffisamment longs (au moins 20 caractères) pour chacun des services auxquels vous allez devoir vous connecter, par exemple uhPaz27aOEmaa2ztxTRZ ou x0vtYD41I4_7T6rep4Q5.

Comme il est impossible d’espérer retenir de tels mots de passe, utilisez un gestionnaire de mots de passe pour stocker tout ça bien à l’abri, par exemple KeepassX. »


Résumé pour les devs : « Il va sans dire que cette méthode de la dérivation de clef devrait être la seule et unique manière de stocker les mots de passe dans une base de données encore utilisée aujourd’hui… »

Résumé pour les utilisateurs : Une passphrase pour protéger une donnée locale (trousseau, clé SSH, clé GPG, luks, système), un mot de passe aléatoire de 20 chars pour protéger une donnée distante/sur le réseau.

Pas de passphrase sur des données distantes car :
    * « This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick. » (source : https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html)

    * « Si tu utilises un mot de passe, considère que ton attaquant connaît le jeu de caractères utilisé (62 pour un mot de passe alphanumérique, soit 62^15 = 7.68e26 possibilités pour un de 15 caractères), le dictionnaire si c’est une phrase de passe (7776 mots pour diceware, soit 7776^7 = 1.72e27 possibilités pour une de 7 mots), la liste des phrases possibles pour une phrase existante/titre de bouquin (soit trop peu^1 = trop peu). » (Aeris, dans les commentaires)

OWI OWI OWI un xkcd sur ce thème. \o/

Ho, excellent, un équivalent du hook preexec de zsh pour bash qui permet donc de lancer une commande avant d'exécuter celle demandée par l'utilisateur. Évidemment, il s'agit d'un hack. :)

Un cas d'usage ? Avant l'exécution d'une commande ssh/scp/..., vérifier si l'agent ssh a encore la passphrase en mémoire, sinon la redemander ($1 contient l'intégralité de la commande saisie par l'utilisateur : pipes, redirection, enchaînement,...) :
preexec() {
        if [[ "$1" =~ ssh|scp|ssh-copy-id|sftp ]]; then
                ssh-add -L | grep -q "The agent has no identities." && echo "I'm SSH agent. Your passphrase, plz." && ssh-add -t 2h </chemin/vers/clé>
        fi
}

Une autre solution élégante pour ce cas d'usage est d'utiliser gpg-agent avec la fonctionnalité ssh-agent. Un seul ssh-add suffit, il est persistant (comprendre que gpg ajoute la clé et le timeout dans ses fichiers internes dans .gnupg) et ensuite, à chaque ssh monserveur, hop, gpg-agent demande la passphrase de la clé s'il ne l'a plus en mémoire. Attention : dans ce mode, le comportement de ssh-add change : ssh -d|-D ne fonctionnent plus, et ssh-add -l|-L n'indiquent plus les clés dont la passphrase est en cache mais toutes les clés SSH connues de gpg-agent.

Jusque-là, je stockais mes mots de passe complexes (20 chars générés aléatoirement avec pwgen et/ou le classique echo `< /dev/random tr -dc _A-Z-a-z-0-9 | head -c20`) destinés aux sites web sur lesquels j'ai un compte dans des fichiers texte, un par site web, le tout planqué dans un dossier dans un conteneur luks. Mes passphrases (luks, système, ssh, systèmes distants, gpg) étaient seulement dans ma tête. Ça fait un petit moment que je m'interroge sur une meilleure solution (gestionnaire de mots de passe ? lequel ? un simple fichier texte chiffré + signé ?).

Qu'est-ce que pass apporte de plus ?
    * pass copie directement le mot de passe dans le presse-papier. On évite donc l'eavesdropping, c'est-à-dire, les regards indiscrets par-dessus notre épaule pendant un copier/coller manuel ;

    * Le mot de passe traîne dans le presse-papier un intervalle de temps court pré-défini à l'avance ce qui restreint l'intervalle de temps pendant lequel une attaque est possible. De plus, ça évite les mauvaises manipulations (genre je colle mon mdp sur IRC/XMPP, par exemple) ;

    * En cas d'accès malveillant (luks protège contre le vol de l'ordinateur éteint mais pas contre une faille de sécu, un malware ou, plus simplement, une session non verrouillée), l'attaquant peut récupérer la liste des sites web sur lesquels j'ai un compte mais plus les login/mdp ;

    * Ça simplifie toute la chaîne, de la génération d'un mot de passe fiable à son accès en passant par son stockage. Tout est intégré dans un même outil ;

    * pass permet un partage sécurisé simplifié : il est possible de chiffrer toute l'arborescence ou seulement une partie avec plusieurs clés publiques dans l'optique de partager un ou plusieurs mots de passe. Super pratique au sein d'une équipe d'adminsys ;

On garde les autres avantages/inconvénients : git pour le versionning/synchro sur plusieurs machines, bête arborescence dossiers/fichiers et le fait que la liste des mots de passe est en claire (relire le point numéro 3 ci-dessus).

Quels sont les inconvénients de pass ?
    * On n'est pas protégé à 100% des regards indiscrets. Il n'est pas possible d'afficher tout sauf le mot de passe. Or, il y a des sites web relous (banques, administrations,...) qui vous font saisir soit le login, soit le mdp sur un clavier virtuel. Dans le cas où le site web demande la saisie du mdp à la souris, on est foutu car on est obligé de l'afficher pour le recopier à la mano. Dans le cas d'un login, c'est dommage d'afficher aussi le mdp avec « pass show »... On peut écrire une fonction bash à mettre dans .bashrc pour masquer le mot de passe sauf si l'on passe une option « -f » à « pass show » :
      function pass {
          passbin=/usr/bin/pass

          if [ "$1" = "show" ]; then
              if [ "$2" = "-c" ]; then
                        $passbin $@
              elif [ "$2" = "-f" ]; then
                        $passbin show $3
              else
                        $passbin show $2 | tail -n +2
              fi
          else
              $passbin $@
          fi
      }
    Utiliser le même nom permet de conserver l'autocompletion.

    * pass repose sur gnupg et donc sur une clé/configuration solide (pas d'algos moisis ou en dernier recours). Voir : http://www.guiguishow.info/2014/07/17/ma-premiere-vraie-cle-pgp/#toc-5108-gnrer-une-paire-de-cls ÉDIT DU 09/11/2015 à 11h05 : Et si je perds ma clé GPG ? Ha bah c'est perdu hein, la sécurité n'est pas gratuite. Et si ma clé GPG expire ou est révoquée ? Ça n'a pas d'importance : l'expiration n'est pas une fatalité (lire le lien donné précédemment) et, en cas de révocation, vous ne pourrez plus ajouter de nouveaux mots de passe mais tous vos mots de passe présents dans le trousseau restent accessibles. Et donc, je fais comment pour changer de clé ? Lisons le man pass « init [ --path=sub-folder, -p sub-folder ] gpg-id... Initialize  new  password  storage  and use gpg-id for encryption. Multiple gpg-ids may be specified, in order to encrypt each password with multiple ids. This command must be run first before a password store can be used. If the specified gpg-id is different from the key used in any existing files, these files will be reencrypted to use the new  id. ». Ça fonctionne tant que vous avez la clé privée, on est bien d'accord ?! Testé et approuvé. FIN DE L'ÉDIT.


Pourquoi pas keepassX (= la version 1 mais multi-plateforme qui lit aussi les fichiers bases de données de keepass 2 ) ou keepass2 ?
    * + Keepass résout nativement et totalement le problème des regards indiscrets puisque le mot de passe est remplacé par des étoiles... Sauf à la demande de l'utilisateur ;

    * + La liste des sites web ne fuite pas avec un simple ls ;

    * + Keepass 2 est multiplateformes. Je m'en fiche, ce n'est pas une propriété que je recherche. Ceci dit, des implémentations d'OpenPGP existent aussi sous winwin mais c'est moins bien intégré à l'environnement ;

    * - pass repose sur OpenPGP qui est normalisé à l'IETF (voir https://tools.ietf.org/rfc/rfc4880.txt) alors que Keepass repose sur son propre format non normalisé ;

    * - Keepass2 est écrit en Microsoft .NET... NON, juste NON. Sans virer à la parano anti-MS, on peut argumenter qu'un soft en .NET sera toujours plus complexe que n'importe quel éditeur de texte (nano, vim, emacs). D'où un audit plus difficile et des failles potentielles en plus. Et puis même, j'suis pas là pour utiliser du .NET. KeepassX utilise C++/QT.

        Néanmoins, il existe plusieurs outils libres qui permettent de lire/écrire des bases de mots de passe au format Keepass sans recourir à Mono (implé .NET libre). Le seul qui est packagé dans Debian stable (sauf la lib perl Clipboard qu'il faut récup' en plus dans CPAN), c'est kpcli (http://kpcli.sourceforge.net/). C'est donc celui-ci que j'ai testé.
            * Il manque la fermeture auto du trousseau, ce que permet Keepass. pass permet ça grâce à l'agent gnupg. Il manque également le nettoyage auto du presse-papier : il faut venir saisir une commande (« xx »). C'est un coup à oublier. Ces points sont bloquants selon moi ;

            * Il faut patcher la lib Clipboard (voir https://github.com/lfont/dotfiles/blob/master/kpcli/Xclip.patch).


En résumé, j'ai choisi pass avec quelques ajustements dans mon .bashrc :
    * Réduire le temps entre la mise dans le presse-papier d'un mot de passe et le nettoyage du presse-papier à 10 secondes au lieu de 45 : export PASSWORD_STORE_CLIP_TIME=10 ;

    * Changer l'emplacement du trousseau : export PASSWORD_STORE_DIR=/chemin/vers/le/trousseau/ . N'oubliez pas le « / » final sinon l'autocomplétion de l'arborescence ne fonctionnera pas.


Tout un écosystème a été développé autour de pass dont le plus intéressant me semble être l'extension Firefox « passff » (https://github.com/jvenant/passff) qui permet la complétion automatique des formulaires dans les pages web. Bien que cette extension soit pratique et bien fichue, je suis plutôt sceptique à l'idée de l'utiliser :
    * À la fin du README, il est écrit, en gros : « This is a beta. For testing purposes only. » ;

    * Du JavaScript qui manipule mes mots de passe pour éxecuter pass dans un sous-processus puis remplir les éléments DOM correspondant au formulaire de login ? Ok, c'est dans un cadre restreint prévu par Firefox mais quand même... Aucun risque de fuite avec un appel JS depuis un site web ? Vraiment ?

    * ATTENTION : ne pas utiliser les fonctions « Copy login » et « Copy password » : le presse-papier n'est JAMAIS nettoyé ! (voir la fin de la fonction « onCopyToClipboard », https://github.com/jvenant/passff/blob/master/src/modules/menu.js#l246). Il faut utiliser seulement les fonctions « Fill [...] » qui n'utilisent pas le presse-papier. Si passff ne remplit pas un des champs, c'est que celui-ci a un nom stupide. Trouvez-le dans le source HTML et ajoutez-le dans « [...] input names » dans « Autofilling » dans les préférences de passff pour qu'il soit reconnu ;

    * https://stackoverflow.com/questions/33358753/firefox-extension-refer-to-object-defined-in-bootstrap-js-from-xul-file. Je contribue sur une extension qui manipule des putain de mots de passe mais « I have no idea what I'm doing :) »...


Merci à benvii pour la découverte de pass, à blusky pour le débat animé sur les avantages et inconvénients de chaque solution et la découverte de kpcli et à johndescs pour son côté bash-nazi.

« Après les sénateurs, les députés ont à leur tour adopté hier [ NDLR : le texte issu de la commission mixte paritaire concernant ] la proposition de loi sur la surveillance des communications électroniques internationales. Un vote à l’unanimité.

[...]

Le texte adopté est désormais susceptible d’être soumis pour contrôle au Conseil constitutionnel. C’est ce qu’a hautement laissé entendre le sénateur Philippe Bas (LR), assurant hier que le président du Sénat « ne manquera pas de saisir le Conseil constitutionnel ». »

J'admire (ironie) le pas de course : 1er octobre : vote en séance publique à l'Assemblée -> 27 octobre : vote en séance publique au Sénat -> 3 novembre : réunion de la CMP -> 5 novembre : vote du texte de la CMP en séance publique au Sénat et à l'Assemblée. Si tout pouvait aller aussi vite en France, ça serait le paradis.

« Les chiffres donnent le tournis. Installer une imprimante et un scanner au nouveau siège du ministère de la Défense coûte près de 14 000 euros, révèle une enquête de Challenges. Alors que « l'Hexagone Balard » est officiellement inauguré jeudi par le président François Hollande, le nouveau site pose d'ores et déjà question. Dans la ligne de mire du journal économique ? La gestion du site en partenariat public privé (PPP). En effet, à en croire certains devis, le consortium Opale défense (Bouygues, Thales...) a la main lourde sur les prix.

[...]

L'homme a reçu un devis exorbitant pour modifier le sens d'ouverture de la porte de son bureau. Montant de la facture ? 2 000 euros. Et l'addition monte encore plus haut lorsqu'il s'agit d'installer une imprimante et un scanner. Sur les devis de Bouygues et Thales - consultés par l'hebdomadaire, l'installation d'une imprimante et d'un scanner était facturée 13 613, 21 euros.

[...]

Alors que le loyer 2016 devait s'élever à 154 millions d'euros, il sera finalement « supérieur » à cette enveloppe, assure Jean-Paul Bodin. »

... Les bras m'en tombent... Comment ce genre de choses sont-elles possibles ?! Quelles sont les personnes qui sont capables d'établir ce genre de devis sans plier des genoux ?!

Via http://lehollandaisvolant.net/?id=20151105165741

J'avais déjà testé les enregistrements SSHFP afin de valider, via le DNS, les clés publiques de mes serveurs persos (voir http://shaarli.guiguishow.info/?X1OYWg). Maintenant que mes desktops sont sous Jessie, dans laquelle la version packagée d'openssh-client supporte les condensats sha256 dans le RDATA des enregistrements SSHFP ainsi que le type ecdsa, entre autres choses, c'est l’occasion de déployer pour de vrai.

Il vous faut :
    * Des zones DNS signées avec DNSSEC sinon l'intérêt de SSHFP est nul.
       Si vos zones ne sont pas signées (cas d'un hébergeur, comme OVH pour les zones comme kimsufi.com, par exemple), laissez tomber. Utiliser une zone signée + CNAME ne fonctionnera pas : CNAME ne peut pas se cumuler avec un autre type d'enregistrement. La seule piste envisageable, c'est de dupliquer, dans ma zone signée les enregistrements de type A et AAAA et d'y ajouter les enregistrements SSHFP mais c'est vraiment crade : vous dupliquez dans une zone des informations d'une autre zone d'où un coût en maintenance supérieur et un risque d'erreur accru. ;


    * Si vous utilisez ssh-keygen pour générer les enregistrements SSHFP, il vous faut la partie publique des clés de votre serveur au format openssh. Si vous avez du dropbear (exemple : OpenWRT), il faudra d'abord la convertir.
        * sudo apt-get install dropbear
        * /usr/lib/dropbear/dropbearconvert dropbear openssh <cle_dropbear> <cle_dropbear>.ssh
        * La partie publique n'est pas stockée sur mon périphérique OpenWRT... générons-la à partir de la partie privée que nous venons de convertir (https://askubuntu.com/questions/53553/how-do-i-retrieve-the-public-key-from-a-ssh-private-key) : ssh-keygen -y -f <cle_dropbear>.ssh > <cle_dropbear>.ssh.pub

        * ssh-keygen -r <hostname> -f <cle_dropbear>.ssh.pub . Deux enregistrements sont produits. Le plus court utilise sha1 pour produire le condensat, le plus long utilise sha256. De nos jours, avec sha1 qui commence à montrer des signes de faiblesse, il faut utilise sha256.


    * Publier les enregistrements SSHFP.


    * Un openssh-client compilé avec la lib ldns lui permet de faire les vérifications DNSSEC et donc de s'assurer que l'information n'a pas été altérée. Ce n'est pas le cas avec Debian : openssh-client n'est pas compilé avec libldns (ldd $(whereis -b ssh) pour vérifier). Donc, il faut impérativement un récursif-cache validant sur votre machine (voir dnssec-trigger, http://shaarli.guiguishow.info/?uEnUXw) ou, à défaut sur le réseau local qui doit alors être de confiance (VPN, réseau domestique...) et pas de WiFi (oui, même WPA1|2 car la clé est partagée entre les utilisateurs du réseau. Et même avec ça, il reste le problème des switchs réseaux mais comme d'hab, ça dépend de qui vous voulez vous protéger).
        Il faut bien comprendre que, sans la lib ldns, la validation des enregistrements DNSSEC est effectué par le récursif-cache validant que vous utilisez. Celui-ci signale qu'il a réalisé le travail de vérification en plaçant le flag "AD" (Authenticated Data) dans le header du message DNS... qui n'est pas signé : un MITM (ou un mensonge du récursif-cache utilisé) reste donc possible.

    * Activer la vérification des SSHFP en ajoutant ceci à votre .ssh/config :
        « Host *
              VerifyHostKeyDNS=yes »

      Vous pouvez aussi restreindre seulement aux machines dont vous savez que le déploiement est effectif. Ça ne change rien pour les machines qui n'ont pas de SSHFP associé à leur clé publique, known_hosts sera alors utilisé mais vous ne ferez pas de requêtes DNS inutiles pour ces machines-là.

      À partir de ce moment-là, SSH n'utilise presque plus .ssh/known_hosts mais uniquement le DNS, SAUF si le client utilise un récursif non validant ou que le SSHFP est outdated, auquel cas le client SSH fallback sur le fichier known_hosts. À la mise en service d'une nouvelle machine (virtuelle ou non), il faudra publier son SSHFP avant de faire un SSH sinon l'absence de réponse sera mise en cache et une validation manuelle sera nécessaire (comme sans VerifyHostKeyDNS quoi). Même chose lors d'un changement de la clé du serveur : il faudra pré-publier et attendre l'expiration du TTL du vieil enregistrement SSHFP avant d'être sûr que le nouveau arrive dans le cache... Les clients n'ont plus besoin de mettre à jour leur known_hosts.


    * Vérifier : ssh -vvv serveur :
        * Si vous utilisez un récursif-cache qui ne valide pas (ÉDIT DU 08/07/2023 : sur une version plus récente de la libc, il faut explicitement activer la validation DNSSEC dans /etc/resolv.conf, cf. http://shaarli.guiguishow.info/?LAZf0g. FIN DE L'ÉDIT.) :
          « debug3: verify_host_key_dns    
            debug1: found 1 insecure fingerprints in DNS
            debug1: matching host key fingerprint found in DNS »
          Et SSH vous demandera une confirmation manuelle de la clé du serveur.

        * Avec un récursif-cache validant :
          « debug3: verify_host_key_dns
            debug1: found 1 secure fingerprints in DNS
            debug1: matching host key fingerprint found in DNS »
          Et vous êtes connectés automagiquement à votre serveur.

Via http://www.bortzmeyer.org/4255.html

Créer un conteneur chiffré luks au lieu d'une partition chiffrée luks.

Mon ordinateur portable Clevo P170HMx m'a lâché en mai/juin dernier : écran quasiment 100% bleu dès l'allumage et plus d'affichage du tout dès que le système prend la main (oui, même un winwin 7...). Il faut savoir que je n'utilisais plus autant cet ordinateur qu'avant (1 ou 2 fois tous les 15 jours) mais qu'il restait quand même branché au secteur et qu'il était posé sur la même table que le reste de mon matos... Donc on est OK pour la qualité de l'alim électrique, humidité & co.

Heureusement, il a été pris en charge par la partie "risques électriques" de mon assurance habitation et il a été remplacé à neuf par un Asus G751JL (non, je n'ai pas eu le choix).

C'est la goutte qui fait déborder le vase vu les autres emmerdes que j'ai eu avec ce Clevo (http://shaarli.guiguishow.info/?sxgfPg). Du coup, j'ai fait un point sur tous les autres ordinateurs portables que j'ai eu afin de voir si le Clevo était une exception par sa médiocrité ou bien s'il était dans une sorte de norme...


Compaq CQ61-407SF :
    * + Finition : j'aimais beaucoup la sensation de frappe sur ce clavier ;
    * + Une puce WiFi Atheros AR9285 compatible avec l'injection Aireplay <3 C'était l'bon temps ;
    * + Fonctionnait très bien sous Debian GNU/Linux Squeeze ;
    * + Installation facile d'un système libre : secure boot et co n'existaient pas encore ;
    * - Composants durs à changer donc prix délirants. Je me souviens de la nappe de la dalle LCD qui était dans un format vaseux, nécessitant d'acheter la dalle kiVaBien à prix d'or (146€ TTC, soit 37% du prix initial d'achat !). Je n'ai pas eu de problèmes, je m'étais renseigné "pour voir" et j'avais choisi l'écran car je sais que c'est sur ce composant qu'on voit les trucs hallucinants sur un ordi portable.


Clevo P170HMx :
    * + Des 4 machines que je compare ici, il est celui qui se démonte le plus facilement, c'est une évidence ;
    * + PC portable personnalisable ;
    * - Cette personnalisation a un coût plutôt exorbitant quand on y regarde bien et le choix est plutôt réduit : choix entre deux modèles de processeur, 4/8/16G de RAM,... Mouais... Dell aussi est personnalisable dans ce cas-là ;
    * + Installation facile d'un système libre : secure boot et co n'existaient pas encore. À part le WiFi, tous les drivers étaient libres ;
    * - Mais même avec ça, la puce WiFi Realtek 8188CE était vraiment merdique et le WiFi quasi inutilisable ;
    * - Comment détecter les composants vaseux ? L'acheteur est-il mieux informé qu'avec un ordinateur acheté dans le commerce ? Je n'en suis pas sûr. Genre j'ai choisi un mauvais SSD qui castrait littéralement les perfs que même un disque dur WD 7200rpm de récup' pénalisait moins la machine. Je me souviens que le site web d'Anyware (revendeur FR Clevo) n'indiquait pas la marque/modèle, juste "SSD de 128G". Même chose pour la puce WiFi sauf que je n'avais pas le choix ;
    * - Aucune finition. Aucun plaisir à taper sur ce clavier d'autant que l'entourage plastique/métal vous gèle les poignets en parallèle... ;
    * - Je m'attendais à un BIOS avec beaucoup d'options compte tenu du côté personnalisable mais non... Plus qu'un laptop acheté en grande surface mais pas novateur non plus. J'ai été très déçu sur ce point ;
    * - SAV d'Anyware (revendeur FR) plutôt décevant surtout dans le relationnel ;
    * - J'ai raconté ici (http://shaarli.guiguishow.info/?sxgfPg) que la carte mère de rechange n'était pas arrivée au bout de 7 semaines entre les mains du SAV d'Anyware. Soit environ 2 ans après la mise sur le marché, Clevo semble ne plus pouvoir assurer des livraisons de pièces détachées dans un délai convenable... On est donc au niveau de tous les autres fabricants/assembleurs de matos électro-ménager. Quel intérêt de choisir Clevo, alors ?


Dell Latitude E6540 :
    * + Finition. J'aime beaucoup la frappe au clavier et l'espèce de caoutchouc sous les poignets. Il y a eu du travail sur le design, sans que ça soit démesuré, et ça se voit ;
    * + Batterie 9000mAh qui tient 4-5h ;
    * + Un EFI, oui, mais le plus complet que j'ai jamais vu... Des options utiles à la pelle comme désactiver micro/webcam... Presque chaque composant peut être désactivé et beaucoup de choses sont configurables. Juste GG <3
    * + Un SAV qui poutre vraiment. Le meilleur SAV auquel j'ai eu affaire dans ma vie. De la relation humaine au suivi en passant par la réparation sans te prendre pour un con, juste GG. <3
    * + Une puce WiFi qui juste fonctionne ;
    * + Installation facile d'un système libre : secure boot est présent mais se désactive facilement. À part le WiFi, tous les drivers sont libres ;
    * - Les boutons du touchpad sont plutôt mal fichus et cliquent plutôt mal ;
    * - Ça reste vendu à prix d'or ;
    * Note :  le fameux mouchard Computrace (voir : http://korben.info/computrace-lojack-absolute.html) n'est pas actif par défaut et peut (doit) être désactivé dans l'EFI sans possibilité de réactivation ultérieure ;


Asus G751JL :
    * Note : Je n'ai pas assez de recul pour juger ;
    * - Aucune finition, rien... Même problème que Clevo. C'est juste ignoble ;
    * - Des trucs WTF :
        * La batterie n'est pas amovible directement (faut dévisser, sérieux !) ;
        * Le touchpad ne peut pas être désactivé matériellement, ce n'est qu'un raccourci pour qu'un logiciel proprio d'Asus (ASUS Smart Gestures), le désactive. BTW, c'est quoi le délire d'avoir mis un touchpad aussi démesuré ?!
        * La connectique est mise n'importe où... J'apprécie (ironie) tout particulièrement l'ethernet et les 2 ports USB au niveau de la souris... Très futé !
    * - Une puce WiFi vaseuse (Intel Wireless 6725) ;
    * - L'installation d'un système libre est un enfer... Dénominations absconses dans le BIOS pour virer secure boot & co... En même temps, sur cette gamme, Asus ne s'attend pas à voir du GNU/Linux... La carte réseau ethernet Realtek et la carte WiFi nécessitent des drivers proprios. Le son ne fonctionne pas sauf à brancher un casque sur line-out. Impossible de revenir d'un suspend-to-ram. Je n'ai pas cherché comment désactiver le touchpad... Voir http://shaarli.guiguishow.info/?Nn1Pyg


J'aurais bien voulu tester du Lenovo Thinkpad car j'en ai toujours entendu et vu le plus grand bien. Mais depuis Superfish (adware + MITM TLS, voir http://shaarli.guiguishow.info/?BxfR0Q) et la backdoor Lenovo Service Engine (voir http://shaarli.guiguishow.info/?X9TOQQ), je n'ai plus du tout envie de m'approcher de Lenovo...

Notons que je ne peux pas comparer avec mes desktops puisque j'ai vu passer 4 desktops dont 2 achetés tout prêt dans le commerce et 2 montés par mes soins et que ça c'est toujours bien passé, même avec secure boot pour le dernier PC acheté.


Ce que je retiens :
    * Plus jamais de Clevo. Au-delà des pannes (quelques exemplaires défectueux, ça peut arriver, sans compter que tous les assembleurs ont connus une période catastrophe), j'trouve qu'on ne gagne pas grand-chose : la personnalisation est plutôt limitée, on n'a pas vraiment plus d'informations sur les composants (voir les exemples que j'ai donnés), la pérennité de l'approvisionnement en composants de rechange n'est pas assurée comme partout ailleurs, un SAV décevant, tout ça pour un prix plus élevé.

    * Je pense aussi que les gros assembleurs traditionnels (HP, Lenovo, Asus,...) ont un rôle à jouer dans la chaîne : ils peuvent tester plusieurs combinaisons de composants et détecter les incompatibilités sur des chaînes de test. Du coup, ils arrivent sûrement à détecter les tendances des constructeurs de composants qui traversent une phase difficile et qu'il faut donc s'interdire d'utiliser temporairement. Si la conception d'une machine est fumeuse, il y a aura de forts retours SAV donc des actionnaires fortement mécontents alors que si je me plante dans le choix des composants sur le site web d'Anyware, ça emmerde que moi-même. Alors oui, ces assembleurs sont aussi plus sensibles aux magouilles du genre "je te fais telle ristourne si on signe un gros contrat de collaboration sur une longue durée" ou "si on arrête de bosser ensemble , c'est pour toujours", c'est bien comme ça que Microsoft s'est imposé. No free lunch.

    * Des ordinateurs qui fonctionnent comme un charme sous GNU/Linux, il y en a aussi dans les grandes surfaces en provenance de gros assembleurs. Par contre, un des avantages indéniables de Dell et Clevo, c'est que je n'ai pas payé la patente winwin et j'ai montré mon désintérêt sans avoir à faire des pieds et des mains pour me faire rembourser après coup.

    * Pour l'anecdote : le Compaq était le seul 15 pouces premier prix dans les grandes surfaces proches de chez moi à l'époque. Je l'ai acheté parce que mes seuls critères étaient 15 pouces + prix le plus bas possible. J'ai acheté le Dell car il répondait à mes besoins : 15 pouces, autonomie, SSD, perfs CPU, pas besoin de perfs GPU. Comme d'habitude, c'est ça qui est important : définir ses critères (aka ce que l'on veut) et ensuite trouver la machine adaptée, peu importe le lieu d'achat ou l'assembleur. Pour le Clevo, j'ai fait une fixation sur personnalisable, "petit" revendeur, matos facilement démontable, pas de licence winwin mais est-ce que c'était important et pertinent, en regardant après coup ? Bien sûr que non.

    * Du Compaq (ou HP Compaq de nos jours mais ma remarque reste valable) que ça soit en desktop ou en laptop, ça juste marche sous GNU/Linux.

Si tout ça peut éclairer votre prochain achat de matos... Le petit revendeur qui livre des configs custom n'est pas plus votre ami que la grande surface qui livre des configs standardisées de gros assembleurs.

Quand on gère une infra, il est important que le temps soit exact. Ça facilite grandement la compréhension des logs et leur corrélation pour debug un problème et ça garantit la fiabilité des informations qui peuvent être demandées en cas de réquisition judiciaire (dans le cas  d'un FAI/FSI).

Où installer des NTPd ?
On installe un NTPd sur chaque machine physique de l'infra. Ça, c'est du classique, du bien connu.

Faut-il un NTPd dans une VM ? On lit de tout sur le web et on entend de tout AFK. Je n'ai pas de VM sur mes serveurs, seulement du LXC donc je ne me suis jamais construit un avis. Par contre, j'ai pu me construire un avis en étudiant l'infra d'ARN (FAI associatif en Alsace) : au boot (ou pause/resume) la VM se sync avec l'horloge matérielle émulée par KVM... mais rien ne l'empêche de dériver durant son fonctionnement. Et en quelques mois, on s'est retrouvé avec les hyperviseurs synchronisés et les machines virtuelles désynchronisées... On parle quand même de plusieurs minutes...

Faut-il un NTPd dans un LXC ? Non, car le noyau est partagé entre l'hôte et tous les LXC. De plus, LXC ne donne pas la permission d'atteindre l'horloge système ni l'horloge matérielle.


Quand on a plusieurs serveurs, c'est une bonne idée de mutualiser un NTPd qui, soit sera la source de temps (avec un module GPS, par exemple), soit sera l'intermédiaire entre tout le réseau et une source de temps extérieure. Mais où installer ce serveur ?

Chez ARN, l'infra repose sur du Ganeti donc nos services sont dans une VM que l'on peut migrer d'un hyperviseur à l'autre en cas de panne/maintenance. Plus précisément, nous avons deux VM : une pour les services que nous exposons à l'extérieur (site web, récursif DNS, mail,...) et une pour les services internes, réservés aux abonnés. Chaque service se trouve dans un LXC sur une de ces VMs. Naturellement, c'est donc dans un LXC sur la VM "services internes" que nous avons installés le NTPd... et découvert que LXC ne donne pas la permission d'attaquer l'horloge matérielle... donc le serveur n'arrive pas à corriger l'horloge et finit par se croire désynchronisé et donc il ne permet plus de synchroniser les NTPd qui se connectent à lui...

Mettre le NTPd directement dans la VM ? C'est la deuxième chose que nous avons tenté. Sauf que la gigue fluctue trop et amène le NTPd à se croire désynchronisé et à ne plus pouvoir synchroniser les NTPd qui se connectent à lui. Cette différence peut avoir deux causes : une grande fluctuation de la latence réseau ou le fait que l'horloge dérive/fluctue très vite/trop entre deux mesures... Dans notre cas, c'était la deuxième cause. Un fait intéressant : si l'on cesse de synchroniser les NTPd installés sur les hyperviseurs sur le NTPd situé dans la VM alors la gigue est correcte et le NTPd dans la VM fait son boulot.

Au final, les deux hyperviseurs sont devenus les serveurs de temps de notre réseau et toutes nos VMs sont synchronisées dessus. Ça juste marche. Voir : http://www.linux-kvm.org/page/FAQ#I.27m_experiencing_timer_drift_issues_in_my_VM_guests.2C_what_to_do.3F


Quels serveurs de temps extérieurs utiliser ?
J'ai pour habitude d'utiliser ntp-p1.obspm.fr et canon.inria.fr. Pourquoi pas fr.pool.ntp.org ? Car les deux serveurs que j'ai cité sont des serveurs de strate 1 avec comme référence une horloge atomique pour le premier et un récepteur GPS pour le second. L'autre inconvénient technique est décrit ici : http://www.guiguishow.info/2011/08/24/installer-un-serveur-ntp-sur-openwrt/#toc-1908-ignore-versus-serveur-de-strate-2


Quelles commandes pour debug ?
    * ntpstat : simple et clair, elle affiche l'état du serveur (synchro/désynchro), à quel serveur le ntpd est synchronisé, la root dispersion (https://serverfault.com/questions/184257/seemingly-poor-quality-of-ntp-time-synchronization-using-a-gps-clock) et l'intervalle de temps selon lequel le ntpd communique avec le serveur. Seul défaut : il n'est pas IPv6-compliant et affiche une IPv4 qui ne correspond à rien quand le ntpd est synchro en IPv6.

    * ntpq -pn / ntpq -c peers : informations sur les pairs : strate, reference, joignabilité, déclage, gigue,...

    * ntpq -c rl : obtenir les variables système dont la root dispersion

    * ntpq -c as puis ntpq -c rv <assid> : différentes infos sur le peer dont les décalages et gigue des mesures
Merci à http://log.or.cz/?p=80 et au serverfault déjà cité.


Avec quoi monitorer un NTPd ?
Je ne voulais pas utiliser un des vieux scripts existant alors que ntpstat va chercher les bonnes infos et les présente de manière compréhensible. Du coup, j'utilise ce script que l'on exécute via SNMP : http://www.guiguishow.info/wp-content/uploads/2015/11/check_ntpstat.sh

J'ai brièvement parlé de VeraCrypt, fork maintenu de TrueCrypt, dans un shaarli (http://shaarli.guiguishow.info/?pZI4Og) et j'ai eu envie de voir ce que ça donne afin de voir si c'est recommandable.

Ce que je retiens de VeraCrypt :
    * L'interface reste la même donc toute la documentation TrueCrypt reste valable ;

    * Ce fork est maintenu, TrueCrypt ne l'est plus. Or, les mises à jour de sécurité sont capitales. Deux failles ont déjà été remontées en septembre 2015 (sans compter les failles mineures dans TrueCrypt remontées par l'action du Open Crypto Audit Project) ;

    * Paradoxalement, TrueCrypt a été audité, des personnes ont même vérifié que les sources distribuées produisent bien le binaire qui est distribué (compilation reproductible), ce qui n'est pas le cas de VeraCrypt. VeraCypt a peut-être des backdoors ? On ne sait pas : moins d'yeux pour se pencher dessus ;

    *  Un nouvel algo de chiffrement (SHA256), un algo déprécié sauf si chiffrement de la partition système (RIPEMD160). SHA-512 devient le nouvel algo de dérivation passphrase -> clé de chiffrement ;

    * Si vous chiffrez votre partition système, VeraCrypt vérifie, à chaque boot, l'intégrité du bootloader et vous en avertit. Ceci dans l'optique de prévenir d'une possible attaque « Evil Maid » (https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html) qui serait en cours. Le mal est fait mais vous êtes prévenus. Bien évidemment, dans un setup avec luks à côté (http://www.guiguishow.info/2011/08/31/installer-windowstruecrypt-fde-et-gnu-linuxdm-crypt-sur-le-meme-disque-dur/), ça va hurler sans arrêt puisque le bootloader est GRUB ;

    * Afin de rendre le bruteforce plus compliqué, les devs de VeraCrypt ont augmenté le nombre d'itérations lors de la dérivation passphrase -> clé de chiffrement donc le temps d'ouverture des volumes chiffrés a clairement augmenté... Sur un ordinateur récent, ça prend quasiment une minute pour ouvrir la partition système chiffrée. Je ne suis pas convaincu par la manip' : avec une mauvaise passphrase (trop courte, pas assez complexe), les itérations supplémentaires feront certes patienter l'attaquant mais avec une vraie passphrase, les itérations supplémentaires feront passer le temps nécessaire à la réussite d'un bruteforce de 1 million d'années à 10 millions (exemple pifométrique)... Ouais, ok, ça dépasse laaaargement mon modèle de menace. De plus, d'ici là, AES sera probablement tombé ou mes genoux en miettes (https://xkcd.com/538/), mais c't'un détails, sans doute. Apprendre aux utilisateurs à choisir une vraie passphrase me semble plus prometteur. La lenteur à l'ouverture me fait craindre un désintérêt des utilisateurs lambdas.

À part le troisième point, VeraCrypt me semble recommandable : on garde TrueCrypt et on améliorer et on le maintient.

«  J’ai bien peur qu’en France, ils finiront par faire la même chose. »

Se souvenir de cette députée qui, à la fin du vote de la loi terrorisme de 2014, a déclaré : « ensuite il faudra s'attaquer au chiffrement, etc. ».

Écouter Valls lors de sa présentation de la stratégie nationale de cyber-sécurité le 16 octobre 2015 : http://rue89.nouvelobs.com/2015/10/16/cryptologie-legale-qua-voulu-dire-manuel-valls-261691 et https://twitter.com/btreguier/status/655037317997031424 (lire tout le "thread", c'est hyper intéressant).

Nous sommes beaucoup de beaux parleurs à vouloir une presse qui fasse son taff de quatrième pouvoir mais nous sommes peu à financer les journaux qui sortent du lot. L'argument clé, c'est le prix...

Depuis juillet 2015, je me paye plusieurs journaux :
    * Canard enchaîné : 73,50€/an (hebdo + les dossiers)
    * Mediapart : 90€/an
    * NextInpact : 90€/an (l'abonnement commence à 35€/an mais je voulais être premium avec toutes les options car je pense que ça l'vaut bien)
    * Arrêt sur Images : 45€/an
TOTAL : environ 300€/an soit environ 25€/mois.

Alors oui, il y a d'autres médias qui m'intéressent qui sont en besoin de financement. Charlie... Sauf que mes tentatives de paiement ont échouées. Reflets.info.. Sauf que leur teasing permanent et leur suffisance ("regardez, ça fait des années qu'on le dit") masquent le très bon fond de cette initiative.

25€/mois... Pour 4 journaux. Pour des dossiers, des analyses poussées (fibre optique, projets de loi liberticides, manipulations mentales,...), des infos fraîches (nan parce que les dépêches AFP de faits divers en boucle, oui, en effet, ça n'a aucun intérêt, ...), une presse différente/unique (regardez les unes versus les unes des autres médias, ça parle tout seul) et soutenir une presse indépendante...

25€/mois... Ça me semble tellement insignifiant que je regrette de ne pas avoir payé de journaux plus tôt, même quand j'étais encore étudiant. J'ai bêtement suivi la "rumeur" qui dit que la presse c'est troooop cher et inaccessible aux étudiants / bas salaires... J'espère que ce shaarli vous permettra de vous faire une autre idée du coût d'une presse sérieuse, différente et indépendante.


Ce shaarli tombe alors que Mediapart et Arrêt sur Images ont lancé des campagnes de don. C'est un hasard : j'ai eu envie de parler de financement de la presse indépendante en citant mon exemple pour montrer que c'est possible et qu'on s'imagine des montagnes alors qu'il n'en est rien.

Pour le coup, je suis plutôt opposé aux campagnes de dons sus-citées : ces deux journaux ont appliqués un taux de TVA réduit jugeant la discrimination papier/numérique glop (et je soutiens ce point : Internet n'est qu'un support/moyen de transport donc rien de justifie cette discrimination sauf le maintien de la perfusion des gros de la presse écrite) et se sont fait redressés par le fisc avant que la loi ne fixe le taux à 2,1% pour toute la presse, numérique ou non. C'était des actes en connaissance de cause, des actes pour faire bouger les choses, de la désobéissance civile. Les premiers recours ont été perdus, les suivants ne sont pas suspensifs donc c'est perdu pour l'instant et il faut sortir la monnaie. Venir geindre et lancer un appel au don après coup, juste non quoi sinon c'est trop facile et dans ce cas, à titre individuel, je me fais financer des procès/pénalités contre des choses que j'estime mauvaises/injustes. La désobéissance ne justifie pas tout. Les lecteurs/rices (de la première heure donc) auraient dû être consultés au préalable sur le taux à appliquer & les risques. Préparer une gagnotte plus importante, quitte à renoncer à d'autres améliorations. Bref, d'autres méthodes étaient possibles.

Ha, tout ce bruit autour de la faille webrtc... Je n'y ai jamais cru (car pas logique techniquement) et vu que mon navigateur n'était pas faillible selon différents checks en ligne, je ne m'étais jamais penché dessus à fond. Sauf qu'hier, j'ai vu un cas d'un VPN OpenVPN avec lequel les checks affichent la vraie IP publique. :o

Souvenez-vous de vos cours SIP (pour ceux/celles qui en ont eu) : les sessions médias (audio/vidéo) ne passent pas par le serveur SIP (signalisation uniquement) pour éviter la charge mais s'établissent en direct. Sauf qu'avec les différents types de NAT et de filtrages baaaah ça marche pas... L'idée d'ICE (http://www.bortzmeyer.org/5245.html) est de ne poser aucune hypothèse et d'essayer plusieurs méthodes de traversée de NAT et se mettre d'accord pour trouver un chemin entre nous et le pair avec qui on veut causer...

Première étape : lister toutes les interfaces réseaux disponibles. Un « ip link show » quoi. Si vous avez une IP publique c'est-à-dire soit une IPv6 par votre FAI ou par un tunnel broker et/ou une IPv4 publique (université, labo de recherche, certaines entreprises), ne cherchez pas plus loin : votre IP apparaîtra dans les checks en ligne.

Vous ne me croyez pas ? Assignez une IP non RFC1918 mais réservée au benchmark/documentation (198.18.0.X/24 ou 192.0.2.X/24, par exemple) sur une interface, même une interface down : le check va vous la remonter alors que ces IP ne sont pas routables sur Internet. À ce stade, venir causer de faille du VPN utilisé ou de STUN, c'est ridicule au possible : ils ne sont pas concernés et c'est le but même d'ICE que de découvrir les différents canaux où un échange pourrait avoir lieu.

On notera qu'avant la version 43 de Firefox, la seule manière d'interdire ce listing, c'est de désactiver totalement webrtc en passant « media.peerconnection.enabled » à false. À partir de la version 43, on a de nouveaux paramètres plus fins (voir https://wiki.mozilla.org/Media/WebRTC/Privacy), dont « media.peerconnection.ice.force_interface » qui permet de spécifier la seule interface réseau à utiliser... On met tun0 et hooop, plus de fuite tout en permettant l'usage de webrtc.


Oui, mais tout le monde n'a pas une IP publique sur sa machine alors qu'il y a beaucoup de témoignages positifs sur le web... La vérité est ailleurs.

Deuxième étape : pour chaque IP récoltée, publique ou privée, le navigateur tente de joindre un serveur STUN qui lui retournera l'IP source de laquelle il a reçu le paquet du client. Ça permet de débusquer les NAT (oui, même avec des IP publiques sur sa machine, on peut avoir du NAT en frontal). C'est là que ça devient intéressant.

Le navigateur forge des paquets en mettant chaque IP qu'il a trouvé en IP source puis les envoie. Il est contraint de suivre la table de routage et donc les routes /1 plus spécifiques qu'OpenVPN ajoute dans la conf' la plus répandue (« redirect-gateway def1 ») l'emportent... et les paquets sont émis sur la tun. Échec, la véritable IP de l'utilisateur sera masquée (parce qu'OpenVPN jettera le paquet grâce à son mécanisme d'iroute (https://wiki.ldn-fai.net/wiki/Tuto_Serveur_OpenVPN#Notion_de_route_interne_.28iroute.29), parce que le presta VPN applique BCP38 (http://www.bortzmeyer.org/usurpation-adresse-ip.html), parce qu'une IP RFC1918 ne sera pas routée au delà du presta VPN,...).

Mais, on se dit que, pourtant, ping est capable d'émettre avec une IP/interface bien précise genre ping -I eth0 89.234.141.64. Le paquet bypass le VPN et sort par eth0. Deux conditions pour que ça fonctionne :
    * Il faut qu'il y ait une route englobant l'IP du serveur STUN (ou, dans l'exemple ci-dessous, de la mire utilisée par ping) accrochée à l'interface. C'est automatiquement le cas avec « redirect-gateway def1 » : eth0 (ou wlan0 si connexion WiFi) a toujours la route par défaut ;
    * Il faut avoir la bonne capabilitie ou être exécuté en root. ping est setuid ;) . Si vous avez un VPN, essayez curl --connect-timeout 5 --interface eth0 http://lehollandaisvolant.net/tout/ip/ puis la même préfixée par sudo, vous verrez.
Donc tout ça ne peut pas fonctionner sous GNU/Linux (sauf à lancer son navigateur web en root mais dans ce cas vous avez un problème beaucoup plus important que la fuite de votre vraie IP publique). \o/

En revanche, sur winwin, ça fonctionne plus souvent si l'on en croit les témoignages sur le web. Soit n'importe quel soft peut émettre sur n'importe quelle interface réseau sans avoir besoin de droits spécifiques, soit il faut être administrateur et vu la proportion du parc winwin qui tourne en permanence en administrateur, faut pas s'étonner... Je n'ai pas de winwin pour vérifier quelle hypothèse est la bonne.


Qu'en retenir ? Qu'un navigateur sur un système bien conçu avec un VPN correctement configuré chez un presta bien foutu et un pare-feu qui drop tout ce qui sort sans passer par le VPN, ne fait pas fuiter la véritable IP. Sauf si vous avez des IPs publiques sur votre machine. Tout ce bruit pour un système mal fichu...

Et pour le cas qui m'a amené à me pencher sur tout ça, alors ?! IPv4 publique sur eth0 puisque sur un réseau universitaire.

Hex to ASCII : xxd -r -p

\o/

Vous voulez un équivalent de ssh-add -l pour gpg-agent aka connaître la liste des clés prises en charge actuellement par gpg-agent ? Ça ne semble pas exister.

Par contre, on peut remonter l'info pour une clé donnée en utilisant sa fingerprint :
echo "GET_PASSPHRASE --no-ask <fingerprint_de_la_clé_sans_les_espaces> Err Pmt Des" | gpg-connect-agent

Retour : soit « ERR 67108922 Pas de données <Agent GPG> » si la passphrase associée à cette clé n'est pas mémorisée actuellement par gpg-agent, soit « OK <passphrase_de_la_clé_en_hexa> » dans le cas contraire.

Attention : n'oubliez pas que vous avez deux clés par défaut : la clé principale, qui sert pour signer (et vérifier votre signature) et une sous-clé dédiée au (dé)déchiffrement. La passphrase est la même pour les deux clés mais les deux clés ne sont pas forcément prises en charge par l'agent en même temps : ça dépend de l'action que vous réalisez (déchiffrement ou signature ;) (pas besoin de votre passphrase pour chiffrer à destination de votre clé ou pour vérifier une signature produite par votre clé ;) )).

Par défaut, gpg -k (aka --list-keys) n'affiche pas la fingerprint de votre sous-clé de chiffrement. Pour la récupérer, il faut utiliser la commande gpg -k --with-fingerprint <identité> ou, plus logique, gpg --fingerprint <identité>

Ok donc dans Debian Stable, on peut virer le fake ssh-agent de MATE facilement (Système -> Préférences -> Applications au démarrage) mais plus difficilement le gpg-agent... Pour ce faire : « gsettings set org.mate.session gnome-compat-startup "['smproxy']" ». Oui, on fait bien sauter tout gnome-keyring... Puis ajouter « use-agent » dans votre gpg.conf. À partir de votre prochain login, /etc/X11/Xsession.d/90gpg-agent s'occupera de spawn l'authentique gpg-agent.

Les autres méthodes (virer gpg-agent dans Système -> Préférences -> Applications au démarrage, dpkg-divert sur /etc/xdg/autostart/gnome-keyring-gpg.desktop, déplacer tous les fichiers /etc/xdg/autostart/gnome-keyring-*,...) ne fonctionnent pas.

Pourquoi virer le gpg-agent gnome-made ?
    * Chacun son boulot. Ce n'est pas à gnome de s'occuper de gpg/ssh ! ;

    * Le fake gpg-agent n'a pas toutes les fonctionnalités (gestion des cartes à puce, par exemple) ;

    * La personnalisation du délai avant oubli de la passphrase de la clé GPG par le fake gnome-agent se fait avec dconf (voir : https://askubuntu.com/questions/340809/how-can-i-adjust-the-default-passphrase-caching-duration-for-gpg-pgp-ssh-keys). Ce n'est pas intuitif. Enigmail permet de changer ce paramètre facilement depuis ses paramètres quand le vrai gpg-agent est utilisé.

Je vais détourner cette expérience de son objet initial mais ça ne montre pas aussi, dans un sens, que la vidéo-surveillance n'est pas efficace ? Les cobayes se seraient-ils mieux comportés en l'absence de la paire d'yeux et de l'animateur si un panneau avait dit « Stand placé sous vidéoprotection » ? Pouvaient-ils ignorer être vus/vidéosurveillés ? Je pense qu'ils se sont posés inconsciemment la question, au même titre que "quelqu'un peut-il me voir ?". On sent d'ailleurs le malaise du couple « allez, on s'tire ».

Je pense que, en plus du fait que la vidéosurveillance ne protège pas mais permet seulement d'avoir, possiblement (si la caméra est en état de marche, si l'auteur n'est pas masqué, si...), une chance de remonter à l'auteur d'un acte glop après coup, elle ne peut remplacer l'humain dans la dissuasion justement par tous les réflexes innés que nous avons face à nos congénères. Peut-être que l'évolution humaine changera ça par évolution de l'environnement (caméra partout)...

En terme comptable, c'est amusant de voir que de coûteuses caméras peuvent être remplacées par des affiches représentant des yeux. Bon ok, la supercherie ne durera pas dans le temps mais still. :D

Via HS-157 (http://hs-157.moe/).

Du coup, j'ai revu ma config en ajoutant :

  * media.eme.enabled -> false. «  JavaScript API for playing DRMed video content in HTML » (https://wiki.mozilla.org/Media/EME)

  * loop.enabled -> false. « Firefox Hello is the new online chat feature being offered by Mozilla Firefox web browser. » (http://www.trishtech.com/2015/01/disable-firefox-hello/ et https://wiki.mozilla.org/Loop/Load_Handling)

  * geo.enabled -> false (« Share Location Data with sites (about:config geo.enabled preference) »)

  * browser.safebrowsing.downloads.enabled -> false. « Non, Google ne connaîtra pas toutes les URL des sites web que je visite en échange d'une prétendue protection. »


J'en profite pour ressortir ce billet complet d'Alda que j'avais mis de côté : http://aldarone.fr/que-fait-firefox-sur-le-reseau-quand-on-le-demarre-et-faut-il-y-remedier/ . Je garde :

« geo.mozilla.org et location.services.mozilla.com correspondent de manière assez évidente à un service de géolocalisation. Mozilla connait donc l’emplacement approximatif de tel navigateur. Ces requêtes disparaissent en passant browser.search.geoip.url à false cela a donc à voir avec les fonctionnalités de recherche comme nous le verrons dans le détails des options.

Enfin, geo.wifi.uri aide la géolocalisation de Firefox à se montrer plus précise en utilisant Google Location Services. Firefox envoie donc votre IP, la liste des réseaux Wifi environnants et un identifiant unique régénéré toutes les deux semaines à Google pour obtenir une localisation fiable au niveau de la rue au lieu de n’avoir que GeoIP qui est fiable au niveau de la ville (et encore, parfois on a que le pays). Sans cette option, la précision prend un sacré coup ce qui peut jouer des tours aux personnes qui en ont l’utilité. »

et :  services.sync.prefs.sync.browser.safebrowsing.enabled -> false + services.sync.prefs.sync.browser.safebrowsing.malware.enabled -> false