Mouais, enfin répondre ECMAScript, CSS3 ou WebCrypto alors que la question portait sur l’implémentation des « balises HTML5 (par exemple les input type="date") », c’est quand même un peu à côté de la plaque…
À voir, parce que le message original dit bien que le démon est lancé par l’utilisateur mpd, ce qui n’est pas très cohérent a priori avec un lancement au démarrage de la session graphique (dans ce cas il serait lancé avec le compte de l’utilisateur de la session).
Ajouté au fait que le même message dit que le problème est apparu avec systemd (« C'est comme ça depuis que c'est systemd qui gère mon démarrage »), pointer systemd du doigt ne me paraît pas déraisonnable, même si un bug d’empaquetage (plutôt qu’un bug de systemd lui-même) ou un bug d’interface chaise-clavier ne sont pas à exclure.
(Et si c’est bien systemd le fautif, le commentaire façon « ceux-qui-accusent-systemd-sont-forcément-des-lennart-hatter » serait d’autant plus croustillant. :-D )
Ça va dépendre de la configuration de smtp.orange.fr, mais en principe il devrait y avoir quelque chose comme client@orange.fr, où client est le nom associé au compte dudit client chez Orange.
Je ne vais pas relever utilisateur@orange.fr, que je n'utilise pas, juste pour voir si j'ai des erreurs sur mes envois.
Ben si tu passes par les serveurs d’Orange pour envoyer, ça ne me paraît pas déconnant…
Si je choisis l'option MX -all, est-ce que j'oblige mes utilisateurs à passer par mon SMTP ?
Non. Si on reprend ton exemple : je suis chez Orange, et je passe par leur serveur pour envoyer un mail avec l’adresse de mon compte chez toi.
smtp.orange.fr contacte le MX du destinataire et lui annonce :
HELO smtp.orange.fr
MAIL FROM: gouttegd@orange.fr
(« Coucou, je suis smtp.orange.fr, j’ai un mail pour quelqu’un de chez toi de la part de gouttegd@orange.fr »)
À ce moment-là, le serveur du destinataire vérifie que smtp.orange.fr figure bien parmi les machines listées dans l’enregistrement SPF de orange.fr. Comme c’est le cas (enfin, ce serait le cas s’il y avait un SPF chez orange.fr), le serveur accepte le mail (et le flagge éventuellement avec un en-tête indiquant qu’il a passé la validation SPF, comme Received-SPF: pass ou Authentication-Result: spf=pass).
À aucun moment le fait que l’en-tête From: du message indique gouttegd@domaine.tld n’est entré en ligne de compte. En fait, ton enregistrement SPF n’a jamais été consulté.
Il ne faut pas se méprendre sur le rôle de SPF : il ne sert pas à empêcher un utilisateur d’usurper une adresse qui n’est pas la sienne (SPF ne m’empêchera pas d’envoyer un message avec From: françois.hollande@élysée.fr).
Ce que SPF sert à éviter, c’est ça (exemple réel tout juste tiré de mon dossier SPAM) :
Return-Path: <educational.permissions@example.com>
Received-SPF: Softfail ('domain owner discourages use of this host') identity=mailfrom; client-ip=182.98.254.225; helo=mx32.usaindiamunish.net; envelope-from=educational.permissions@example.com; receiver=webmaster@incenp.org;
Received: from mx32.usaindiamunish.net (unknown [182.98.254.225])
by mail.incenp.org (Postfix) with SMTP id 4824F9C30E
for <webmaster@incenp.org>; Mon, 8 Dec 2014 03:02:21 +0100 (CET)
Ici, la machine mx32.usaindiamunish.net a contacté mon serveur en prétendant avoir un message venant de educational.permissions@example.com, alors qu’il n’y est pas autorisé par le SPF de example.com (j’ai changé le nom de domaine original, puisqu’il n’est pour rien dans ce spam — c’est lui la victime de l’usurpation en fait).
En gros, mx32.usaindiamunish.net envoie du spam en tentant de faire porter le chapeau à example.com. L’enregistrement SPF de example.com permet à tout le monde de déjouer la supercherie (et d’éviter à example.com d’être accusé d’envoyer du spam).
Je pense que je dois passer à côté de quelque chose. Par exemple, dans ce paragraphe, je ne comprends pas à quoi correspond la sender address, si ce n'est pas le champ From. Je pense que c'est le nœud du problème.
Le problème, c’est que ce terme de « champ From » est ambigu et peut désigner deux choses complètement différentes.
Pour l’expliquer, l’analogie avec le courrier postal est souvent employée et je la trouve assez pertinente.
La sender address, ou adresse « d’expédition », « d’enveloppe », « de retour » (parfois aussi appelé, plus formellement, « 5321.MailFrom », du numéro du RFC qui décrit le protocole SMTP), c’est l’adresse qui figure au dos de l’enveloppe du courrier, celle à laquelle le facteur renvoie l’enveloppe s’il ne peut pas la distribuer.
Elle est distincte de l’adresse qui apparaît dans l’en-tête From: du message (« 5322.From », du numéro du RFC qui décrit le format des e-mails), et qui est analogue à l’adresse située en-tête du courrier proprement dit (à l’intérieur de l’enveloppe).
Concrètement, l’adresse « 5321.MailFrom » est celle qu’envoie le client SMTP pour annoncer au serveur qu’il a un mail à envoyer. Comme le dit le passage que tu cites, ça se passe au tout début du dialogue SMTP (juste après le EHLO) :
MAIL FROM: return-address@example.net
À ce moment-là, le serveur (s’il implémente SPF) peut vérifier si le domaine example.net a un enregistrement SPF et, le cas échéant, si l’adresse du client fait partie des adresses autorisées par ledit enregistrement.
While the address in the Return-Path often matches other originator addresses in the mail header such as From or Sender, this is not necessarily the case, and SPF does not prevent forgery of these other addresses.
Comme le dit ce passage, rien n’oblige le 5321.MailFrom et le 5322.From a être identique (tout comme l’adresse de retour au dos d’une enveloppe peut être différente de l’adresse mentionnée sur le papier à en-tête). SPF ne concerne que le 5321.MailFrom.
si je comprend bien, tu me demandes de parler quand je n'ai rien à dire.
Non, je te dis que quand tu n’as rien à dire sur l’article proprement dit, tu peux juste… ne rien dire, plutôt que de chercher à critiquer les trois lignes du résumé.
L’ironie de l’histoire est que c’est ton intervention qui donne à ce résumé une importance qu’il n’était probablement pas censé avoir.
Vous pouvez moinsser, mais au moins vous pourriez aussi m'expliquer
Pour ma part, je moinsse parce que j’estime que critiquer un résumé de trois lignes sur un article de 40 ko (le résumé n’étant là que pour ceux qui ont la flemme de lire l’article en question), ben… ce n’est pas pertinent.
Tout comme le fait de vouloir débattre dudit résumé et de la justesse de la métaphore au lieu de débattre, je ne sais pas moi, du contenu de l’article peut-être.
Une partie au moins devait être dû à la complexité inhérente de PulseAudio, dont Lennart Poettering, probablement plus réaliste que ses fan-boys, est d’ailleurs bien conscient. Il n’a jamais caché que « intégrer PulseAudio dans une distribution n’est pas une mince affaire » — “Adopting PA in a distribution is a fair amount of work, given that it interfaces with so many different things at so many different places.”
Sauf que Alsa contenait une grande liste de correctifs pour palier les bogues des pilotes pour communiquer avec ces cartes là, PulseAudio ne l'a pas fait
Je ne comprends pas, là. PulseAudio est en aval de ALSA (ou en amont, ça dépend du point de vue), si ALSA fait le nécessaire pour « palier les bogues des pilotes », PulseAudio devrait en bénéficier automatiquement (comme n’importe quel programme qui utiliserait ALSA directement)…
Pourquoi faudrait-il que PulseAudio refasse ce qui est déjà fait dans ALSA ?
L’intérêt par rapport à X.509 est que ce dernier ne permet que de faire du pyramidal, là où OpenPGP permet de faire aussi bien du décentralisé que du pyramidal.
Avec un certificat X.509, si le visiteur ne fait pas confiance à la seule autorité de certification qui a signé le certificat, il n’a aucun autre moyen de vérifier le certificat (sauf à recourir à des méthodes non-prévues par X.509, comme DANE, Monkeysphere, Convergence ou assimilées).
Avec un certificat OpenPGP, le visiteur a plus d’options : il peut faire complètement confiance en une des autorités de certification qui a signé le certificat, il peut faire marginalement confiance (c’est possible avec OpenPGP, contrairement à X.509) en plusieurs des autorités de certifications qui ont signé le certificat, il peut connaître personnellement et faire complètement confiance à un des administrateurs du site (qui a ajouté sa propre signature au certificat, en plus des signatures posées par les autorités de certification), il peut connaître indirectement plusieurs personnes responsables du site et leur accorder une confiance partielle, etc.
Je suppose que IdenTrust est lui soumis à ces contrainte
Oui.
qui doivent précisément définir dans quelles circonstance il peut autoriser de CA intermédiaires
Non, il n’y a aucune contrainte de ce genre. Chaque CA racine est libre de signer des sous-CA comme bon lui semble.
et quelles contraintes ces CA intermédiaires doivent respecter.
Oui. Les CA intermédiaires DEVRAIENT (SHALL, au sens du RFC 2119) respecter les consignes du CA/Browser Forum (les mêmes que celles qu’on demande aux CA racines).
Sauf que, à la différence des CA racines qui doivent prouver aux éditeurs de navigateurs leur conformité à ces consignes, les CA intermédiaires n’ont pas à justifier de quoi que ce soit auprès de qui que ce soit.
En particulier, les CA racines n’ont aucune obligation de vérifier que les CA intermédiaires qu’elles signent respectent ces consignes, sauf dans le cas très particulier des CA intermédiaires dites « techniquement contraintes ».
(Une CA intermédiaire « techniquement contrainte » est une CA dont le certificat limite explicitement, par le biais d’une extension X.509v3 Name Constraints, les noms pour lesquelles elle est autorisée à émettre des certificats. À ma connaissance, cette possibilité de limiter le champ d’action d’une sous-CA n’est quasiment pas utilisée — le seul cas que j’ai jamais vu était une sous-CA signée par le ministère américain de la défense, qui lui avait interdit de signer des noms en .mil.)
mais pas un mot sur quand et comment ils comptent arriver à ça.
Alors, il n’y a rien sur le site de Let’s Encrypt, mais l’annonce de J. Alex Halderman apporte une réponse : leur certificat racine sera signé par IdenTrust, qui est déjà dans les magasins des navigateurs :
We recently completed a cross-signing agreement with IdenTrust that will let certificates from Let’s Encrypt be trusted by almost all web browsers from day one. We’re also going to work with browser makers to have our root integrated into major browsers going forward, to ensure lasting trust.
Avant de vous réjouir, réfléchissez un peu à ce que ça signifie.
Ça veut dire que cette nouvelle CA (sous-CA, en réalité, ou CA intermédiaire) aura automatiquement la confiance de tous les navigateurs et pourra signer des certificats valides partout… alors qu’elle n’aura été soumise à aucune des contraintes dictées par le CA/Browser Forum, ni exposée à aucune vérification par les responsables des navigateurs. Let’s Encrypt peut ne pas avoir de politique de sécurité, ne pas avoir fait l’objet d’un audit… ça n’empêchera pas les navigateurs de lui faire confiance. Les seules contraintes pesant sur Let’s Encrypt sont celles éventuellement dictées dans l’accord qui lie la nouvelle CA à son signataire IdenTrust, que ni Let’s Encrypt ni IdenTrust n’ont l’obligation de rendre public.
Notez qu’il n’y a là rien de spécifique à Let’s Encrypt et IdenTrust : c’est juste une illustration du problème posé par les CA intermédiaires, auxquelles les directives du CA/Browser Forum (les mêmes que CAcert ne satisfait pas, faute d’audit) ne s’appliquent pas puisqu’elles ne concernent que les CA racines. Tant qu’une CA ne cherche pas à entrer dans le magasin des navigateurs, rien ne l’oblige à satisfaire ces directives.
Je note bien que Let’s Encrypt annonce aussi dans le même passage son intention d’entrer justement dans le magasin des navigateurs, et donc de se plier à terme aux exigences du CA/Browser Forum. C’est tout à leur honneur.
Mais en attendant, cette nouvelle CA n’existera que grâce à une faille du système, celle qui permet aux CA intermédiaires de s’affranchir des obligations des CA racines. Tout va bien, ayez confiance…
Avec un système d'autorités de certifications, si je ne fais pas une confiance absolue a la dite autorité, je risque a tout moment un man in the middle par quelqu'un qui a mis l'autorité de certification dans sa poche (une agence gouvernementale par exemple).
Avec le système actuel d’autorités de certifications, tu risques à tout moment un man in the middle par quelqu’un qui a mis l’une quelconque des centaines de CA et leurs sous-CA dans sa poche.
Ceci indépendamment du fait que tu fasses une confiance absolue à l’autorité en question (au passage, la confiance dans une CA est forcément absolue : ou ton navigateur la considère de confiance, ou non ; on ne peut pas accorder de confiance relative à une CA).
Une alternative gratuite et reconnue par tous les navigateurs sera un vrai souffle d'air.
Rien ne permet de prévoir pour l’instant que cette nouvelle CA sera « reconnue par tous les navigateurs ». À moins que j’ai raté quelque chose, il n’y a rien sur le site concernant l’inclusion de leur certificat racine dans le magasin des principaux navigateurs. Le sujet a l’air d’être soigneusement évité.
Il y a bien deux pages qui indiquent en passant que les certificats sont trusted (About) et browser-trusted (How It Works), mais pas un mot sur quand et comment ils comptent arriver à ça.
S’il suffisait d’afficher « trusted certificate » sur une page web pour obtenir la confiance des navigateurs, CAcert serait dans les magasins par défaut depuis longtemps…
De mémoire, l’Académie française exprime cette idée en disant que le masculin est le genre non-marqué, dans le sens où contrairement au féminin (genre marqué), il ne porte pas de « marque » le différenciant du neutre.
Je regrette d’ailleurs que cette explication, que je n’ai jamais entendue sur les bancs de l’école, ne soit pas plus souvent employée à la place de la formule « le masculin l’emporte sur le féminin ». Outre le fait que cette dernière est un chiffon rouge agité sous le nez des féministes, je n’ai jamais apprécié cette tournure si informelle, si familière — on n’exprime pas une règle grammaticale de cette façon.
Il est probablement possible de configurer l’appareil pour que le clavier et les pads utilisent des canaux MIDI différents (sinon ça réduit pas mal l’intérêt, je trouve). Tu règles le clavier sur le canal 1 et les pads sur le canal 2 (par exemple), puis tu configures tes instruments logiciels pour écouter sur les bons canaux.
Malheureusement, si j’en crois le Quick Start Guide du constructeur (pp. 3–4), le réglage des canaux MIDI n’est accessible que depuis l’éditeur logiciel fourni pour Windows et Mac OS X, et pas depuis l’appareil lui-même. J’espère que je me trompe, sinon c’est très moche…
typiquement attribué le volume et le bend du clavier à ZASFX
Bah ce sont des contrôleurs standards et ZynAddSubFX agit automatiquement en conséquence quand il les reçoit, donc il n’y a rien de particulier en faire.
Il suffit de connecter la sortie MIDI de ton clavier à l’entrée de ZynAddSubFX (avec le patchbay de Qjackctl, Patchage, ou n’importe quel outil permettant de manipuler les connections Jack).
En gros, si ZynAddSubFX reçoit les messages Note On/Off (c’est-à-dire qu’il émet bien un son quand tu enfonces une touche de ton clavier), il recevra aussi les messages des contrôleurs de volume/expression/pitchbend etc. À condition bien sûr que ton clavier émette bien ces messages quand tu manipules le bouton de volume ou la molette de pitchbend, ce qui devrait être explicitement indiqué dans la MIDI Implementation Chart fournie avec.
Honnêtement, j'ai fait ça à minima avec juste un firewall. C'est juste un serveur de test qui n'héberge aucune données sensibles
La plupart des attaquants ne sont pas intéressés par les données qui peuvent se trouver sur une machine ; c’est la machine elle-même qui les intéresse.
C'est vrai que ce scénario fait un peu théorie du complot. Mais ce qui me fait pencher sur ce scénario c'est cela : http://pastebin.com/RXzgKmD0 (extrait du /var/log/auth).
J'héberge sur ce serveur mon petit neveu Ernest. Étant donné son âge, il est impossible qu'il se soit loggé par ssh à 4h du matin. Par contre, le robot semblait connaître le mot de passe à l'avance puisqu'il a réussi à se connecter dés la première tentative.
Si tu regardes le reste de l’extrait de /var/auth/log, tu peux constater que juste avant, la même adresse (185.25.151.145 — qui n’est probablement pas celle de la machine de ton petit neveu, tu peux essayer un whois dessus pour voir à qui elle appartient) a essayé successivement "erling", "erma", "ermolaev" (sans succès puisque ta machine n’a pas de comptes utilisateurs avec ces noms). Après avoir réussi à se connecter avec "ernest", elle a d’ailleurs continué avec "ernest21" et "ernestina"…
Ça ressemble donc beaucoup plus à un scan bête et méchant avec un dictionnaire de noms d’utilisateurs qu’à une attaque ciblée.
Quant à savoir comment l’attaquant a pu trouver le mot de passe de "ernest" à la première tentative de connexion avec ce nom-là : es-tu sûr que c’est la première tentative ? Je soupçonne que tu si tu remontes plus loin dans les logs, tu en verras beaucoup d’autres.
Pour éviter que la même chose ne se reproduise, fail2ban est effectivement une bonne solution. Éviter les mots de passe trop faibles serait aussi une bonne chose, et se passer de mots de passe pour n’utiliser que l’authentification par clefs en serait une encore meilleure.
Ici il s’agit de demander aux outils (binutils) classiques
Je ne sais pas pour FreeBSD, mais sous GNU/Linux binutils fait référence aux outils qui permettent de manipuler les fichiers objets et les exécutables binaires (des programmes comme strip, as, readelf, ar, objdump, etc.). Les outils Unix « classiques » comme df, w ou wc n’en font pas partie.
Je profite de ce thread pour présenter une manière de valider les certificats que j’aimerais voir dans les navigateurs (et que j’ai déjà implémentébidouillé dans mon Uzbl).
L’idée maîtresse est de permettre de vérifier un certificat par toute une série de mécanismes distincts — au lieu de se reposer uniquement sur le système PKIX comme actuellement — et de prendre la décision finale d’accepter le certificat (et donc d’afficher la page) ou de le rejeter (et de présenter un message d’erreur) en fonction du résultat combiné de tous les mécanismes.
Le principe consiste en une sorte de « pipeline de validateurs », où chaque validateur teste à tour de rôle le certificat présenté par le serveur et renvoie un score négatif pour un certificat invalide, un score positif pour un certificat valide, ou un score nul si la validation est impossible (le validateur ne peut pas se prononcer sur ce certificat). À la sortie du pipeline, le certificat est accepté si le score final est positif, rejeté si le score est négatif. Si le score est nul, la décision revient à l’utilisateur, à qui un message présente les résultats de chaque validateur.
Les validateurs possibles incluent (liste non exhaustive, justement un des buts de cette approche est de pouvoir ajouter de nouveaux mécanismes de validation sans tout chambouler) :
un validateur PKIX, comme ce qui existe déjà dans tous les navigateurs (renvoie 1 si le certificat est correct et signé — directement ou non — par une autorité de certification qui a la confiance de l’utilisateur, -1 si le certificat n’est pas correct, ou 0 si l’autorité de certification n’est pas connue) ;
un validateur DANE (renvoie 1 si le certificat correspond à au moins un enregistrement TLSA, 0 s’il n’y a pas d’enregistrements TLSA, -1 s’il y a des enregistrements TLSA et que le certificat du serveur ne correspond à aucun d’entre eux) ;
un validateur Monkeysphere (renvoie 1 si le certificat est présent dans la toile OpenPGP et qu’il existe un chemin de confiance jusqu’à lui, 0 dans tous les autres cas) ;
un validateur mémorisant les certificats associés à chaque hôte (renvoie 1 si le certificat actuellement présenté par le serveur est le même que celui mémorisé lors d’une précédente visite, -1 s’il est différent, 0 lors de la première visite) ;
un validateur de « bonnes pratiques », qui attribue un score négatif à tout certificat ne respectant pas certains critères de qualité (par exemple avoir une clef suffisamment grande, ou ne pas utiliser SHA-1).
L’utilisateur aurait la possibilité d’activer ou désactiver les validateurs de son choix, et aussi éventuellement de changer le « poids » accordé à chaque validateur dans le score final.
En gros, on ne jette pas PKIX à la poubelle (même si franchement, j’aimerais beaucoup…), mais on considère ça comme un moyen de valider un certificat parmi d’autres. On pourrait aussi ajouter des validateurs pour Convergence, Certificate Transparency, etc.
P.S. : Je sais qu’il existe pour Firefox des plugins pour chacun des mécanismes de validation décrits ci-dessus (DNSSEC/TLSA Validator, xul-ext-monkeysphere, CertWatch, etc.). Mais il manque, à ma connaissance, l’intégration de tous ces plugins dans un « pipeline » unique, donnant un seul résultat en sortie.
Oh que non, il y a aussi eu des cas d'autorités de certification qui ont émis des certificat pour des noms de domaines données à l'intention de gens qui n'en étaient pas du tout propriétaires.
Je me suis peut-être mal exprimé, par « certificats falsifiés » je voulais parler, pour répondre à voxmundix, de certificats générés avec une fausse signature, rendue permise par une collision sur l’algorithme de condensation.
Je n’incluais pas dans ce lot les certificats avec une signature authentique (réellement apposée par l’autorité de certification) mais émise à mauvais escient (par une AC malhonnête ou piratée).
[^] # Re: Et le support standard du HTML 5 ??
Posté par gouttegd . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 3.
Mouais, enfin répondre ECMAScript, CSS3 ou WebCrypto alors que la question portait sur l’implémentation des « balises HTML5 (par exemple les input type="date") », c’est quand même un peu à côté de la plaque…
Et pour l’exemple cité, non, personne ne travaille à implémenter les contrôles de formulaire de type date/time.
[^] # Re: autostart ?
Posté par gouttegd . En réponse au message mpd démarre tout seul. Évalué à 2.
À voir, parce que le message original dit bien que le démon est lancé par l’utilisateur mpd, ce qui n’est pas très cohérent a priori avec un lancement au démarrage de la session graphique (dans ce cas il serait lancé avec le compte de l’utilisateur de la session).
Ajouté au fait que le même message dit que le problème est apparu avec systemd (« C'est comme ça depuis que c'est systemd qui gère mon démarrage »), pointer systemd du doigt ne me paraît pas déraisonnable, même si un bug d’empaquetage (plutôt qu’un bug de systemd lui-même) ou un bug d’interface chaise-clavier ne sont pas à exclure.
(Et si c’est bien systemd le fautif, le commentaire façon « ceux-qui-accusent-systemd-sont-forcément-des-lennart-hatter » serait d’autant plus croustillant. :-D )
[^] # Re: Je comprends toujours pas
Posté par gouttegd . En réponse au message SPF : autoriser l'envoi par un autre SMTP. Évalué à 3. Dernière modification le 08 décembre 2014 à 11:46.
Ça va dépendre de la configuration de smtp.orange.fr, mais en principe il devrait y avoir quelque chose comme client@orange.fr, où client est le nom associé au compte dudit client chez Orange.
Ben si tu passes par les serveurs d’Orange pour envoyer, ça ne me paraît pas déconnant…
Non. Si on reprend ton exemple : je suis chez Orange, et je passe par leur serveur pour envoyer un mail avec l’adresse de mon compte chez toi.
smtp.orange.fr contacte le MX du destinataire et lui annonce :
(« Coucou, je suis smtp.orange.fr, j’ai un mail pour quelqu’un de chez toi de la part de
gouttegd@orange.fr»)À ce moment-là, le serveur du destinataire vérifie que smtp.orange.fr figure bien parmi les machines listées dans l’enregistrement SPF de orange.fr. Comme c’est le cas (enfin, ce serait le cas s’il y avait un SPF chez orange.fr), le serveur accepte le mail (et le flagge éventuellement avec un en-tête indiquant qu’il a passé la validation SPF, comme
Received-SPF: passouAuthentication-Result: spf=pass).À aucun moment le fait que l’en-tête
From:du message indiquegouttegd@domaine.tldn’est entré en ligne de compte. En fait, ton enregistrement SPF n’a jamais été consulté.Il ne faut pas se méprendre sur le rôle de SPF : il ne sert pas à empêcher un utilisateur d’usurper une adresse qui n’est pas la sienne (SPF ne m’empêchera pas d’envoyer un message avec
From: françois.hollande@élysée.fr).Ce que SPF sert à éviter, c’est ça (exemple réel tout juste tiré de mon dossier SPAM) :
Ici, la machine
mx32.usaindiamunish.neta contacté mon serveur en prétendant avoir un message venant deeducational.permissions@example.com, alors qu’il n’y est pas autorisé par le SPF deexample.com(j’ai changé le nom de domaine original, puisqu’il n’est pour rien dans ce spam — c’est lui la victime de l’usurpation en fait).En gros,
mx32.usaindiamunish.netenvoie du spam en tentant de faire porter le chapeau àexample.com. L’enregistrement SPF deexample.compermet à tout le monde de déjouer la supercherie (et d’éviter àexample.comd’être accusé d’envoyer du spam).# Distinguer 5321.MailFrom de 5322.From
Posté par gouttegd . En réponse au message SPF : autoriser l'envoi par un autre SMTP. Évalué à 4.
Le problème, c’est que ce terme de « champ From » est ambigu et peut désigner deux choses complètement différentes.
Pour l’expliquer, l’analogie avec le courrier postal est souvent employée et je la trouve assez pertinente.
La sender address, ou adresse « d’expédition », « d’enveloppe », « de retour » (parfois aussi appelé, plus formellement, « 5321.MailFrom », du numéro du RFC qui décrit le protocole SMTP), c’est l’adresse qui figure au dos de l’enveloppe du courrier, celle à laquelle le facteur renvoie l’enveloppe s’il ne peut pas la distribuer.
Elle est distincte de l’adresse qui apparaît dans l’en-tête
From:du message (« 5322.From », du numéro du RFC qui décrit le format des e-mails), et qui est analogue à l’adresse située en-tête du courrier proprement dit (à l’intérieur de l’enveloppe).Concrètement, l’adresse « 5321.MailFrom » est celle qu’envoie le client SMTP pour annoncer au serveur qu’il a un mail à envoyer. Comme le dit le passage que tu cites, ça se passe au tout début du dialogue SMTP (juste après le EHLO) :
À ce moment-là, le serveur (s’il implémente SPF) peut vérifier si le domaine
example.neta un enregistrement SPF et, le cas échéant, si l’adresse du client fait partie des adresses autorisées par ledit enregistrement.Comme le dit ce passage, rien n’oblige le 5321.MailFrom et le 5322.From a être identique (tout comme l’adresse de retour au dos d’une enveloppe peut être différente de l’adresse mentionnée sur le papier à en-tête). SPF ne concerne que le 5321.MailFrom.
[^] # Re: Trop facile résumé...
Posté par gouttegd . En réponse au journal Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10. Dernière modification le 29 novembre 2014 à 18:00.
Non, je te dis que quand tu n’as rien à dire sur l’article proprement dit, tu peux juste… ne rien dire, plutôt que de chercher à critiquer les trois lignes du résumé.
L’ironie de l’histoire est que c’est ton intervention qui donne à ce résumé une importance qu’il n’était probablement pas censé avoir.
[^] # Re: Trop facile résumé...
Posté par gouttegd . En réponse au journal Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 9.
Pour ma part, je moinsse parce que j’estime que critiquer un résumé de trois lignes sur un article de 40 ko (le résumé n’étant là que pour ceux qui ont la flemme de lire l’article en question), ben… ce n’est pas pertinent.
Tout comme le fait de vouloir débattre dudit résumé et de la justesse de la métaphore au lieu de débattre, je ne sais pas moi, du contenu de l’article peut-être.
[^] # Re: Mwai
Posté par gouttegd . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 9.
Une partie au moins devait être dû à la complexité inhérente de PulseAudio, dont Lennart Poettering, probablement plus réaliste que ses fan-boys, est d’ailleurs bien conscient. Il n’a jamais caché que « intégrer PulseAudio dans une distribution n’est pas une mince affaire » — “Adopting PA in a distribution is a fair amount of work, given that it interfaces with so many different things at so many different places.”
[^] # Re: Mwai
Posté par gouttegd . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 5.
Je ne comprends pas, là. PulseAudio est en aval de ALSA (ou en amont, ça dépend du point de vue), si ALSA fait le nécessaire pour « palier les bogues des pilotes », PulseAudio devrait en bénéficier automatiquement (comme n’importe quel programme qui utiliserait ALSA directement)…
Pourquoi faudrait-il que PulseAudio refasse ce qui est déjà fait dans ALSA ?
[^] # Re: Meilleur HTTPS => éviter X.509
Posté par gouttegd . En réponse au journal Il est temps que vous ayez un meilleur HTTPS. Évalué à 10.
L’intérêt par rapport à X.509 est que ce dernier ne permet que de faire du pyramidal, là où OpenPGP permet de faire aussi bien du décentralisé que du pyramidal.
Avec un certificat X.509, si le visiteur ne fait pas confiance à la seule autorité de certification qui a signé le certificat, il n’a aucun autre moyen de vérifier le certificat (sauf à recourir à des méthodes non-prévues par X.509, comme DANE, Monkeysphere, Convergence ou assimilées).
Avec un certificat OpenPGP, le visiteur a plus d’options : il peut faire complètement confiance en une des autorités de certification qui a signé le certificat, il peut faire marginalement confiance (c’est possible avec OpenPGP, contrairement à X.509) en plusieurs des autorités de certifications qui ont signé le certificat, il peut connaître personnellement et faire complètement confiance à un des administrateurs du site (qui a ajouté sa propre signature au certificat, en plus des signatures posées par les autorités de certification), il peut connaître indirectement plusieurs personnes responsables du site et leur accorder une confiance partielle, etc.
[^] # Re: J'espère que c'est vrai...
Posté par gouttegd . En réponse au journal Encryptons. Évalué à 3.
Oui.
Non, il n’y a aucune contrainte de ce genre. Chaque CA racine est libre de signer des sous-CA comme bon lui semble.
Oui. Les CA intermédiaires DEVRAIENT (SHALL, au sens du RFC 2119) respecter les consignes du CA/Browser Forum (les mêmes que celles qu’on demande aux CA racines).
Sauf que, à la différence des CA racines qui doivent prouver aux éditeurs de navigateurs leur conformité à ces consignes, les CA intermédiaires n’ont pas à justifier de quoi que ce soit auprès de qui que ce soit.
En particulier, les CA racines n’ont aucune obligation de vérifier que les CA intermédiaires qu’elles signent respectent ces consignes, sauf dans le cas très particulier des CA intermédiaires dites « techniquement contraintes ».
(Une CA intermédiaire « techniquement contrainte » est une CA dont le certificat limite explicitement, par le biais d’une extension
X.509v3 Name Constraints, les noms pour lesquelles elle est autorisée à émettre des certificats. À ma connaissance, cette possibilité de limiter le champ d’action d’une sous-CA n’est quasiment pas utilisée — le seul cas que j’ai jamais vu était une sous-CA signée par le ministère américain de la défense, qui lui avait interdit de signer des noms en .mil.)[^] # Re: J'espère que c'est vrai...
Posté par gouttegd . En réponse au journal Encryptons. Évalué à 10.
Alors, il n’y a rien sur le site de Let’s Encrypt, mais l’annonce de J. Alex Halderman apporte une réponse : leur certificat racine sera signé par IdenTrust, qui est déjà dans les magasins des navigateurs :
Avant de vous réjouir, réfléchissez un peu à ce que ça signifie.
Ça veut dire que cette nouvelle CA (sous-CA, en réalité, ou CA intermédiaire) aura automatiquement la confiance de tous les navigateurs et pourra signer des certificats valides partout… alors qu’elle n’aura été soumise à aucune des contraintes dictées par le CA/Browser Forum, ni exposée à aucune vérification par les responsables des navigateurs. Let’s Encrypt peut ne pas avoir de politique de sécurité, ne pas avoir fait l’objet d’un audit… ça n’empêchera pas les navigateurs de lui faire confiance. Les seules contraintes pesant sur Let’s Encrypt sont celles éventuellement dictées dans l’accord qui lie la nouvelle CA à son signataire IdenTrust, que ni Let’s Encrypt ni IdenTrust n’ont l’obligation de rendre public.
Notez qu’il n’y a là rien de spécifique à Let’s Encrypt et IdenTrust : c’est juste une illustration du problème posé par les CA intermédiaires, auxquelles les directives du CA/Browser Forum (les mêmes que CAcert ne satisfait pas, faute d’audit) ne s’appliquent pas puisqu’elles ne concernent que les CA racines. Tant qu’une CA ne cherche pas à entrer dans le magasin des navigateurs, rien ne l’oblige à satisfaire ces directives.
Je note bien que Let’s Encrypt annonce aussi dans le même passage son intention d’entrer justement dans le magasin des navigateurs, et donc de se plier à terme aux exigences du CA/Browser Forum. C’est tout à leur honneur.
Mais en attendant, cette nouvelle CA n’existera que grâce à une faille du système, celle qui permet aux CA intermédiaires de s’affranchir des obligations des CA racines. Tout va bien, ayez confiance…
[^] # Re: J'espère que c'est vrai...
Posté par gouttegd . En réponse au journal Encryptons. Évalué à 4.
Parce qu’elle répondra aux critères de Mozilla pour l’inclusion des CA, ou parce qu’il y a deux personnes de Mozilla dans le comité de direction ?
[^] # Re: Ça ne résout pas le problème de fond
Posté par gouttegd . En réponse au journal Encryptons. Évalué à 8.
Avec le système actuel d’autorités de certifications, tu risques à tout moment un man in the middle par quelqu’un qui a mis l’une quelconque des centaines de CA et leurs sous-CA dans sa poche.
Ceci indépendamment du fait que tu fasses une confiance absolue à l’autorité en question (au passage, la confiance dans une CA est forcément absolue : ou ton navigateur la considère de confiance, ou non ; on ne peut pas accorder de confiance relative à une CA).
[^] # Re: J'espère que c'est vrai...
Posté par gouttegd . En réponse au journal Encryptons. Évalué à 3.
Rien ne permet de prévoir pour l’instant que cette nouvelle CA sera « reconnue par tous les navigateurs ». À moins que j’ai raté quelque chose, il n’y a rien sur le site concernant l’inclusion de leur certificat racine dans le magasin des principaux navigateurs. Le sujet a l’air d’être soigneusement évité.
Il y a bien deux pages qui indiquent en passant que les certificats sont trusted (About) et browser-trusted (How It Works), mais pas un mot sur quand et comment ils comptent arriver à ça.
S’il suffisait d’afficher « trusted certificate » sur une page web pour obtenir la confiance des navigateurs, CAcert serait dans les magasins par défaut depuis longtemps…
[^] # Re: Hum
Posté par gouttegd . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 5.
De mémoire, l’Académie française exprime cette idée en disant que le masculin est le genre non-marqué, dans le sens où contrairement au féminin (genre marqué), il ne porte pas de « marque » le différenciant du neutre.
Je regrette d’ailleurs que cette explication, que je n’ai jamais entendue sur les bancs de l’école, ne soit pas plus souvent employée à la place de la formule « le masculin l’emporte sur le féminin ». Outre le fait que cette dernière est un chiffon rouge agité sous le nez des féministes, je n’ai jamais apprécié cette tournure si informelle, si familière — on n’exprime pas une règle grammaticale de cette façon.
[^] # Re: Utilisation de vérification via les enregistrements DNS(SEC)
Posté par gouttegd . En réponse au sondage Comme autorité de certification pour linuxfr.org je préfèrerais.... Évalué à 3.
C’est proposé aussi pour les clefs OpenPGP (il y a plusieurs propositions d’ailleurs).
Le type TLSA a été créé pour ça (RFC 6698).
[^] # Re: Update
Posté par gouttegd . En réponse à la dépêche Qpsycle, un studio modulaire de création musicale, cherche des développeurs. Évalué à 2.
Il est probablement possible de configurer l’appareil pour que le clavier et les pads utilisent des canaux MIDI différents (sinon ça réduit pas mal l’intérêt, je trouve). Tu règles le clavier sur le canal 1 et les pads sur le canal 2 (par exemple), puis tu configures tes instruments logiciels pour écouter sur les bons canaux.
Malheureusement, si j’en crois le Quick Start Guide du constructeur (pp. 3–4), le réglage des canaux MIDI n’est accessible que depuis l’éditeur logiciel fourni pour Windows et Mac OS X, et pas depuis l’appareil lui-même. J’espère que je me trompe, sinon c’est très moche…
[^] # Re: bonne fois
Posté par gouttegd . En réponse à la dépêche Qpsycle, un studio modulaire de création musicale, cherche des développeurs. Évalué à 4.
Bah ce sont des contrôleurs standards et ZynAddSubFX agit automatiquement en conséquence quand il les reçoit, donc il n’y a rien de particulier en faire.
Il suffit de connecter la sortie MIDI de ton clavier à l’entrée de ZynAddSubFX (avec le patchbay de Qjackctl, Patchage, ou n’importe quel outil permettant de manipuler les connections Jack).
En gros, si ZynAddSubFX reçoit les messages Note On/Off (c’est-à-dire qu’il émet bien un son quand tu enfonces une touche de ton clavier), il recevra aussi les messages des contrôleurs de volume/expression/pitchbend etc. À condition bien sûr que ton clavier émette bien ces messages quand tu manipules le bouton de volume ou la molette de pitchbend, ce qui devrait être explicitement indiqué dans la MIDI Implementation Chart fournie avec.
# Deux points à vérifier
Posté par gouttegd . En réponse au message Règle udev pour lancer un programme suite à une connexion USB. Évalué à 2.
Dans quel fichier est enregistré cette règle ? Le nom du fichier se termine-t-il bien par
.rules?As-tu bien rechargé les règles après avoir créé ce fichier (
udevadm control --reload) ?[^] # Re: Logs
Posté par gouttegd . En réponse au message Piratage de mon serveur et détection d'intrusion. Évalué à 3.
La plupart des attaquants ne sont pas intéressés par les données qui peuvent se trouver sur une machine ; c’est la machine elle-même qui les intéresse.
[^] # Re: Pas forcément une intrusion
Posté par gouttegd . En réponse au message Piratage de mon serveur et détection d'intrusion. Évalué à 3.
Si tu regardes le reste de l’extrait de /var/auth/log, tu peux constater que juste avant, la même adresse (185.25.151.145 — qui n’est probablement pas celle de la machine de ton petit neveu, tu peux essayer un whois dessus pour voir à qui elle appartient) a essayé successivement "erling", "erma", "ermolaev" (sans succès puisque ta machine n’a pas de comptes utilisateurs avec ces noms). Après avoir réussi à se connecter avec "ernest", elle a d’ailleurs continué avec "ernest21" et "ernestina"…
Ça ressemble donc beaucoup plus à un scan bête et méchant avec un dictionnaire de noms d’utilisateurs qu’à une attaque ciblée.
Quant à savoir comment l’attaquant a pu trouver le mot de passe de "ernest" à la première tentative de connexion avec ce nom-là : es-tu sûr que c’est la première tentative ? Je soupçonne que tu si tu remontes plus loin dans les logs, tu en verras beaucoup d’autres.
Pour éviter que la même chose ne se reproduise, fail2ban est effectivement une bonne solution. Éviter les mots de passe trop faibles serait aussi une bonne chose, et se passer de mots de passe pour n’utiliser que l’authentification par clefs en serait une encore meilleure.
# binutils ?
Posté par gouttegd . En réponse au journal Du xml dans vos outils CLI. Évalué à 6.
Je ne sais pas pour FreeBSD, mais sous GNU/Linux binutils fait référence aux outils qui permettent de manipuler les fichiers objets et les exécutables binaires (des programmes comme strip, as, readelf, ar, objdump, etc.). Les outils Unix « classiques » comme df, w ou wc n’en font pas partie.
[^] # Re: PKIX + DANE + Monkeysphere
Posté par gouttegd . En réponse au sondage Comme autorité de certification pour linuxfr.org je préfèrerais.... Évalué à 8.
Je profite de ce thread pour présenter une manière de valider les certificats que j’aimerais voir dans les navigateurs (et que j’ai déjà
implémentébidouillé dans mon Uzbl).L’idée maîtresse est de permettre de vérifier un certificat par toute une série de mécanismes distincts — au lieu de se reposer uniquement sur le système PKIX comme actuellement — et de prendre la décision finale d’accepter le certificat (et donc d’afficher la page) ou de le rejeter (et de présenter un message d’erreur) en fonction du résultat combiné de tous les mécanismes.
Le principe consiste en une sorte de « pipeline de validateurs », où chaque validateur teste à tour de rôle le certificat présenté par le serveur et renvoie un score négatif pour un certificat invalide, un score positif pour un certificat valide, ou un score nul si la validation est impossible (le validateur ne peut pas se prononcer sur ce certificat). À la sortie du pipeline, le certificat est accepté si le score final est positif, rejeté si le score est négatif. Si le score est nul, la décision revient à l’utilisateur, à qui un message présente les résultats de chaque validateur.
Les validateurs possibles incluent (liste non exhaustive, justement un des buts de cette approche est de pouvoir ajouter de nouveaux mécanismes de validation sans tout chambouler) :
un validateur PKIX, comme ce qui existe déjà dans tous les navigateurs (renvoie 1 si le certificat est correct et signé — directement ou non — par une autorité de certification qui a la confiance de l’utilisateur, -1 si le certificat n’est pas correct, ou 0 si l’autorité de certification n’est pas connue) ;
un validateur DANE (renvoie 1 si le certificat correspond à au moins un enregistrement TLSA, 0 s’il n’y a pas d’enregistrements TLSA, -1 s’il y a des enregistrements TLSA et que le certificat du serveur ne correspond à aucun d’entre eux) ;
un validateur Monkeysphere (renvoie 1 si le certificat est présent dans la toile OpenPGP et qu’il existe un chemin de confiance jusqu’à lui, 0 dans tous les autres cas) ;
un validateur mémorisant les certificats associés à chaque hôte (renvoie 1 si le certificat actuellement présenté par le serveur est le même que celui mémorisé lors d’une précédente visite, -1 s’il est différent, 0 lors de la première visite) ;
un validateur de « bonnes pratiques », qui attribue un score négatif à tout certificat ne respectant pas certains critères de qualité (par exemple avoir une clef suffisamment grande, ou ne pas utiliser SHA-1).
L’utilisateur aurait la possibilité d’activer ou désactiver les validateurs de son choix, et aussi éventuellement de changer le « poids » accordé à chaque validateur dans le score final.
En gros, on ne jette pas PKIX à la poubelle (même si franchement, j’aimerais beaucoup…), mais on considère ça comme un moyen de valider un certificat parmi d’autres. On pourrait aussi ajouter des validateurs pour Convergence, Certificate Transparency, etc.
P.S. : Je sais qu’il existe pour Firefox des plugins pour chacun des mécanismes de validation décrits ci-dessus (DNSSEC/TLSA Validator, xul-ext-monkeysphere, CertWatch, etc.). Mais il manque, à ma connaissance, l’intégration de tous ces plugins dans un « pipeline » unique, donnant un seul résultat en sortie.
[^] # Re: systemd ?
Posté par gouttegd . En réponse au message IP sur blacklist, impossible d'envoyer des mails avec postfix. Évalué à 2.
Il voulait dire « regarder de plus près dans les logs », je suppose — les logs en question étant probablement gérés par systemd-journald.
[^] # Re: auto signé
Posté par gouttegd . En réponse au sondage Comme autorité de certification pour linuxfr.org je préfèrerais.... Évalué à 4.
Je me suis peut-être mal exprimé, par « certificats falsifiés » je voulais parler, pour répondre à voxmundix, de certificats générés avec une fausse signature, rendue permise par une collision sur l’algorithme de condensation.
Je n’incluais pas dans ce lot les certificats avec une signature authentique (réellement apposée par l’autorité de certification) mais émise à mauvais escient (par une AC malhonnête ou piratée).