gouttegd a écrit 1805 commentaires

Comment être reconnu en non spam chez hotmail ?

Problème récurrent bien connu de tous les postmasters, hélas (Hotmail n’est pas le seul à poser problème, mais c’est clairement le pire).

Quelques pistes :

1) S’inscrire au Smart Network Data Service (SNDS), qui t’indiquera le statut de l’IP de ton serveur aux yeux de Microsoft.

Problème : Ça donne l’impression de faire quelque chose mais en fait ça ne sert à rien. SDNS peut sans aucune honte t’afficher qu’aucune de tes adresses n’a de problème alors même qu’aucun de tes messages n’arrive à destination.

2) Devenir un spammeur (pardon, je voulais dire un legitimate email marketer). Non, sérieusement. Si ton serveur n’envoie pas assez de messages, il passe sous les radars des systèmes de mesure de réputation dans le genre de SenderScore. Du coup, ton IP n’a pas de réputation, ce qui pour Microsoft est équivalent à ne pas avoir de bonne réputation et donc équivalent à avoir mauvaise réputation.

Donc, il faut envoyer beaucoup de messages (genre, plusieurs milliers par mois, minimum) pour avoir une chance de prouver que tu n’es pas un spammeur. Faut pas chercher à comprendre, c’est de la logique Microsoft.

3) Payer. L’argent agit comme de l’huile de moteur qui vient graisser les rouages des systèmes de mesure de réputation et facilite le transit des messages.

Concrètement, tu achètes les « services » d’une boîte comme Validity (qui est aussi derrière SenderScore, oh ben ça alors quelle coïncidence), qui du coup ira dire à Microsoft « c’est bon, celui-là il a casqué, tu peux laisser passer ses messages. »

Là tu parles d’un « CV académique », qui est effectivement très différent d’un CV « tout court ».

Le CV académique est en effet supposé être le plus complet possible, sans aucune limite sur le nombre de pages (j’en ai vu de 8 pages).

À ma connaissance, ce type de CV n’est demandé/attendu que dans le secteur académique, d’où son nom.

Je ne sais pas si c’est une pratique courante en France, mais ici au Royaume-Uni, on recommande aux chercheurs d’emploi d’éviter les CV un peu trop « graphique », avec des éléments visuels, des cadres latéraux, ce genre de choses.

La raison serait que la plupart des entreprises, au moins à partir d’une certaine taille, ont recours au traitement automatique des CV par un logiciel, qui compare la description du poste avec le CV du candidat ; seuls les CV qui, d’après le logiciel, semblent correspondre au profil recherché peuvent passer à l’étape suivante où ils seront lus par un recruteur humain.

Du coup, il vaut mieux que le CV soit aisément « parsable » par une machine, quitte à être moins « flashy » visuellement, sous peine de le voir rejeté avant même qu’il arrive sur le bureau d’un DRH.

Hébergement sur un VPS perso, pour ma part.

Puisqu’on est dans le HS, une petite histoire pour raconter comment j’en suis arrivé à gérer mon propre serveur mail (c’était pas du tout le but au départ) :

Tout a commencé il y a environ douze ou treize ans, à une époque où je n’arrivais pas à décider d’un client mail à utiliser. J’hésitais constamment entre Thunderbird, KMail, Claws-Mail, et peut-être un ou deux autres. Au bout d’un moment, ça a fini par me déranger d’avoir mes comptes mails (j’en avais trois à l’époque : un personnel chez Hotmail, un personnel associé à mon domaine chez OVH, et un estudiantin fourni par l’université) configurés dans plusieurs clients : changer le mot de passe d’un compte, par exemple, nécessitait de répercuter le changement dans tous les clients, ce que je trouvais pénible et non-optimal.

