gouttegd a écrit 1805 commentaires

Ça va, on a compris…

Au-delà de systemd et d’Apache httpd qui passe (enfin !) en 2.4, il y a plusieurs autres petites choses intéressantes dans les versions de certains logiciels (par rapport à la précédente stable) :

• OpenSSH 6.7 : prise en charge des algorithmes ed25519, Chacha20-poly1305, AES en mode GCM et HMACs en mode Encrypt-Then-MAC ;

• Postfix 2.11 : prise en charge de DANE ;

• Prosody 0.9.7 : prise en charge d’IPv6 et (via LuaSec 0.5) d’algorithmes permettant la “Forward Secrecy”.

On peut raisonnablement supposer que le réseau de OVH l’hébergeur est distinct de celui de OVH le fournisseur d’accès (raison pour laquelles ils ont deux numéros d’AS différents), et qu’une panne de l’un n’affectera pas systématiquement l’autre. C’est déjà un début, ça me convient.

(L’offre n’est pas limitée à une seule personne — mon serveur a je pense largement de quoi héberger d’autres zones —, donc si d’autres sont intéressés, ce n’est pas trop tard.)

Dans mon cas, où tous les services sont sur une seule machine (exactement la même machine qui sert la zone DNS…), l’intérêt est réduit, en effet. Inutile de le nier, ma motivation principale n’est rien de plus que la satisfaction de faire les choses correctement.

Mais quelques informations (pas beaucoup, je te l’accorde) publiées dans ma zone restent intéressantes même dans le cas où les services sont temporairement inaccessibles, comme par exemple :

– l’adresse du serveur de courrier (au moins le serveur SMTP de l’expéditeur saura déjà où l’envoyer, même s’il devra attendre pour procéder à l’envoi proprement dit) ;
– les clefs DKIM (un client peut vouloir vérifier une signature DKIM à n’importe quel moment) ;
– dans le même ordre d’idée, les enregistrements SPF et DMARC ;
– l’empreinte de ma clef OpenPGP (publiée via un enregistrement CERT).

Parce que ça force l'infrastructure et l'intégralité des clients à supporter le bousin ?

DANE est une des méthodes les moins intrusives (beaucoup moins que CT). Tout est déjà en place pour la supporter. Tous les serveurs et résolveurs DNS dignes de ce nom supportent déjà DNSSEC (et DANE n’a pas besoin d’être explicitement pris en charge, les enregistrements TLSA ne sont que des enregistrements DNS comme les autres). Aucun protocole n’a besoin d’être modifié. Tout ce qu’il manque est le support des navigateurs.

Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.

Ça c’est complètement faux. Côté serveurs, je le répète, tous les serveurs DNS dignes de ce nom gèrent DNSSEC. Côté client, ce n’est pas parce que les navigateurs regardent ailleurs que personne d’autre n’est intéressé. DNSSEC a bien d’autres intérêts au-delà du seul web.

Les serveurs de courrier électronique y ont un intérêt pour chiffrer les communications SMTP de serveur à serveur (en utilisant DANE pour authentifier le pair d’en face, et donc faire un peu mieux que du chiffrement à l’aveugle sans savoir à qui on parle). Les clients SSH y ont un intérêt pour authentifier les serveurs SSH (enregistrements SSHFP, seulement fiables si on est sûr que l’enregistrement n’est pas frauduleux).

Je ne dis pas que DNSSEC n’est pas monstrueux. Personne ne peut lire le RFC décrivant NSEC3 et ne pas penser que c’est une monstrueuse usine à gaz. Mais d’une part, ce n’est pas plus une usine à gaz que bien d’autres protocoles que l’on utilise sans même y penser (dont, au passage, X.509 et TLS, dont la complexité effare bien des experts en sécurité), et d’autre part, c’est complètement déployable et même déployé.

Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.

C’est du même niveau que les magouilles consistant à fabriquer des faux certificats à la volée. Que DNSSEC contrarie ce genre d’agissements est une feature, pas un bug. Les responsables « d’environnements pro » qui veulent contrôler le moindre traffic de leurs utilisateurs devront le faire de manière ouverte et assumée, pas dans le dos des utilisateurs.

L'idée sur le long terme est de pouvoir "pinner" dynamiquement chaque certificat sur ces databases, et ça çareglerait pas mal de problèmes.

