gouttegd a écrit 1805 commentaires

cela fait un peu FUD (comme les arguments des logiciels propriétaires contre les logiciels libres à une époque pas si lointaine).

Pas d’accord. Ce serait du FUD si on n’avait rien pour l’étayer, mais en l’espèce, les fournisseurs de solutions de sécurité closed-source ont largement démontré qu’ils n’hésitaient pas à refiler de la poudre de perlimpinpin.

Il y a peut-être des fournisseurs vertueux, mais c’est à eux de montrer que leurs solutions valent réellement quelque chose, il ne peut pas y avoir de présomption de qualité quand il s’agit de sécurité. Et qu’ils ne viennent pas dire qu’ils ne le font pas pour ne pas compromettre la sécurité de leurs produits : si leur sécurité dépend du fait que personne ne sait comment ils fonctionnent, c’est qu’ils ne fournissent aucune sécurité digne de ce nom (comme RSA et ses tokens SecurID, qu’il faut remplacer après un vol d’information chez RSA).

On sait au moins depuis Kerckhoffs, soit bien avant qu’on invente les logiciels libres, que la sécurité par l’obscurité ne fonctionne pas.

Par contre l'implémentation n'est pas toujours bien réalisée

Tout le problème est là : avec ce genre de matériel, tu ne peux pas savoir si on n’est pas en train de te refourguer un truc complètement bidon. Comme lorsqu’on te vend 130 € une clef USB prétendument « sécurisée » et « approuvée par les services de renseignements français »… dont la sécurité ne vaut pas un clou.

Pourquoi se casser la tête à créer des solutions réellement sécurisées, alors qu’il suffit de faire croire aux acheteurs qu’elles le sont ?

j'ai ajouté une règle SPF (une norme Petitmou tiens)

SPF (RFC 7208) n’est pas une « norme Petitmou », au contraire Petitmou avait une proposition concurrente, Sender ID (RFC 4406), qui pour semer la confusion utilisait un enregistrement TXT commençant par spf2.0.

Sender ID n’a pas connu de déploiement massif et est maintenant largement abandonné en faveur de SPF (RFC 6688).

Aux US, lors d'une perquisition, le juge peut indiquer que seul les éléments en liens avec l'affaire peuvent être pris en compte.
En france non. Ca veut dire que si tu donnes tes clés, et que tu as, disons 1 MP3 dont il est soupconné que tu n'ai pas les droits dessus, tu risques quand même 3 ans de prisons.

Ça ne correspond pas vraiment à ce que raconte Zythom. « La mission, rien que la mission » est quelque chose qui revient souvent dans ses anecdotes d’expert judiciaire.

Il semble que le juge puisse poser des questions assez précises (« y a-t-il des images pédopornographiques sur cet ordinateur ? ») lorsqu’il confie sa mission à l’expert, auquel cas l’expert n’a pas à rapporter quoi que ce soit qui ne soit pas lié à la question.

La question est : le volume caché est-il vraiment indétectable ?

D’après certains qui se sont penchés sur cette question, c’est pas gagné. Le comportement normal tant du système d’exploitation que des programmes qui tournent dessus peut laisser des traces qui, a minima, font fortement douter de la présence d’un volume caché.

Cette étude concernait une version ancienne de TrueCrypt et les auteurs notent que la version suivante a corrigé certains problèmes. Mais cela illustre néanmoins toujours que le déni plausible est loin d’être évident. « We encourage the users not to blindly trust the deniability of such systems. »

Le déni plausible, franchement j’y crois moyen…

C’est peut-être efficace si on veut juste se protéger contre les forces de l’ordre dans un état de droit. Mais si votre opposant n’hésite pas à recourir à la rubber-hose cryptanalysis (cryptanalyse à la clef à molette, en français), le déni plausible non seulement ne servira probablement pas à grand’chose, mais en plus met en danger même ceux qui ne l’utilisent pas, en faisant planer sur eux une suspicion qu’ils n’ont aucune possibilité de réfuter.