Du coup, j’ai entrepris de séparer les étapes de réception, d’envoi, et de consultation des mails, en utilisant d’un côté fetchmail pour récupérer les mails de mes différents comptes et de l’autre msmtp pour envoyer un mail via les serveurs d’envoi de mes différents comptes. Du coup, la configuration de mes comptes n’était plus dupliquée entre mes différents clients : chaque compte de réception était configuré une seule fois dans le fichier de config de fetchmail, chaque serveur d’envoi était configuré une seule fois dans le fichier de config de msmtp. Mes différents clients sus-cités (Thunderbird/KMail/Claws-Mail/etc), eux, n’étaient plus configurés que pour aller chercher les mails là où fetchmail les déposait et pour invoquer msmtp pour envoyer un message.

Ça marchait et j’étais content de moi, jusqu’à ce que je réalise qu’en fait ça ne marchait pas si bien que ça… Le problème était que la plupart des clients semblaient assumer qu’ils étaient les seuls à utiliser les dossiers Maildir où fetchmail stockait les messages, et n’appréciaient que très moyennement d’y découvrir des fichiers laissés par un autre client (je crois que KMail en particulier était très susceptible).

Du coup, je me suis dit qu’au lieu de laisser chaque client aller chercher directement les mails là où fetchmail les déposait, pourquoi ne pas intercaler un serveur IMAP au milieu ? Dovecot serait donc le seul à accéder au dossier des e-mails sur le disque dur, et les clients seraient configurés pour obtenir les e-mails en parlant à Dovecot en local (ça ne faisait toujours qu’un seul compte IMAP à configurer sur chaque client, au lieu d’un compte IMAP ou POP3 par fournisseur, donc ça allait).

Plus tard, je me suis dit que tant qu’à faire à avoir un serveur IMAP, pourquoi le faire tourner sur mon PC portable qui n’est allumé que par intermittence ? Il tournerait tout aussi bien sur la vieille bécane de récupération que j’ai dans le cagibi et qui me sert de serveur de stockage, et qui est allumé en permanence… J’ai donc déplacé fetchmail et Dovecot sur la bécane en question, et simplement changé la configuration de mes clients pour aller parler au serveur IMAP sur le réseau local et non plus sur localhost.

Plus tard, je me suis dit que tant qu’à faire à avoir un serveur IMAP sur une autre machine, pourquoi l’avoir sur une machine connectée à Internet à travers une connexion brinquebalante (pour rester poli) ? Pourquoi ne pas le mettre plutôt sur ce petit VPS qui jusqu’à présent ne fait tourner qu’un pauvre serveur Web ? Et ce fut fait.

Plus tard, je me suis dit que c’était quand même dommage que les mails envoyés à mon adresse perso chez OVH soit d’abord reçus par les serveurs mails d’OVH, puis récupérés par fetchmail sur mon VPS, puis servis via IMAP à mes clients sur ma machine… Pourquoi ne pas retirer les serveurs mail d’OVH du circuit, et faire en sorte que les messages destinés à mon domaine soient reçus directement par mon VPS ? Ce n’est jamais qu’un Postfix à configurer après tout (et un enregistrement MX à mettre à jour, mais c’est une autre histoire¹)…

Et voilà comment, de fil en aiguille, parce qu’au départ j’avais la flemme de configurer plusieurs clients de messagerie, et parce que personne n’était là pour me dire « arrête tes conneries, tu vas devenir sysadmin si ça continue », je me suis retrouvé à gérer mon propre serveur mail…

---

¹ Un jour, je me suis dit que devoir passer par l’interface Web d’OVH pour ajouter, supprimer, ou modifier un enregistrement DNS pour mon domaine était quand même assez pénible, alors pourquoi ne pas gérer ça moi-même ? Ce n’est jamais qu’un Bind à configurer après tout…

(Oui, je n’ai pas de vie sociale, comment vous avez deviné ?)

installer les guest tools virtio

Done.

avoir des disques ssd

C’est le cas.

si possible ne pas partager le disque de l'hyperviseur mais dédier un ssd à la vm

Oui, alors Windows est bien gentil, mais j’ai cinq ou six autres machines virtuelles sous Debian ou Slackware qui se contentent très bien d’un disque virtuel sous la forme d’une image qcow sur le disque dur de l’hôte, je ne vais pas réserver un SSD entier juste parce Môssieur Windows a ses exigences…