Lesquels, et comment ? Par ailleurs, rien dans la description de CT ne laisse transparaître une telle « idée sur le long terme ».

Certificate Transparency ne sert à rien

Je corrige mon propos, Certificate Transparency pourrait être utile dans un cas : celui des magouilles du genre Superfish, où un logiciel malveillant ajoute son propre certificat au magasin du système et s’en sert pour forger des faux certificats à la volée. Les faux certificats ne pourraient pas obtenir de SCT et seraient donc refusés.

Cette technique étant assez répandue (outre le cas emblématique de Lenovo, elle est semble-t-il courante en entreprise, pour déchiffrer le traffic des employés), c’est un cas d’utilisation non-négligeable.

Néanmoins :

• D’une part, CT n’est pas la seule technique potentiellement efficace contre cette attaque (DANE, Convergence, Monkeysphere, éventuellement le pinning si la première connexion au site se fait avant l’installation du malware, …).

• D’autre part, en fait aucune technique ne peut être réellement efficace contre cette attaque (CT pas plus que les autres), puisque qu’elle part du principe que l’attaquant a la main-mise sur la machine du client (via un malware, ou si l’attaquant est l’administrateur de l’entreprise). C’est une conclusion établie en matière de sécurité qu’il n’y a pas de sécurité qui tienne la route si la machine terminale est compromise. Les nouveaux Superfish en puissance pourront toujours s’adapter pour contourner n’importe laquelle des méthodes envisagées ici (CT ? On désactive la vérification des jetons SCT. DANE ? On falsifie les réponses DNS — rappelez-vous que DNSSEC ne sécurise pas le dernier kilomètre et suppose que le résolveur validant est de confiance. Convergence ? Je n’ai pas assez étudié le principe, mais je ne doute aucunement qu’un contournement soit possible, peut-être en manipulant la liste des notaries. Etc, etc).

Non, on fait simplement des choses avec des étapes de transitions raisonnables.

Tu as ton certificat traditionnel émis par une CA reconnue qui autorise les visiteurs à consulter ton site sans avertissements (mais sans sécurité non plus, merci le modèle PKIX…), en quoi est-il déraisonnable d’épingler ce certificat dans un enregistrement TLSA ? Tu ne perturbes en rien le fonctionnement des navigateurs qui ne connaissent pas DANE.

Il n'a jamais été designé pour les remplacer, uniquement corriger leur problèmes: ce qui est le plus urgent à faire.

Certificate Transparency corrige quoi au juste ?

Autant le dire : Certificate Transparency ne sert à rien, et surtout pas à « corriger les problèmes des CA ».

L’objectif de Certificate Transparency est de pouvoir détecter quand une « rogue CA » émet un certificat illégitime. Quand tous les navigateurs exigeront que les certificats soient affublés d’un ou plusieurs SCT pour être acceptés, une CA ne pourra pas émettre de certificats sans l’enregistrer dans les logs de Certificate Transparency (nécessaire pour obtenir le SCT), ce qui permettra à tout le monde de découvrir ce certificat illégitime.

Et après ? Ben rien. Certificate Transparency ne dit absolument rien quand à ce qui doit se passer ensuite. La vision bisounours est que les éditeurs de navigateurs, en constatant que la CA a émis des certificats frauduleux, prendront immédiatement la décision qui s’impose, à savoir virer la CA indélicate de leurs magasins d’autorité de confiance.

C’est tellement naïf que je ne peux pas imaginer une seule seconde que les promoteurs de Certificate Transparency y croient réellement.

On n’a jamais viré sans ménagements une CA des magasins des navigateurs. Quand une CA indélicate est prise la main dans le sac, on s’indigne, on crie (surtout si la CA est chinoise, beaucoup moins si elle est américaine…), mais on tergiverse beaucoup et au final on ne fait pas grand’chose.

(De toute façon une action en suppression immédiate et inconditionnelle au moindre certificat émis en doublon ne serait pas mieux : il peut y avoir des raisons légitimes pour qu’une CA émette un certificat pour un domaine qui en a déjà un ailleurs… par exemple pour fournir le backup pin requis par HPKP.)

La seule raison d’être de Certificate Transparency est d’asseoir un peu plus le cartel des CA, en exigeant :