Purée, et moi qui pensais que ces histoires de user-agent à la noix étaient derrière nous…

Par contre cette histoire de ne "rien" répondre est la plus importantes ….

Peut-être pas tant que ça.

Il ne me paraît pas normal que les machines « tombent » simplement parce que ton serveur leur envoie une réponse négative.

A priori, ce qui se passe est que ces machines se souviennent de l’ancienne adresse IP que leur avait attribué le serveur légitime, et envoient donc directement un message DHCPREQUEST pour demander que l’on leur ré-attribue cette adresse. Ton serveur refuse (DHCPNAK), ce qui est normal (l’adresse demandée n’est pas dans la plage d’adresse qu’il est configuré pour distribuer). Mais à ce moment-là, au lieu de « tomber », les clients devraient se rabattre automatiquement sur un cycle DHCP « complet » (DHCPDISCOVERY → DHCPOFFER → DHCPREQUEST → DHCPACK), qui devrait leur permettre de recevoir une bonne configuration de la part du serveur DHCP légitime.

Si malgré tout les machines « tombent », je dirais qu’il se passe le scénario suivant :

① Le client envoie un DHCPREQUEST avec l’ancienne IP (correcte).

② Ton serveur répond DHCKNAK.

③ Le client envoie un DHCPDISCOVER.

④ Ton serveur répond un DHCPOFFER avec une adresse IP incorrecte (valable sur ton réseau local, mais pas sur le réseau entreprise).

⑤ Le serveur DHCP légitime du réseau entreprise envoie DHCPACK (en réponse au DHCPREQUEST du ①), mais il est trop tard.¹

⑥ Le client envoie un DHCPREQUEST avec l’adresse IP reçue en ④.

⑦ Ton serveur renvoie DHCPACK ; le client se retrouve configurée avec une IP incorrecte, donnant l’impression qu’il est « tombé » du point de vue du réseau entreprise.

⑧ Le serveur DHCP légitime envoie un DHCPOFFER en réponse au DHCPDISCOVER du ③, mais encore une fois, trop tard.¹

En supposant que c’est bien ce qui se passe, il n’est pas particulièrement gênant que ton serveur réponde DHCKNAK en ②. Tout au plus, cela oblige le client à renvoyer un DHCPDISCOVER dont il pourrait autrement se passer. Le vrai problème, c’est que ton serveur ne devrait pas envoyer de DHCPOFFER en ④. Et pour ça, configurer ton serveur comme dans l’exemple que tu donnes (pour ne répondre positivement qu’à des machines précises) devrait être suffisant.

---

¹ L’ordre exact d’arrivée des messages du serveur DHCP légitime peut être un peu différent, mais ce qui est sûr c’est qu’ils arrivent après la bataille.

Aucune des deux ne fonctionne

Normal, ce que tu cherches à faire n’est pas supporté.

La page de manual iptables-extensions(8) dit clairement :

--mac-source address
Match source MAC address. It must be of the form XX:XX:XX:XX:XX:XX.

Rien ne permet de laisser supposer que l’utilisation de « wildcard » est possible.

Et un coup d’œil au code du module xt-mac achève de lever le doute, ce module ne travaille qu’avec des adresses complètes et pas avec des plages d’adresses :

static bool mac_mt(const struct sk_buff *skb, struct xt_action_param *par)
{
        const struct xt_mac_info *info = par->matchinfo;
        bool ret;

        if (skb->dev == NULL || skb->dev->type != ARPHRD_ETHER)
                return false;
        if (skb_mac_header(skb) < skb->head)
                return false;
        if (skb_mac_header(skb) + ETH_HLEN > skb->data)
                return false;
        ret  = ether_addr_equal(eth_hdr(skb)->h_source, info->srcaddr);
        ret ^= info->invert;
        return ret;
}