J’alloue 6 GiB à la machine virtuelle. Je n’ai pas essayé le CPU pinning, faudra que je voie si ça fait une grosse différence.

• CPU: Quad Core Intel Core i5-10210U
• GPU: Intel UHD Graphics 620 (apparemment aussi connu sous le nom « Generation 9.5 GT2 Kaby-Lake-Refresh », si quelqu’un comprend quelque chose aux noms qu’Intel donne à ses puces — moi j’ai renoncé)
• RAM: 15.34 GiB
• HDD: Seagate ST1000LM048-2E7172 (931 GiB)
• SDD: A-Data SU800NS38 (238 GiB)

Sous Slackware64-current avec noyau Linux-5.4.72 et qemu-5.0.0.

Je pertinente, Windows est tout à fait tolérable en machine virtuelle.

Ce n’est pas du tout mon expérience. J’ai essayé il y a peu Windows 10 sur une machine virtuelle KVM, l’installation s’est déroulée sans problèmes mais à l’usage c’est d’une lenteur telle que c’est tout bonnement inutilisable. Dix-sept minutes pour démarrer et une fois arrivé sur le bureau, au moins une minute avant que le moindre clic de souris ne produise un effet…

J’admets volontiers que ma machine n’est pas nécessairement un foudre de guerre, mais quand même, sous la même configuration je fais tourner une machine virtuelle Debian/GNOME de façon parfaitement fluide. Je veux bien que Windows requière une configuration matérielle plus solide, mais à ce point ?

Après, configurer KVM + Windows aux petits oignons tient de la magie noire

Du coup si tu as des pointeurs sur la question, je suis preneur.

Pour info, j’ai principalement utilisé ça : https://www.funtoo.org/Windows_10_Virtualization_with_KVM

Mon petit doigts me dit que certain pigiste on la vie facile, trouver un bon résumé bien disruptif sur elsevier et tu as un papier sans travailler, avec le mots clé cancer, covid, tu peux trouver ton bonheur \o/

Obligatory xkcd PHD Comics

Merci pour l’info. :) Alors, pour ceux qui comme moi chercheraient, c’est dans Settings > Meeting > In Meeting (Advanced), toooooooout en bas de la longue liste d’options, il y a

Show a "Join from your browser" link
Allow participants to bypass the Zoom application download process, and join a meeting directly from their browser. This is a workaround for participants who are unable to download, install, or run applications. Note that the meeting experience from the browser is limited

« Pas mis en avant », c’est le moins qu’on puisse dire en effet… Et étant donné que

• cette option n’est pas activée par défaut,
• personne parmi mes collègues (surtout ceux chargés de créer les meetings) semble n’avoir connaissance de cette option,
• je ne fais que participer à des meetings sans les créer, donc le fait que je connaisse cette option me fait une belle jambe,

… ben pour moi, non, le client web Zoom n’est pas une solution « vraiment acceptable », puisque c’est bel et bien comme s’il n’existait pas…

Pour Zoom, il me semble que l'utilisation du client web est une solution vraiment acceptable. En tout cas, le client fonctionne avec Firefox.

Pas chez tout le monde, non…

Sur mon Firefox, Zoom n’essaie même pas de faire quoique ce soit dans le navigateur lui-même, la seule option est de lancer le client desktop (qui doit donc préalablement avoir été installé). Je suis même surpris d’entendre parler d’un « client Web », qui de ce que je vois de chez moi ne semble même pas exister du tout…

Ouh, je me suis mélangé les pinceaux à deux reprises entre TLS implicite et explicite, sorry about that …

s/À l’inverse, en TLS explicite, je ne connais aucun client/À l’inverse, en TLS implicite, je ne connais aucun client/
s/Et pourtant en TLS implicite, ça arrive/et pourtant en TLS explicite, ça arrive/