• de la part des navigateurs, qu’un certificat possède un ou plusieurs SCT pour être accepté ;

• de la part des journaux Certificate Transparency, qu’un certificat soit émis par une CA reconnue pour l’enregistrer et lui donner son SCT (en particulier, les certificats auto-signés sont explicitement exclus).

Et je ne parle pas du bordel que représente l’implémentation de Certificate Transparency, qui demande des modifications à peu près à tous les niveaux.

Je n'aime pas plus les certificate authority que vous: elles coûtent cher, ont un monopole honteux, une éthiques douteuses pour certaines d'entre elles. Je les verrai avec joie disparaitre.

Certificate Transparency est justement conçu pour s’assurer qu’elles ne disparaissent pas.

Un internet sans CA viendra bien plus probablement de choses comme :

Toutes ces méthodes sont intéressantes et la meilleure solution est à mon avis de permettre d’utiliser toutes ces méthodes selon ses besoins et convenances, plutôt que de vouloir absolument une méthode unique. DANE est une des méthodes possibles. Encore une fois, personne n’a prétendu que ça devait être la seule. Contrairement aux CA, qui ont pris soin de se rendre indispensable.

On implémente le pinning proprement au niveau de TLS ? Et on mets en place le certificate transparency sur le long terme ?

Pourquoi pas ? Implémenter DNSSEC/DANE n’interdit pas les autres méthodes. Personne n’a jamais dit que DANE devait être le seul moyen d’authentifier un serveur TLS.

Tout comme IE6 ont pourrit la vie des devs Web pendant 10 ans, tu vas forcément continuer à avoir des utilisateurs sous IE9 ou Android 2.3 qui ne géreront pas correctement DANE pendant des années et des années.

Avec cet argument là, autant ne rien faire du tout…

Donc rien que pour ceux là, tu devras aussi faire signer ton certificat par une autorité de certification et rentrer dans le business juteux des CAs qui continueroent de vivre paisiblement.

Encore une fois, DANE n’a pas la prétention de remplacer d’un coup tout le reste. Au contraire, DANE prévoit explicitement la possibilité d’être utilisé en complément du système PKIX. Ceux qui le souhaitent peuvent utiliser DANE exclusivement (sélecteur TLSA sur DANE-TA ou DANE-EE), mais ce n’est pas une obligation.

Au passage, Certificate Transparency est beaucoup moins flexible sur ce plan, puisqu’il interdit explicitement tout certificat qui n’aurait pas été émis par le cartel des CA.

On fait confiance au cache des DNS, donc il faut systématiquement un serveur DNS local à la machine ?

Pas forcément « systématiquement », mais c’est recommandé, en effet. Au minimum, il faut que le résolveur DNS validant soit sur le réseau local, et que celui-ci soit de confiance. C’est le problème dit de la « sécurité du dernier kilomètre », qui sort du cadre de DNSSEC. Si le résolveur validant est distant, il faut un mécanisme de protection supplémentaire, comme TSIG par exemple.

Ça parait trop aberrant, donc ça doit être autre chose. Il a une notion de CA ?
Et du coup il y a même problème de pining au niveau de DNSSEC, soit c'est piné par le client, soit ça utilise un CA ?

Dans le cas idéal, le résolveur validant n’a besoin d’épingler que la clef de la racine. La plupart des logiciels résolveurs la connaissent déjà (tout comme ils connaissent les adresses des serveurs de noms de la racine).

J'en déduis que pour chaque site que je visite il faut que je le whitelist ?

Seulement si on ne peut pas remonter jusqu’à la racine, c’est-à-dire dans le cas (non idéal) où une des zones parentes n’est pas signée.

Par exemple, si la zone fille.example.com. est signée mais que sa zone parente example.com. ne l’est pas, il est impossible de remonter jusqu’au TLD com. (signé) et a fortiori jusqu’à la racine (dont le résolveur connaît la clef). Jusqu’à ce que le gérant de example.com. signe sa zone (et communique sa clef au gérant de com.), la seule solution pour le résolveur souhaitant valider les données de fille.example.com. est d’ajouter directement la clef de cette zone dans la liste des clefs de confiance.

Merci pour le lien mais qu'est-ce que je dois conclure?

