GuiGui's Show

« Ne culpabilisez pas d'être révolté [...] C'est bien d'être révolté. Après, il faut rationaliser ça. Ça peut prendre plein de formes. [...]  Dans le journalisme, ça nécessite d'accumuler des preuves pour prouver des choses et ça sert à quelque chose au moins à informer les gens qui peuvent s'en saisir.  N'ayez pas mauvaise conscience à vous révolter, à avoir un point de vue. C'est la seule manière d'exister, c'est la seule manière de ne pas être ambigu et de savoir se comporter face aux grands problèmes du monde. [...] Je pense qu'on est dans une période où il est difficile d'assumer la révolte ou l'indignation parce qu'on culpabilise cette indignation et cette révolte. Immédiatement vous êtes un "radical", vous êtes immédiatement  sur la touche. C'est important d'arrêter avec cette mauvaise conscience. Y'a tellement de chantiers dans le monde aujourd'hui. [...] Nous, on a mis du temps avant d'être un peu grandes gueules et révoltés, ça se construit, ça prend du temps à construire cette envie et cette volonté de faire. »

Chez https://jeekajoo.eu/links/?aGEPPw via https://www.ecirtam.net/opennews/?xMBlaA

« « Plus des deux tiers des lecteurs de Bild.de utilisant un adblocker l'ont désactivé afin de pouvoir continuer à consulter le quotidien allemand en ligne. »

Donc en gros, dire « laissez-nous vous traquer, engorger votre réseau et pourrir le cerveau ou ne nous lisez plus du tout » ça marche.

Effectivement, dans ce cas, pourquoi revoir son modèle économique… »

Je ne savais pas comment le formuler mais voilà, tout est dit. Je trouve ça profondément navrant et triste. :'(

« À l'occasion du lancement la campagne de dons pour 2016, nous nous sommes entretenus avec Adrienne Charmet-Alix, coordinatrice des campagnes de la Quadrature du Net.

[...]

Cette année, La Quadrature du Net a lancé plusieurs actions judiciaires à l’encontre d’actes du gouvernement, ce qui est relativement nouveau…

Oui, c’est un des gros points de l’actualité de 2015. Mais ce n’est pas uniquement La Quadrature. C’est une action qui est faite conjointement avec FDN (French Data Network) et FFDN (la Fédération FDN), par un petit groupe de juristes qui travaillent énormément.

Cette année nous avons attaqué les décrets d’application de la loi de programmation militaire sur la collecte de données personnelles sur les réseaux télécoms, les décrets d’application de la Loppsi sur tout ce qui est blocage de sites, les décrets sur le déréférencement de sites internet, et le décret secret sur la DGSE de 2008.

On s’attaque essentiellement à la mise en application des lois qui ont été votées (une liste intégrale des recours devant le Conseil d’État et le Conseil constitutionnel est publiée sur le site de la Quadrature du Net, ndlr). Sur la plupart de ces recours qui sont des procédures très longues, nous sommes encore dans une phase d’échange d’arguments avec le gouvernement.

C’est une stratégie que l’on va poursuivre, qui nous semble très importante, parce que le processus législatif et politique est absolument bloqué, de partout. Une des armes majeures des ONG maintenant, c’est le terrain judiciaire. Donc pour nous il est très important d’occuper ce terrain, en remontant en bout de course jusqu’aux institutions européennes puisqu’on sait qu’en France c’est totalement bloqué.

[...]

Et les autres travaux importants de cette année ?

Au niveau européen, on s’est retrouvé dans une situation complexe, puisque les deux gros règlements sur lesquels on travaille, qui sont la neutralité du net et la collecte des données personnelles, ont été en phase de trilogue pendant toute l’année 2015. Ce sont des phases où il est très compliqué pour nous d’avoir une action parce qu’on n’est absolument pas dans une phase de transparence, démocratique… On a fait un travail beaucoup plus sous-terrain, d’amendements, d’analyse juridique, etc., peu visible pour le grand public.

De même, nous avons réalisé un gros travail sur nos propositions positives, qui n’avaient pas été mises à jour depuis 2012. On a travaillé dessus en même temps que nos réponses aux deux consultations sur le projet de loi numérique, ce qui nous a permis de reprendre l’ensemble de nos sujets et de faire des propositions positives qui sont des grands principes détaillés, qui ne sont pas une réaction à des lois en cours de vote.

[...]

Et y a-t-il une écoute gouvernementale sur ces propositions ?

C’est particulier… Je pense qu’on est parfaitement identifié par le gouvernement. On a vraiment de très mauvaises relations avec le ministère de l’Intérieur — je crois que Bernard Cazeneuve ne nous aime pas, et je crois que c’est réciproque d’ailleurs (rires). Sur les questions de surveillance, vraiment il y a une incompréhension totale, il n’y a absolument pas de dialogue possible.