C'est pour ca que j'ai appuyé sur le fait que le client doit être aussi correctement configuré […] Donc non, pas possible de forcer le downgrade (ou alors il y a un bug dans le client

Donc tu te reposes sur le fait que tous tes clients sont 1) correctement configués et 2) non-buggés. C’est assez osé à mon sens comme pré-requis.

En TLS explicite, continuer la communication en clair si aucune des parties ne voit l’option STARTTLS est un comportement assez courant (et pour cause, c’est le comportement par défaut : la communication est d’abord en clair, et seulement éventuellement bascule en chiffré), je ne ferais pas confiance aux clients pour ne pas adopter ce comportement. À l’inverse, en TLS explicite, je ne connais aucun client qui bascule silencieusement vers le port non-chiffré si la connexion au port chiffré échoue.

Si j'ai coché "starttls" dans la config de mon client, qu'on appelle ça explicite ou implicite*, il n'est pas sensé basculer en plain-text.

Et pourtant en TLS implicite, ça arrive. « Mauvais client, changer de client », peut-être, mais en attendant, si j’ai un moyen en tant qu’administrateur de forcer le chiffrement sans compter sur le bon vouloir ou le bon comportement du client, je le fais.

Que penses-tu de mon argument de ne pas avoir de certitude quant à la suite du chemin ? N'as tu pas peur de te reposer sur un faux-sentiment de sécurité ?

L’argument du « je ne contrôle pas ce qui se passe en dehors de chez moi alors ça sert à rien que je me casse le cul à faire attention chez moi » ? Euh, pas grand’chose de bien, pourquoi ?

Ceci est absurde comme argument, le starttls stripping n'apporte rien si l'attaquant est déjà en position d'impersonniser le serveur.

D’une, je pense que retirer une simple option lors de l’établissement de la connexion SMTP, c’est quand même plus simple que « d’impersonniser un serveur ». Justement le STARTTLS stripping dispense l’attaquant de devoir monter un vrai MITM. Rendre le STARTLS stripping impossible complique la tâche de l’attaquant qui n’a dès lors plus le choix, il doit faire un vrai MITM.

De deux, très fréquemment le STARTTLS stripping est le fait d’un opérateur réseau pour qui ce genre de manipulation sur les paquets qu’il achemine est extrêmement facile. De nombreux fournisseurs d’accès sont connus pour ce genre de pratiques appliquées à grande échelle contre tous leurs abonnés. Pourquoi leur faciliter la tâche ?

Que je sache, il n'y a aucune différence entre TLS et STARTLS en ce qui concerne la possibilité d'un MITM

Si par « TLS » et « STARTTLS » tu parles de TLS implicite et explicite comme décrit plus haut :

Sans vérification du certificat, aussi bien le TLS implicite que le TLS explicite sont vulnérables à une « vraie » attaque MITM (où l’attaquant se fait passer pour la partie d’en face), mais seul le TLS explicite est vulnérable au STARTTLS stripping.

En TLS explicite, l’attaquant peut forcer les deux parties à communiquer en clair simplement en retirant l’option STARTTLS (TLS stripping), sans même avoir à jouer le rôle d’un véritable « homme du milieu » (donc sans jamais avoir besoin d’un faux certificat). C’est impossible en TLS implicite.

Certes, même en TLS explicite tu peux configurer le client et/ou le serveur pour rendre TLS obligatoire (i.e. refuser de continuer la communication si l’option STARTTLS est absente), mais dans ce cas l’attaque par TLS stripping se transforme en déni de service (en retirant l’option, l’attaquant force les deux parties à abandonner la communication).

il me semble absurde d'exiger que la communication entre ton MTA et le next-hop soit chiffrée sans avoir aucune garantie sur la suite du parcours

Rappel : OpenPGP ne protège que le corps du message, pas toutes les métadonnées associées. Il est toujours absolument pertinent de chercher autant que possible à utiliser SMTP sur TLS (chiffrement point à point des métadonnées) même si le corps est déjà chiffré en mode « end-to-end » avec OpenPGP.