Par exemple, que si la simple possibilité de mélanger options et arguments te choque tant que ça, tu peux simplement mettre export POSIXLY_CORRECT= quelque part dans /etc/profile, et laisser ceux qui apprécient cette fonctionnalité en profiter.

Que c'est effectivement pour le plaisir de ne pas faire comme tout le monde?

Mais qu’est-ce que tu vas chercher ? C’est juste une fonctionnalité que certains (dont moi) jugent utile, c’est tout.

À part faire parler des gens pendant des heures entières sur les avantages et inconvénients supposés d'un système dont l'utilité est à mes yeux plus que douteuse, je ne vois pas vraiment d'autres effets?

Bah écoute, si tu ne veux pas en parler pendant des heures entières, définis juste POSIXLY_CORRECT dans ton environnement et arrête d’en parler.

https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Standards.html#Non_002dGNU-Standards

Tu peux avoir un couplage plus fort, je n'ai pas remonté l'historique assez loin. Un noyau est forcément dépendant de ce que propose sa libc

Pas vraiment, non. Ce sont surtout les programmes en espace utilisateur qui dépendent beaucoup de ce que propose la libc.

Il y a plus de couplage entre la glibc et le reste de l’espace utilisateur, qu’entre le noyau et l’espace utilisateur (y compris la glibc).

Ça se traduit par le fait que mettre à jour la glibc est plus délicat que de mettre à jour le noyau : notamment, il n’est pas rare que de nombreux programmes en espace utilisateur doivent carrément être recompilés (pas forcément mis à jour, mais recompilés quand même) contre la nouvelle glibc pour fonctionner, alors qu’une mise à jour du noyau n’impose jamais de recompiler quoi que ce soit (ni la glibc, ni le reste de l’espace utilisateur).

Une glibc de 2012, ce n'est pas ce que j'appellerais vieux. ;)

Au moins ça correspond à une situation plus vraisemblable (et probablement plus proche de ce que l’auteur de la question avait à l’esprit) que de parler de faire fonctionner « des logiciels d’aujourd’hui avec un Linux 1.0 ».

L'inverse est tout aussi vrai, des appels systèmes de Linux nécessitent des versions de glibc particulières.

Ce sont « des appels systèmes » qui nécessitent une version suffisamment récente de la glibc, pas le noyau dans son ensemble. Le noyau reste complètement utilisable sans ça, simplement tes programmes ne bénéficieront pas des toutes dernières fonctionnalités.

tu ne peux pas utiliser de versions trop décolorées

C’est pour ça que quand je mets à jour mon noyau, je rajoute toujours une lingette de Decolor Stop®, comme ça ma glibc et mon noyau gardent toutes leurs couleurs éclatantes.

je me demande si les versions glibc systemd et kernel doivent être corréler ?

Pour Systemd, je ne sais pas trop¹, mais pour la glibc, d’aussi loin que je me souvienne, ça ne m’a jamais posé le moindre problème de mettre continuellement à jour le noyau tout en gardant une glibc vieille de parfois plusieurs années (là par exemple, j’ai une glibc 2.17 datant de 2012 sur un noyau 3.18 compilé le mois dernier). Même le passage du noyau 2.4 au noyau 2.6 (utiliser un noyau 2.6 avec une glibc — et plus généralement tout l’userspace —compilée contre un noyau 2.4) n’avait posé aucun souci à l’époque.

En revanche, si le noyau proprement dit peut être « désynchronisé » de la glibc, pour les développeurs ou ceux qui installent des logiciels à partir des sources il est très fortement conseillé que les fichiers d’en-tête du noyau (/usr/include/linux) restent ceux contre lesquels la glibc a été compilée.

je m'explique si je veut, par exemple, mettre un noyau 4 sur une distribution qui utilise systemd je doit espérer que systemd soit à jour et le compiler aussi ?

Dans ce sens-là, a priori, non. Ce serait plutôt dans l’autre sens (installer la dernière version de systemd avec un noyau plus ancien) qu’il pourrait y avoir problème.¹

---

¹ J’ai le vague souvenir d’un troll d’une discussion ici-même où quelqu’un faisait part d’un message de Poettering expliquant qu’il entendait coller de très près au noyau Linux, et qu’il n’était pas exclu que des versions de systemd exigent une version suffisamment récente du noyau. N’utilisant pas systemd, je ne sais pas ce qu’il en est dans les faits.