Alors, je sais que je viens de dire que je préférais expliquer les choses aux utilisateurs, mais là pour le coup, ça me semble relever du détail que Monsieur Michu n’a pas absolument besoin de connaître (même si je me ferais un plaisir de lui expliquer s’il me le demande). L’utilisateur moyen ne manipule jamais les clefs de session (et même parmi les « utilisateurs avancés » il ne doit pas y en avoir beaucoup qui ont déjà utilisé --show-session-key et --override-session-key), il peut ignorer jusqu’à leur existence, ce n’est pas ça qui va l’empêcher de se servir correctement de GnuPG.

Il y ad’autres notions plus importantes à appréhender avant d’en arriver là à mon avis (au hasard, la distinction entre trust et ownertrust, qui d’expérience pose beaucoup de problèmes de compréhension aux débutants).

Les recommandations liées à IPv6 précisent que les 64 premiers bits sont utilisées pour addresser le réseau et les 64 derniers bits sont là pour adresser les hosts.

En fait, ça a l’air plus compliqué que ça. De ce que je comprends, c’était supposé être plus souple, mais l’usage a sanctifié l’idée d’utiliser 64 bits pour identifier la machine et maintenant l’IETF entérine l’usage.

Pour moi, l'apprentissage de l'outil est un effort déjà suffisant de la part de "l'ignorant" (dont je fais partie) pour avoir accès à la jouissance de la connaissance si l'outil est disponible.

Pas toujours (mais ça dépend probablement beaucoup du domaine, et de ce que fait l’outil).

Un problème à ne connaître que l’outil sans avoir aucune idée des concepts sous-jacents, c’est que lorsque l’outil te demande de faire un choix, tu ne peux pas répondre correctement (tu ne comprends même pas la question !) et tu es obligé de demander à Bibi.¹ Donc tu n’es pas autonome, et tu n’es pas libre.

Quand ça arrive, Bibi préfère expliquer les tenants et aboutissants de la question (brièvement, il ne s’agit pas de faire un cours non plus) et suggérer la bonne réponse, plutôt que de dire sèchement « réponds-lui ça ».

Et j’ai constaté que mes interlocuteurs avaient plutôt tendance à apprécier que je prenne le temps de leur expliquer, au lieu de faire comme si je pensais qu’ils sont trop cons pour comprendre. (Ou alors, ils sont trop polis pour m’avouer que je leur casse les bonbons avec mes explications, c’est possible aussi. :-° )

---

¹ Parfois, ce problème serait évitable. Les logiciels posent probablement trop de question alors qu’un comportement par défaut (débrayable pour les utilisateurs avancés) conviendrait probablement à la plupart des gens (GnuPG progresse dans ce sens, avec par exemple la nouvelle option --quick-gen-key introduite dans GnuPG 2.1, qui génère une nouvelle paire de clef sans rien demander à l’utilisateur). Mais tu auras toujours des cas où le logiciel aura besoin d’une intervention éclairée de l’utilisateur.

n'ai je pas le droit d'être libre ?

Bien sûr que si. Mais le fait d’avoir ce droit n’implique pas nécessairement que tu n’as pas d’effort à faire pour en jouir.

« Avoir le droit » et « avoir la capacité » sont deux choses complètement indépendantes.

je suis convaincu que les savants doivent éduquer les ignorants

À conditions que les « ignorants » (je ne fais que reprendre ce terme, je ne cautionne pas son usage dans ce contexte — pas plus que l’usage de « savants » d’ailleurs) le veuillent. Or en l’espèce, et à l’exception des quelques personnes que j’ai croisées lors de crypto-parties, la plupart des gens ne veulent pas avoir à apprendre quelque chose. Au maximum, ils veulent bien avoir à installer un logiciel (comme on installe un anti-virus) et c’est tout.

Malheureusement, il ne suffit pas d’installer un programme de crypto (GnuPG ou un autre) pour être magiquement en sécurité. Ce serait cool si c’était aussi simple, mais ça ne l’est pas. Et faire croire le contraire aux gens ne serait pas leur rendre service à mon avis. (Ça n’interdit pas évidemment d’améliorer les outils existants pour les rendre plus abordables, mais on ne pourra jamais les rendre complètement transparents.)