Edit: Ah zut, j’ai répondu au mauvais commentaire ><, désolé, c’est une réponse au commentaire grand-parent…

Du coup, quelle serait la limite acceptable pour forcer le chiffrement, 1%, 2% ?

Ça dépend de plusieurs choses. Déjà, s’agit-il d’un serveur perso dont tu es le seul utilisateur, ou fournis-tu un service pour d’autres utilisateurs (à la manière d’un CHATON par exemple) ?

Si tu es le seul utilisateur, es-tu prêt à accepter que 1% de tes mails n’arrivent pas à leurs destinataires parce que les serveurs desdits destinataire n’acceptent pas le chiffrement ? Sachant que dans ce 1% tu pourrais très bien avoir un mail destiné à ton banquier, au propriétaire de ton logement, à l’entreprise à laquelle tu envoies un CV, etc…

Si tu as d’autres utilisateurs en plus de toi-même, es-tu prêt à répondre aux utilisateurs qui se plaignent d’avoir des mails qui n’arrivent pas que c’est normal, tu as consciemment fait le choix de rendre le chiffrement obligatoire et que c’est le problème des autres serveurs qui ne supportent pas le chiffrement ?

Je me demande combien de domaines utilisent l'enregistrement TLSA et DNSSEC…

Au 31 août 2020, 2 151 862 domaines supportent TLSA.

J'ai une dernière question, pourquoi Thunderbird différencie SSL/TLS de STARTTLS dans les options qui me permettent de me connecter à mon serveur (vu que STARTTLS est toujours utilisé) ?

Pour la connexion entre un MUA (comme Thunderbird) et un serveur (par opposition aux connexions de serveur à serveur), il y a toujours deux options :

• une connexion chiffrée dès le départ sur un port dédié (typiquement 465 au lieu de 25 pour SMTP, 993 au lieu de 143 pour IMAP) ;
• une connexion établie initialement en clair sur le port standard, qui bascule en mode chiffré lorsque les deux parties se mettent d’accord pour ça (via une commande interne au protocole, qui dans le cas des protocoles SMTP et IMAP s’appelle STARTTLS).

Formellement, le premier mode est appelé « TLS implicite », parce que l’utilisation de TLS est implicitement requise par le simple fait d’établir une connexion sur le port dédié aux connexions TLS ; le second mode, par opposition, est dit « explicite », parce que l’utilisation de TLS est explicitement négociée une fois la connexion initiale établie.

Mais ces appellations de « TLS implicite » et « TLS explicite » sont assez récentes (à ma connaissance c’est le RFC 8314 qui les a formalisées pour la première fois), pendant longtemps les serveurs et les clients ont utilisé diverses appellations plus ou moins heureuses¹ pour désigner les deux modes.

Dans le cas de Thunderbird, SSL/TLS désigne le mode implicite, STARTTLS désigne le mode explicite.

---

¹ Les moins heureuses de ces appellations étant SSL pour désigner le mode implicite et TLS pour désigner le mode explicite, alors que ça n’a rien à voir…

J'ai cru comprendre que la directive "smtp_tls_security_level = may" (entre autres) permet d'activer un mode chiffrement opportuniste nommé STARTTLS et donc que ce dernier est vulnérable aux attaques en MITM.

Plus précisément, le niveau may implique les deux comportements suivants :

• ton serveur demande au serveur d’en face que la communication soit chiffrée, mais accepte d’envoyer le mail en clair si le serveur d’en face ne propose pas le chiffrement (ou si un attaquant actif supprime l’option STARTTLS en chemin) ;
• même si la communication est chiffrée, ton serveur ne vérifiera pas la validité du certificat d’en face.

Est-il possible de ne pas utiliser STARTTLS avec "smtp_tls_security_level = enforce", par exemple ?

Comment ça, ne pas utiliser STARTTLS ? A priori tu veux forcer l’utilisation de STARTTLS, au contraire…