Avec Axelle Lemaire (secrétaire d’État au numérique, ndlr), c’est un peu différent. Elle dit qu’elle nous écoute, mais en même temps on voit bien qu’elle n’a pas de pouvoir — et le projet de loi numérique sorti vendredi en est l’illustration. Elle peut nous écouter, c’est très bien, mais en réalité on voit que les pouvoirs ne sont pas du tout de son côté.

Justement, que vous inspire le projet de loi sur la République Numérique d’Axelle Lemaire ?

Ça aurait pu être une loi fondamentale. En réalité elle s’est tellement vidée au fur et à mesure du temps, et elle continue tellement à se vider de son sens et de son contenu, qu’elle ne va servir à rien et qu’en tout cas sur nos sujets, elle n’aura probablement aucun impact.

Le processus de consultation était une bonne chose, mais on a prévenu dès le départ qu’il serait validé par ce qu’il resterait ou non dans la loi. Et là ce qu’on voit sortir, c’est qu’en gros la consultation a eu lieu, les gens ont participé, des propositions (notamment les nôtres) ont été très massivement soutenues par les citoyens qui ont participé… et pour autant on n’en retrouve pas grand chose dans le projet de loi. Le jeu traditionnel des lobbys et des arbitrages ministériels fait que finalement le processus de consultation n’a pas servi à grand chose.

[...]

Et quels seront les grands sujets pour La Quadrature du Net en 2016 ?
[...]
On voit également arriver des choses comme la régulation des plateformes en ligne, où il y a beaucoup d’enjeux en termes de centralisation ou décentralisation du Web, de protection des données, et de souveraineté ou non.

[...]

2016 sera aussi une année pré-électorale. Quelle sera votre position dans le débat politique ?

Pour l’instant nous n’avons pas terminé de réfléchir là dessus. Le problème des années pré-électorales, c’est que les candidats sont prêts à s’engager sur tout et n’importe quoi, et derrière ils ne font jamais ce qu’ils ont dit. En revanche, ce qui est extrêmement important pour nous, c’est de faire entrer la question des droits fondamentaux dans l’espace numérique dans le champ des politiques.

Aujourd’hui on a très peu de positionnements politiques forts sur ces questions là. On a une majorité de responsables politiques qui ne comprennent pas très bien, ou qui sont près à céder à l’impératif de sécurité à n’importe quel prix. C’est à nous de faire entrer ces questions là dans la conscience politique et de mobiliser les citoyens pour qu’ils interpellent les candidats sur ces questions là, afin qu’ils définissent une vraie ligne politique.

C’est quelque chose qui m’a beaucoup frappé lors de la loi sur le Renseignement. Les parlementaires me disaient : « mais moi, personne ne vient me voir dans ma permanence pour me dire qu’il faut défendre les droits des citoyens en ligne ». Et donc, ils ne les défendent pas. »

« La Quadrature du Net lance aujourd'hui sa campagne de soutien annuelle. Pour conserver son indépendance totale, La Quadrature appelle ses soutiens à s'engager matériellement dans la défense des droits en soutenant une association entièrement dédiée à la promotion positive des libertés, à l'engagement des citoyens dans la Cité, et au développement d'une société numérique libre et ouverte. Au terme d'une année où les libertés fondamentales dans l'espace numérique ont été fortement menacées, voici venu le temps de préparer l'avenir.

[...]

L'année 2015 a été très active pour La Quadrature du Net, et donc pour les libertés. En France, la lutte contre les lois de surveillance a été au cœur de nos actions depuis le mois de janvier, tandis qu'en Europe nous avons œuvré pour la neutralité du Net, la protection des données personnelles et la réforme du droit d'auteur.

Dans le même temps, nous avons travaillé à une importante mise à jour de nos propositions positives pour formuler ce que nous voulons promouvoir comme réformes et principes pour une vision équilibrée d'Internet.

Nous avons également développé la présence de La Quadrature du Net dans plusieurs villes de France, en encourageant l'action des très nombreux bénévoles et sympathisants de l'association. Le travail commun avec des partenaires (associations, syndicats, professionnels) français et internationaux a aussi été très développé, notamment pendant les discussions parlementaires houleuses sur la loi Renseignement.

[...]

Pour 2016, les principaux chantiers de travail déjà identifiés seront :
    * Travailler autour de la loi Numérique qui sera discutée début 2016
    * Travailler autour de la réforme du droit d'auteur au niveau européen
    * Poursuivre le travail de propositions positives
    * Refondre entièrement le site internet de La Quadrature du Net afin de le rendre plus accessible au grand public
    * Poursuivre le développement de l'action bénévole autour de La Quadrature du Net, sur l'ensemble du territoire français
    * Développer ou refondre les outils de participation citoyenne (Memopol, PiPhone, etc) »

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)

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.

« 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.

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

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.

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.