En attendant, je suis complètement disposé à aider quiconque veut se mettre à protéger ses communications.¹ Mais ① il faut le vouloir (je ne vais pas aller chercher ceux qui disent « m’en fous, j’ai rien à cacher ») et ② il faut y mettre du sien (je ne vais pas tenir la main à ceux qui disent « ouh là, c’est trop compliqué ton truc » au bout de trois secondes d’explication).

(Le dernier paragraphe est d’ailleurs applicable à toutes les choses pour lesquelles je suis prêt à aider les gens, pas seulement aux chiffrements des emails.)

---

¹ J’ai d’ailleurs dans les cartons le projet d’écrire une série de journaux autour de l’utilisation de GnuPG et OpenPGP, dans la foulée de ma dépêche sur la carte OpenPGP. (Voilà, maintenant que c’est annoncé, je ne vais plus pouvoir me défiler.)

C'est pour ça que je disais "presque tout". Je pensais au lib de sécurité principalement.

Il n’y a pas que dans les bibliothèques dédiées à la « sécurité » qu’il y a des failles de sécurité… Il y a même pas mal de failles qui viennent de bugs dans des bibliothèques qui n’ont rien à voir avec la sécurité (ne serait-ce que toutes les bibliothèques qui lisent des formats de fichiers, genre libpng et assimilées).

S/MIME est effectivement pris en charge nativement par davantage de clients qu’OpenPGP (du moins sur le desktop — pas sûr que beaucoup de clients mobiles prennent en charge l’un ou l’autre), mais :

– à l’usage, les interfaces utilisateurs pour S/MIME ne sont pas plus intuitives que celles pour OpenPGP ; leur seul avantage est qu’il n’y a pas de greffon à installer, mais je ne pense pas que ce soit l’installation de Enigmail qui pose le plus de difficultés aux gens ;

– ce n’est pas plus adapté qu’OpenPGP à l’utilisation dans un webmail ;

– surtout, ça ne change rien au problème majeur d’utilisabilité que représente la distribution des clefs.

Mettons qu’Alice vient de générer un certificat (OpenPGP ou X.509, peu importe, le problème est le même ; peu importe aussi qu’elle ait fait ça consciemment ou que son client de messagerie s’en soit chargé sans intervention de sa part). Comment le diffuse-t-elle auprès de ses contacts ? Et quand elle veut écrire à Bob, comment peut-elle obtenir automatiquement le certificat de Bob ?

Les serveurs de clefs sont une réponse possible, mais pas nécessairement la meilleure, surtout si l’on veut que tout soit automatisé : il peut y avoir douze mille clefs au nom de Bob bob@example.com sur les serveurs de clef, une intervention de l’utilisateur sera forcément nécessaire pour savoir laquelle choisir.

S/MIME est surtout utilisé dans un environnement restreint et contrôlé (dans une grande entreprise par exemple), où ces questions peuvent être résolues par une politique appropriée. Par exemple, lorsqu’on crée le compte du nouvel employé Bob, on génére automatiquement un certificat signé par la CA interne à l’entreprise. Le client mail d’Alice a été configuré par les administrateurs (avec interdiction pour Alice d’en utiliser un autre, d’ailleurs elle n’a pas les droits root sur sa machine) pour, d’une part, aller chercher automatiquement le certificat de Bob sur l’annuaire LDAP de la boîte, et d’autre part, faire confiance à la CA interne.

C’est cool, ça marche tout seul (enfin, du point de vue d’Alice et Bob, parce qu’en réalité, ça ne marche que parce qu’il y a un service IT derrière pour faire tout le boulot), mais ce n’est pas transposable au grand public.

Bon, je ne suis pas particulièrement fan de l’approche qui consiste à tout masquer à l’utilisateur en lui disant « clique sur ce gros bouton et tu seras secure, fais-moi confiance ».

Mais si tu veux te pencher sur la question « comment rendre OpenPGP plus abordable », quelle que soit la méthode je t’invite à ne surtout pas faire ça seul dans ton coin.