Pour rendre le chiffrement obligatoire, tu peux en principe (mais voir la question suivante d’abord) utiliser smtp_tls_security_level = encrypt. La différence par rapport au niveau inférieur may est qu’à ce niveau, ton serveur coupera court à la communication si le serveur d’en face n’utilise pas TLS (que ce soit parce qu’il ne supporte pas le chiffrement ou parce qu’un attaquant a supprimé l’option STARTTLS en chemin).

Est-il raisonnable d'interdire la communication avec des serveurs n'utilisant pas le chiffrement, sachant qu'ils sont peu nombreux ?

Peu nombreux, peu nombreux… la dernière fois que j’ai analysé les logs de mon serveur pour voir l’utilisation du chiffrement, il y avait encore environ 15% de serveurs qui n’acceptaient que des communications en clair. Pour moi c’est encore beaucoup trop pour que je sois confortable avec l’idée d’interdire toute connexion en clair.

Faut-il autoriser l'utilisation d'algorithmes cryptographiques obsolètes, pour garantir une compatibilité optimale ?

Il y a quelques années j’aurais dit « oui », en partant du principe qu’une communication chiffrée avec un algorithme obsolète est toujours mieux qu’une communication en clair.

Je n’en suis plus si sûr aujourd’hui. Toujours d’après les logs de mon serveur, il semble que les serveurs mails dans la nature se répartissent désormais en deux grandes catégories :

• ceux qui supportent le chiffrement : ceux-là supportent les dernières versions de TLS (1.2, 1.3) et les algorithmes les plus modernes ;
• ceux qui ne supportent pas du tout le chiffrement.

Concrètement, contrairement à ce qui se passait il y a encore deux ou trois ans, je ne vois plus dans mes logs aucune trace de serveurs « intermédiaires », qui supporteraient le chiffrement mais n’offreraient que des versions dépassées de TLS (SSLv3, TLS 1.0, TLS 1.1) et/ou que des algorithmes « faibles . C’est bien sûr à pondérer avec le fait qu’il ne s’agit que de ce que voit mon serveur (je ne prétends pas que c’est représentatif de tout le paysage des serveurs mails), mais je ne pense pas qu’on perde beaucoup aujourd’hui à refuser de supporter des protocoles et algorithmes dépassés.

Le corollaire de tout ça c'est que pour mesurer la durée d'exécution d'un fragment de code avec

En fait si l’objectif est de mesurer une durée d’exécution (et non pas de collecter de l’entropie), rdtsc n’est pas vraiment approprié, parce que traduire la valeur du compteur en temps n’est pas évident, d’autant plus que la signification exacte du compteur a varié au fil des générations de processeurs.

Pour mesurer une durée d’exécution, clock_gettime(CLOCK_MONOTONIC) est préférable. En plus c’est portable.

Tu l'utilises professionnellement ou simple curiosité

Alors professionnellement, je suis biologiste… Le seul noyau qui m’intéresse professionnellement parlant, c’est le noyau cellulaire. ^^

et tu as epluché LKML ?

Nul besoin d’éplucher la LKML quand LWN nous gratifie régulièrement d’articles très détaillés sur tout ce qui se passe autour du développement du noyau. :)

(Y compris parfois sur des patchs qui au final ne sont pas intégrés, mais qui font quand même avancer le développement par les réflexions qu’ils suscitent.)

Dans le cas particulier du pilote random, il a fait l’objet d’analyses détaillées par des cryptographes, comme Lacharme et al. (2012) (cité dans le journal) ou avant ça Gutterman et al. (2006). Ce sont des lectures intéressantes, surtout en ce qu’elles donnent plus facilement une vision d’ensemble du RNG (les articles de LWN ont tendance à plus rapidement aller dans les détails d’implémentation, au détriment d’une vue plus générale).

Et bien sûr, le code source lui-même est indispensable pour disperser toute incompréhension ou ambiguité (par contre, il faut bien se reporter au code uniquement et pas tellement à la documentation associée — y compris les commentaires dans le code —, parce que celle-ci n’est malheureusement pas toujours à jour et ne reflète pas forcément ce que fait le code…).