Ça peut être piégeur si un jour tu tombes sur un script (ou un autre extrait de code quelconque, dans une documentation par exemple) qui fait ceci :

ln cible -s lien

ou même

ln cible lien -s

… ce qui est parfaitement valide avec le ln de GNU.

Rappel : la plupart des outils GNU n’imposent pas que les options précèdent systématiquement les arguments positionnels, sauf si la variable POSIXLY_CORRECT est définie dans l’environnement.

Je sais pas si c'est ce que veut dire le -s

Non, ça veut dire “créer un lien symbolique” (soft link). Le comportement par défaut de ln (sans cette option) est de créer un lien physique.

dans un environnement comme celui de mon école, il est quasi-necessaire d'ajouter une sécurité demandant un mot de passe supplémentaire qui ne puisse être esquivé d'aucune façon, parce que il suffit d'une seconde d'inattention et hop, une clef de plus dans le authorized_keys. Sans compter les petits scripts codé par des petits malins qui permettent de lancer divers jeux, et qui installent les clefs publiques au passage…

Si on veut combiner l’authentification par clef publique avec une authentification par mot de passe, on peut configurer sshd pour s’en charger lui-même (AuthenticationMethods publickey,password) plutôt que se fier à un bidouillage du .bashrc…

Je ne sais pas ce que c’est que cet environnement, mais si n’importe qui peut ajouter une clef publique dans le ~/.ssh/authorized_keys (le dossier de l’utilisateur, y compris ~/.ssh, est accessible en écriture à tout le monde ? wtf ?), qu’est-ce qui empêcherait ce même n’importe qui de tripatouiller le ~/.bashrc pour, par exemple, supprimer la demande de mot de passe ?

En fait, je dirais a priori qu’utiliser SSH dans un environnement pareil revient un peu à utiliser une porte blindée avec digicode juste à côté d’une fenêtre grande ouverte…

Ca n'a rien à voir.

Euh, si, l’accessibilité demande de ne pas faire n’importe quoi avec CSS. Par exemple, ne pas essayer de cacher un paragraphe en le « poussant à l’extérieur » de l’écran, ou ne pas mettre d’informations importantes seulement dans du contenu généré par CSS (propriétés content)…

Et je vois que la page principale redirige maintenant automatiquement vers celle-ci en absence de Javascript (ce n’était pas le cas ce matin). Merci !

(C’est malin, et contre quoi je vais rouspéter moi maintenant ?

Ah oui, je sais : les boutons de partage Facebook/Twitter/Google+… zut, non même pas, ce sont des boutons inactifs, qui ne font rien tant qu’on ne clique pas dessus ! Cette fois je suis fait !)

On peut faire des sites accessibles avec javascript, il n'y a rien qui s'y oppose.

On peut, oui. Ça s’appelle la graceful degradation. Le principe de base est que l’information essentielle du site doit être disponible sans Javascript. Si le Javascript est utilisé par-dessus pour enrichir la navigation, je n’y vois aucun problème.

En revanche, lorsque rien n’est consultable sans Javascript, ce qui est le cas du site mentionné, là ça me pose problème.

Non, je n’activerai pas Javascript pour accéder à ton site de merde, toi le développeur web (on ne dit plus webmaster paraît-il) qui se moque de l’accessibilité comme de sa première chaussette !

Et c’est la Quadrature du net qui est derrière ça, bon sang, ce serait la première « web agency » venue à la limite je pourrais comprendre, mais là…

Je sais, je sais, post inutile, vous pouvez moinsser mais ça soulage.

Je ne vois pas en quoi c'est un standard

Genre, je veux que les bibliothèques s’installent dans /usr/lib64 et non dans /usr/lib (c’est l’option qui a été retenue pour Slackware64), quelle est l’option à utiliser ? Avec un projet autoconfisqué, ce sera toujours --with-libdir=/usr/lib64. Avec CMake, ce sera tantôt -DLIB_SUFFIX=64, tantôt -DWANT_LIB64, tantôt -DLIB_INSTALL_DIR=/usr/lib64, tantôt -Dpackage_INSTALL_LIB_DIR (avec package dépendant du projet)…