Un bon endroit pour en discuter sont les listes de discussion du projet GnuPG. D’une part, c’est probablement l’implémentation la plus répandue d’OpenPGP, et d’autre part, la question y est déjà régulièrement abordée.

Et non, contrairement à ce qu’on peut lire parfois, les développeurs de GnuPG (et des programmes qui tournent autour comme Enigmail) ne sont pas enfermés dans une tour d’ivoire d’où ils ignorent les critiques concernant l’utilisabilité de leurs logiciels. S’ils n’ont pas forcément de solutions miracles (c’est un sujet difficile, surtout quand on veut apporter de vraies réponses et pas de la poudre aux yeux), ils y réfléchissent quand même. (Oui, je sais, il n’y a rien de nouveau sur cette page depuis 2012. Mais il y a toujours du travail de fait sur le code du côté de GnuPG.)

J’ai l’impression que tu mélanges un peu tout, là.

Alors que pirater une CA. Miam. Du web partout, des centaines de boîtes mails directement accessibles, glop glop.

Le simple fait de pirater une CA ne te donne pas automatiquement accès aux communications de tous les sites web et tous les serveurs SMTP qui ont fait signer leurs certificats chez cette CA. Tu n’as pas accès aux clefs privées des certificats des clients.

Pirater une CA te met en position de pouvoir faire du MITM sans être détecté par les clients qui vérifient l’origine des certificats.

Du coup, oui, en théorie les CA apportent une sécurité supplémentaire, puisqu’il faut non seulement être en position de monter une attaque MITM et avoir obtenu un certificat de la part d’une CA (soit en la piratant, soit en demandant gentiment à des CA comme Trustwave). En pratique, la barrière ajoutée ne constitue pas un gros obstacle pour quiconque a déjà les moyens de faire du MITM — je pense même qu’obtenir le certificat illégitime est la partie facile.

Bon, c'est quand même bien pour ça qu'on recommande d'activer la PFS partout.

La PFS ne protège pas contre un homme du milieu qui a un certificat auquel le client fait confiance. Le client parle directement à l’homme du milieu, et c’est avec lui (et non avec le vrai serveur à qui il croit parler) qu’il procède à l’échange de clef initial.

La PFS protège contre la compromission de la clef privée du serveur TLS, qui n’est pas menacée par les agissements ou les vulnérabilités des CA.

Si, parce que les CA sont des organisations de confiance. Ça change tout.

Elles n’émettraient jamais de certificats illégitimes, encore moins de certificats permettant de faire du MITM. Et de toute façon si une CA faisait une chose pareille, les éditeurs de navigateurs n’hésiteraient pas une seconde à lui retirer leur confiance.

Aucun risque non plus qu’une CA se fasse pirater.

En plus, il y a plusieurs dizaines de CA et plusieurs centaines (voire milliers) de sous-CA là-dehors. Si c’est pas rassurant de savoir que tout ce monde veille à la sécurité de nos communications…

En même temps, si tu rejettes le client dès la connection, tu n’as aucune certitude qu’il allait te donner du spam. Tout ce que tu as, c’est la présence de son adresse dans une blacklist.

C’est précisément cette approche à la tronçonneuse que je condamne. Et autant je pourrais à la limite la comprendre de la part d’un gros fournisseur de messagerie qui doit faire face à des millions de connexion et n’a pas de temps à perdre avec des dommages collatéraux (même si ce n’est pas une excuse ; si on tient absolument à utiliser une blacklist, la bonne procédure consiste à combiner ses résultats avec d’autres indicateurs de spamicité), autant je la trouve inadmissible venant de ceux qui se font les champions de l’auto-hébergement.

Le chiffrement est possible avec TLS, c'est juste que personne ne l'utilise.

C’est de plus en plus utilisé, au contraire. Par exemple, Google observe qu’à mi-2014, 58% des échanges SMTP entre ses serveurs et le reste du monde étaient chiffrés.