Tiens, je viens de remarquer que le compteur renvoie toujours une valeur paire… Je n’ai pas d’explication à ça.

Sur une autre machine j’ai bien un mélange ~50/50 de valeurs paires/impaires.

Quelle est l'origine de l'imprévisibilité de la durée d'exécution d'une séquence d'instructions ?
Est-ce principalement lié aux pipelines, aux caches, à l'exécution dans le désordre et au prédicteur de branchement ?

À toutes ces choses là, exactement, auxquelles il faut aussi ajouter :

• la différence entre la fréquence du processeur et la fréquence du bus mémoire (pouvant occasionner un délai de synchronisation entre les deux lors des accès mémoire) ;
• la variation de la fréquence du processeur dans le temps ;
• les fonctionnalités d’économie d’énergie ;
• le déplacement du processus d’un processeur à un autre ;
• les interruptions matérielles.

On peut facilement toucher du doigt cette imprévisibilité avec le petit test suivant :

#include <stdio.h>
#include <stdint.h>

extern __inline__ uint64_t
rdtsc(void) {
    uint64_t a, d;

    __asm__ volatile ("rdtsc" : "=a" (a), "=d" (d));
    return (d<<32) | a;
}

int
main(int argc, char **argv)
{
    uint64_t prev, cur;
    unsigned n;

    prev = rdtsc();

    for ( n = 0; n < 10; n++ ) {
        cur = rdtsc();
        printf("Δ TSC: %lu\n", cur - prev);
        prev = cur;
    }

    return 0;
}

Un exemple d’exécution chez moi :

$ ./a.out
Δ TSC: 28
Δ TSC: 86490
Δ TSC: 1728
Δ TSC: 1114
Δ TSC: 37814
Δ TSC: 1096
Δ TSC: 982
Δ TSC: 1240
Δ TSC: 1020
Δ TSC: 976


Même s’il semble clairement y avoir un biais en faveur de valeurs proches de ~1000, la variabilité est quand même bien là.

Évidemment, plus la séquence d’instruction exécutée dans la boucle est longue et complexe, et plus sa durée d’exécution sera variable. Dans le noyau, c’est carrément l’ordonnanceur du système qui est appelé dans la boucle entre deux lectures du compteur, de sorte qu’à la variabilité du processeur lui-même s’ajoute celle du système (qui va varier en fonction de la charge, des activités en provenance des périphériques, etc.).

J'imagine que sous DOS en 1995 le pseudo-aléatoire ne résistait à des attaques que par le manque de puissance de calcul de l'époque?

En 1995, je ne sais pas, mais au moins jusqu’à la fin des années 1980, d’après la littérature de l’époque il est clair que la plupart des RNG mis à la disposition des programmeurs n’étaient pas terribles.

Par exemple, une étude¹ du RNG fourni avec le compilateur FORTRAN de Microsoft pour MS-DOS avait montré que le générateur avait une période d’à peine 50 000 nombres, et globalement échouait à tous les tests statistiques.

La préoccupation de l’époque n’était même pas d’être résistant aux attaques cryptanalytiques, c’était juste d’avoir des nombres suffisamment aléatoires pour ne pas biaiser les résultats des simulations scientifiques — si le générateur n’est même pas assez bon pour ça, aucune chance qu’il soit bon pour des applications cryptographiques…

RDRAND → pool d'entrée entrée (le brassage) → pool d'entrée en sorti → pool de sortie en entrée (le brassage) → pool d'entrée en sortie (chacha20)

Euh, non.

1) RDRAND n’est pas vraiment considérée comme une source d’entropie, et à ce titre les octets produits par RDRAND ne suivent pas le chemin « normal » comme ceux produits par les autres sources d’entropie. RDRAND est plutôt traitée comme une sorte « d’agent confondant », intervenant à différents points le long du trajet pour semer un peu plus de désordre.