Je veux installer les pages de manuel dans /usr/man au lieu de /usr/share/man ? Avec les autotools, ce sera toujours --with-mandir=/usr/man. Avec CMake, ce sera tantôt -DMAN_DIR=, tantôt -DMAN_INSTALL_DIR=, tantôt -Dpackage_MAN_PATH=…

Je veux changer le répertoire des fichiers de configuration ? Avec les autotools, ce sera toujours --with-sysconfdir=. Avec CMake ? Au choix, -DSYSCONFDIR=, -DSYSCONF_INSTALL_DIR=…

Je veux stripper les binaires à l’installation ? Avec les autotools, make install-strip, toujours. Avec CMake, parfois on peut faire make install/strip, et parfois non, il faut stripper à la main après.

Et je tape sur CMake, mais les 99 prétendus prétendants à la succession des Autotools ont le même problème.

Dès que je dois installer un logiciel à partir des sources (ce que je fais relativement fréquemment, puisque j’ai choisi d’utiliser une distribution qui fournit de base peu de paquets) et que je ne vois pas de configure dans l’archive, je pousse un soupir « purée, alors c’est quoi cette fois le système de build et c’est quoi les options à utiliser pour ce projet ? »

Il y a peut-être eu un autre problème plus compliqué que ça, sur un rapport de bug lié quelqu’un rapporte la même erreur (certificat inconnu) pour un certificat émis il y a plusieurs mois. Cela semble résolu puisque le serveur OCSP répond désormais que le certificat est valide (testé à l’instant), mais ça laisse quand même planer un doute sur la qualité du service OCSP…

Et ce doute va faire que lorsqu’un serveur OCSP de Startcom renverra une réponse négative à juste titre, tout le monde l’ignorera en disant « non mais les serveurs OCSP de Startcom, ils n’ont jamais été fiables, vas-y, passe outre le message d’erreur »…

le réglage est également sur «non requis» par défaut

À ma connaissance, le réglage par défaut est de tenter de confirmer la validité du certificat en contactant le serveur OCSP, mais d’accepter quand même le certificat si jamais le serveur OCSP ne répond pas (soft-fail, par opposition au hard-fail, où l’impossibilité de contacter le serveur OCSP entraîne automatiquement le refus du certificat).

Ici, d’après le message d’erreur que tu rapportes :

Une erreur est survenue pendant une connexion à blabla. Le serveur OCSP n'a pas de statut pour le certificat. (Code d'erreur : sec_error_ocsp_unknown_cert)

Le serveur OCSP a bel et bien répondu, mais il a répondu qu’il ne connaissait pas le certificat que tu lui demandes de vérifier (ce qui signifie : « je n’ai pas émis ce certificat »).

Dans ce cas de figure, le réglage soft-fail ou hard-fail n’a aucune importance (il ne fait de différence que lorsque le serveur OCSP ne répond pas). Même en mode soft-fail, le navigateur ne peut pas ne pas tenir compte d’une réponse négative du serveur OCSP (sinon à quoi bon demander en premier lieu ?).

Le problème semble purement du côté de Startcom, dont les serveurs OCSP tardent à être informés de l’émission de nouveaux certificats.

Oui, mais lequel ?

Dans le lien que j'ai donné, ils parlent par exemple d'une certification FIPS-197 pour Intel 520. Est-ce que cela ne serait pas un début de preuve du sérieux ? (je pose la question car je n'y connais rien)

Non. « Intel 520 is compliant with FIPS-197 », ça veut juste dire que ce modèle utilise l’algorithme AES. C’est un bon début (c’est beaucoup mieux que d’utiliser un algorithme maison sorti du chapeau — AES a la confiance unanime des cryptographes), mais ça ne dit rien de la qualité de l’implémentation.

Un produit peut tout-à-fait utiliser les meilleurs algorithmes (et être « certifié » pour ça) et quand même ne rien valoir du tout.

Si on me dit que toutes les certifications/audits c'est du bidon

C’est surtout que les certifications dont on parle ici ne disent pas ce que les commerciaux qui vendent ce genre de produits voudraient faire croire. Un produit « certifié FIPS-197 » n’est pas nécessairement un produit de qualité, c’est un produit qui utilise un algorithme de qualité, ce qui est très différent — et surtout, ce n’est pas suffisant pour justifier les promesses de sécurité que ces commerciaux font miroiter à leurs clients.