Ça devient d’ailleurs tellement utilisé qu’on cherche de plus en plus à casser ou contourner ça.

Je pense que c’est une démonstration que Systemd encourage le laxisme, et que c’était mieux avant : maintenant, même les trolls ne font plus d’efforts.

J’en vois ici qui tirent sur le FAI, mais ce n’est pas lui le principal problème à mon avis.

Le principal problème, ce sont les administrateurs de serveurs mail qui prennent les blacklists comme une solution de facilité « clef-en-main » contre le spam, sans même y réfléchir une seconde.

Un exemple : je prends un tuto au hasard (un des premiers résultats sur une recherche Google « linux mail server »), et voilà ce que contient la section sur la configuration de Postfix :

Now we can specify some restrictions. Be carefull that each setting is on one line only.

...
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org,
      reject_rbl_client blackholes.easynet.nl
...

Hop, on envoie paître les clients listés dans l’une ou l’autre des deux DNSBL mentionnés. Peu importe que toutes les autres vérifications montrent que le client est correct, si son IP est blacklisté, il va se faire voir, point. Non mais. C’est pas comme si le but de ce tuto était d’encourager les gens à monter leur propre serveur mail.

(Encore plus grave, de mon point de vue : à aucun moment l’auteur de ce document n’explique ce que fait la configuration qu’il propose.)

Ou mieux, n'as tu pas 5€/mois à dépenser pour louer un dédié ou un dédié virtuel et y installer un postfix qui ferait relais

J’approuve, mais il faut quand même noter que même ça ne te garantit pas de ne pas te retrouver dans une blacklist.

Mon serveur n’a jamais envoyé le moindre spam, il respecte complètement le protocole SMTP, l’enregistrement DNS inverse correspond bien au nom annoncé de la machine, son adresse correspond à la seule adresse mentionnée dans l’enregistrement SPF de mon domaine, les mails sortants sont signés par DKIM, j’accepte les rapports DMARC, mon serveur peut faire du TLS opportuniste (et les autres serveurs peuvent vérifier la validité du certificat par DANE)… Bref, je crois sincèrement avoir un serveur bien géré (et je ne peux pas en dire autant de tous les fournisseurs de messagerie).

Ça n’a pas empêché, d’une part, une certaine DNSBL de blacklister tout le réseau dans lequel mon serveur se trouve, et d’autre part, au moins un fournisseur de messagerie de rejeter inconditionnellement tous les messages en provenance de mon serveur sur la seule base de la présence dans une blacklist apparemment connue pour blacklister des /24 entiers.

C’est surtout le deuxième point qui m’énerve. Je veux bien que la présence d’une adresse dans une DNSBL soit un critère de spam, mais pas que ce soit le seul. Ça sent vraiment l’administrateur flemmard qui pense qu’il a fait son boulot de lutte contre le spam parce qu’il a mis une ligne reject_rbl_client dans son fichier de configuration…

tandis que le blocage du port 53 se ferait à cause d'une décision du gouvernement

Je pensais plutôt à un blocage à l’intiative du FAI pour des raisons mercantiles : si le FAI a mis en place un résolveur menteur qui renvoie vers une page de pub quand le client demande un nom inexistant (comme SFR l’a fait à une époque, même si ça n’a plus l’air d’être le cas maintenant), ce serait dommage que le client puisse librement aller voir ailleurs.

Est-ce qu'obligation s'applique aux DNS google ou bien à OpenDNS ?

L’obligation de censure s’applique aux « personnes mentionnées au 1 du I de l’article 6 de la loi 2004-575 du 21 juin 2004 », c’est-à-dire « les personnes dont l’activité est d’offrir un accès à des services de communication au public en ligne. »

Et puis rien n'interdit de monter son propre DNS qui interroge les serveurs racines…

Tant que le port 53 n’est pas bloqué en sortie, ce que les FAI pourraient très bien décider de faire sans attendre que la loi ne leur demande (aucune loi ne demande le blocage du port 25, ça n’empêche pas certains FAI de le faire).