Même lorsque RDRAND est utilisée pour initialiser le CSPRNG (avec l’option RANDOM_TRUST_CPU), cela passe par un chemin à part (directement RDRAND -> CSPRNG), sans passer par le pool d’entrée et donc sans contribuer au compteur de « l’entropie disponible ».

2) Le « chaînage d’algo » entre les sources d’entropie et les périphériques de sortie est le suivant (dans le cas des version ≥ 5.6) :

source d’entropie -> fonction de mixage du pool d’entrée -> fonction d’extraction du pool d’entrée (en gros SHA-1) -> initialisation du CSPRNG ChaCha20 -> extraction depuis le CSPRNG

D'ailleurs j'ai une question, maintenant que le pool de sorti bloquant n'existe plus quel est l'intérêt de distinguer le pool d'entrée du pool de sorti ?

Pas sûr de comprendre là… Il n’y a plus de pool de sortie. Les pools de sortie, c’était le pool non-bloquant et le pool bloquant. Les deux n’existent plus, tous deux remplacés par le CSPRNG ChaCha20.

Le seul pool qui reste désormais est le « pool d’entrée ».

La sécurité est un monde fascinant : l’existence même d'une simple méthode qui arrive à prédire un bit à 49,9% de chances serait considérée comme une faille.

Perso j'ai aucune idée de comment on pourrait exploiter une telle faille

À titre d’exemple, une attaque sur l’algorithme de chiffrement RC4 exploite un biais en apparence anodin dans la sortie de l’algorithme : la probabilité que le deuxième octet soit nul est de 2/256, au lieu de 1/256 si l’algorithme produisait réellement un flux pseudo-aléatoire.

Les détails de l’attaque dépassent largement mes compétences, mais c’est à cause de ce genre de faiblesses que RC4 est désormais largement déconseillé.

A minima un agent PGP ne me sert pas à grand-chose et devrait disparaître.

Ça fait bien longtemps que l’agent GnuPG est indispensable au fonctionnement de GnuPG. Seul GnuPG 1.4.x peut encore fonctionner sans agent. Toutes les versions ultérieures ont besoin de l’agent, c’est le seul composant qui accède directement aux clefs privées. GnuPG sans son agent n’est tout simplement pas fonctionnel.

puisque je les utilise quotidiennement, ils ont donc des fenêtres d'ouverture pendant lesquelles je ne peux que supposer qu'ils exposent mes accès.

C’est vrai pour l’agent SSH, qui conserve en mémoire les clefs chargées sous une forme en clair, pour la durée de son existence.

En revanche, l’agent GnuPG :

• ne garde jamais les clefs en mémoire, que ce soit en clair ou non ; lorsque l’agent a besoin d’une clef privée, elle est lue depuis le disque, utilisée pour la tâche à accomplir (déchiffrer ou signer quelque chose), puis immédiatement supprimée de la mémoire de l’agent ;
• ne garde les phrases de passe en mémoire que pour un moment (10 minutes par défaut), jamais pour la durée de vie de l’agent.

Il existe une norme open source de carte à puce USB qui a fait un peu parler d’elle. Le but était de pouvoir se connecter avec elle sur un site Web, Firefox ayant un module dédié pour cela. Les impôts, au début, utilisaient la méthode des certificats personnels pour s’identifier, le problème est qu’ils étaient stockés sur la machine et étaient perdus en cas de changement ou de réinstallation. Ils pouvaient aussi être volés (par un virus dédié). Cela n’aurait pas été le cas avec une telle sorte de clef.

Tu fais référence à quelle norme, et quel module Firefox ?

Pour moi ça ressemble à la description de Scute, un module PKCS#11 pour Firefox qui permet d’utiliser un certificat X.509 dont la clef privée est stockée sur une carte OpenPGP.

Sauf que… je ne crois pas que Scute ait jamais vraiment fait parler de lui, même « un peu » (j’en suis le premier chagriné d’ailleurs, vu que j’en suis le mainteneur !), donc je me dis que ça ne doit pas être ça… Et du coup je suis curieux de savoir de quelle norme il s’agit !