Cherche explications pour utilisation d'adresses piratées

[roro123]

Bonjour à tous

J'aimerai avoir des explications techniques SVP
Ma fille a une messagerie sur Hotmail.
Son FAI est Darty.
Voici quelque jours elle me sigale que son carnet d'adresses
ne s'affiche plus.... il a disparu !!
Elle a dû le retaper.
Ma question concerne des mails expédiés par une société
de pubs X... sur des multimédias (PC, téléphone..) rien d'alarmant
pour ....l'instant sur le thème des mails, mais cela peut
s'élargir à d'autres Pubs.
J'aimerai comprendre SVP le côté technique du piratage.
Imaginons que la Société X a récupéré un carnet d'adressses
elle va l'utiliser pour élargir son champ de contacts.

C'est classique le mail vient de la société DUPONT par exemple.
OK cela je comprends mais ce qui méchappe c'est que tous les
anciens correspondants de ma fille (dont moi-même) nous recevons
plusieurs fois cette Pub mais l'expéditeur n'est pas la Société X mais
ma fille. Autement dit comme si ma fille envoyait la pub
et semblait intéressée par les objectifs de vente.
Ce n'est pas le cas, elle n'envoie rien mais pouriez-vous SVP
m'expliquer la manoeuvre technique utilisée par ces pirates
des adresses.
Je ne sais pas si je suis assez clair.
Si c'est le cas je vous remercie d'avance de votre réponse


Bon dimanche
-----

[Towl]

En gros, et sans rentrer dans les détails, le protocole d'envoi de mail n'assure en aucun cas l'identification de la personne qui a envoyer le mail. Quand on envoie un mail, la premiere question que nous pose le serveur, c'est qui etes vous, et il n'y a aucune vérification, il vous fait confiance. Il suffit de mettre l'adresse mail de XXX pour que le mail apparaisse comme envoyé par XXX.

[roro123]

Bonjour Towl

Pardon pour le retard à te remercier mais j'ai dû m'absenter.

Je te remercie pour ton explication car je n'y avais pas pensé.


Bonne fin d'après-midi

[invite6754323456711]

Bonjour,

C'est la raison pour laquelle il faudrait passer assez rapidement sur des dispositifs d'authentification des mails fiable (par exemple signer électroniquement le contenu du mail et une partie de son en-tête) car aujourd’hui, de nombreux vers utilisent cette possibilité d’usurpation d’identité pour envoyer de faux e-mails ressemblant à des vrais. Cela serait aussi une nouvelle arme antispam.

Ces nouveaux dispositifs d'authentification des mails doivent rester gratuits.

Patrick

[A voir en vidéo sur Futura]

[Bruno]

En gros, et sans rentrer dans les détails, le protocole d'envoi de mail n'assure en aucun cas l'identification de la personne qui a envoyer le mail. Quand on envoie un mail, la premiere question que nous pose le serveur, c'est qui etes vous, et il n'y a aucune vérification, il vous fait confiance. Il suffit de mettre l'adresse mail de XXX pour que le mail apparaisse comme envoyé par XXX.

Oui enfin, avec le SPF et SenderID, c'est pas très compliqué de voir que le FROM est faussé...

C'est la raison pour laquelle il faudrait passer assez rapidement sur des dispositifs d'authentification des mails fiable (par exemple signer électroniquement le contenu du mail et une partie de son en-tête)

Bof, ça nécessite un certificat et c'est pas donné question prix...

[Towl]

Oui enfin, avec le SPF et SenderID, c'est pas très compliqué de voir que le FROM est faussé...

Encore faut il que tout le monde utilise le SPF (le SenderID étant soumis à brevet, rejeté par Apache et Debian, définit par l'IETF comme violant les normes internet me semble pas le choix idéal). Or, à l'heure actuelle, nombre de fournisseur d'adresse mail n'utilise pas cela. On peut faire comme hotmail et décider que tous les fournisseurs qui ne le supportent pas sont du spam, mais cela reste quand même assez bourrin comme aproche.
On a donc pour l'instant pas de moyen fiable de savoir si c'est un faux ou un serveur qui ne respecte pas le standard SPF.

Bof, ça nécessite un certificat et c'est pas donné question prix...

Il existe aussi PGP (et OpenGPG) qui permettent cela sans avoir de certificat. Par contre, comme toute solution d'indentification basée sur la confiance, ça n'est utilisable que dans les cercles "fermés" de relation

[invite6754323456711]

Bonjour,

voir : http://www.dkim.org/

Patrick

[Bruno]

voir : http://www.dkim.org/

Je ne suis pas certain que la solution soit d'identifier tout le monde, on est quand même en train de s'agiter sur un protocole (trop?) permissif par nature.

Encore faut il que tout le monde utilise le SPF (le SenderID étant soumis à brevet, rejeté par Apache et Debian, définit par l'IETF comme violant les normes internet me semble pas le choix idéal).

Un lien intéressant là-dessus ?

Or, à l'heure actuelle, nombre de fournisseur d'adresse mail n'utilise pas cela. On peut faire comme hotmail et décider que tous les fournisseurs qui ne le supportent pas sont du spam, mais cela reste quand même assez bourrin comme aproche.

Ou bien faire comme maintenant : utiliser les greylist/blacklist intégrées à des solutions comme spamassassin. Dans tous les cas, il faut être maitre de son serveur mail si on veut mettre en place qqch d'efficace.

On a donc pour l'instant pas de moyen fiable de savoir si c'est un faux ou un serveur qui ne respecte pas le standard SPF.

Pas de solution fiable, ça n'existe nulle part, mais on s'en sort pas mal avec les moyens actuels quand on sait que 90% des emails sont du spam.

Il existe aussi PGP (et OpenGPG) qui permettent cela sans avoir de certificat. Par contre, comme toute solution d'indentification basée sur la confiance, ça n'est utilisable que dans les cercles "fermés" de relation

Yep, mais tu as le problème du certificat fait maison qui fait hurler ton mozilla. C'est plus une solution pour échanger des données sensibles, vu que ça se base sur le cryptage qui implique une auth, plutot bourrin comme solution..

[invite6754323456711]

Je ne suis pas certain que la solution soit d'identifier tout le monde, on est quand même en train de s'agiter sur un protocole (trop?) permissif par nature.

http://en.wikipedia.org/wiki/DomainKeys

"Note that DomainKeys does not directly prevent abusive behavior; rather, it allows abuse to be tracked and detected more easily."

Patrick

[Towl]

Un lien intéressant là-dessus ?

Dans la RFC 4406 :

Participants in the Sender-ID experiment need to be aware that the
way Resent-* header fields are used will result in failure to receive
legitimate email when interacting with standards-compliant systems
(specifically automatic forwarders which comply with the standards by
not adding Resent-* headers, and systems which comply with RFC 822
but have not yet implemented RFC 2822 Resent-* semantics). It would
be inappropriate to advance Sender-ID on the standards track without
resolving this interoperability problem.

En fait, tout le paragraphe "IESG Note" est interressant pour voir que cette solution (et SPF) ne sont pas assez mure et pose quelques problèmes.

Yep, mais tu as le problème du certificat fait maison qui fait hurler ton mozilla

Non PGP et OpenGPG ne se basent pas sur des certificats, c'est justement l'avantage de cette solution. Le principe est que X publie sa clé publique K(X) sur un site, carte de visite, la donne au recepteur. Y fait de même. Si X fait confiance à Y (en ayant importé K(Y)), alors les mails signés par Y sont reconnus comme valide.
Après il y a aussi la possibilité de créer des réseau de confiance : X fait confiance à Y, je fais confiance à X, donc je fais confiance à Y. Enfin internet te donneras plus de détail sur cette approche, ses avantages (surtout pour des communautés de gens qui se connaissent) et ses travers

[Bruno]

http://en.wikipedia.org/wiki/DomainKeys

"Note that DomainKeys does not directly prevent abusive behavior; rather, it allows abuse to be tracked and detected more easily."

Patrick

Ok, en gros on transpose l'idée du SSL avec des clés privées/publiques et la signature dans les headers ? Finalement on en revient au problème du certificat pas gratuit, quoiqu'il n'y ait pas besoin d'avoir les coordonnées du proprio dans ce cas. Perso, je préfère encore SPF : plus simple et le même principe de base.

Dans la RFC 4406 :

En fait, tout le paragraphe "IESG Note" est interressant pour voir que cette solution (et SPF) ne sont pas assez mure et pose quelques problèmes.

Ok, merci.

Non PGP et OpenGPG ne se basent pas sur des certificats, c'est justement l'avantage de cette solution. Le principe est que X publie sa clé publique K(X) sur un site, carte de visite, la donne au recepteur. Y fait de même. Si X fait confiance à Y (en ayant importé K(Y)), alors les mails signés par Y sont reconnus comme valide.
Après il y a aussi la possibilité de créer des réseau de confiance : X fait confiance à Y, je fais confiance à X, donc je fais confiance à Y. Enfin internet te donneras plus de détail sur cette approche, ses avantages (surtout pour des communautés de gens qui se connaissent) et ses travers

J'avais utilisé OpenGPG pour mes emails, et je me souviens encore des alertes de Thunderbird.. ptet parce que je cryptais. Mais on est d'accord, c'est pas une solution transposable à tout le net.

[invite6754323456711]

Perso, je préfère encore SPF : plus simple et le même principe de base.

Le futur protocole SSP (Signing Practices Protocol) doit permettre de résoudre les limitations de DKIM.

SPF n'est il pas abandonné (Experimental RFC 4408) ?

SPF, normalisé dans le RFC 4408, avait été critiqué car son langage, très puissant, permettait d'exprimer des politiques complètes qui auraient pu mener à une avalanche de requêtes DNS à chaque message reçu.

http://2005.jres.org/slides/36.pdf

Patrick

[invite6754323456711]

Perso, je préfère encore SPF : plus simple et le même principe de base.

Il existe des différences fondamentales entre SPF et DKIM. DKIM tout comme OpenPGP est bout en bout alors que SPF est canal par canal.

Principe de base du DomainKeys : repose sur une signature cryptographique automatique des messages. La clé publique est diffusée via le DNS (ou d’autres canaux, à venir). Le MX émetteur dispose de la clé privée du domaine. Ne révèle pas l’architecture de la messagerie sortante. Basé sur des clés asymétriques, signature des entêtes et du contenu, pas de distribution des clés. L'objectif est de valider :

• L'intégrité du message
• L'authenticité du domaine
• Responsabilité du message

Principe de base de SPF : insére dans le DNS des informations identifiant les serveurs autorisés à émettre pour un certain domaine. Le MX de réception fait le contrôle reposant sur l’adresse IP du MTA opposé. SPF est donc basé sur l'authentification de l'adresse source IP du MTA et non sur une authentification par cryptographie. Ne protège donc pas l'intégrité du contenu du message. Problème identifié : le forwarding ne change pas le MAIL FROM.

Patrick

[Bruno]

Principe de base du DomainKeys : repose sur une signature cryptographique automatique des messages. La clé publique est diffusée via le DNS (ou d’autres canaux, à venir). Le MX émetteur dispose de la clé privée du domaine.

Tu peux m'expliquer comment se déroule la signature ? Pour moi, un système asymétrique permet d'envoyer des données cryptées à une machine, je vois pas comment le smtp va décrypter sans clé publique ou sans négociation d'une clé commune ?

Ne révèle pas l’architecture de la messagerie sortante.

Tu peux préciser ce que tu entends par "architecture" ?

pas de distribution des clés.

???

Principe de base de SPF : insére dans le DNS des informations identifiant les serveurs autorisés à émettre pour un certain domaine. Le MX de réception fait le contrôle reposant sur l’adresse IP du MTA opposé. SPF est donc basé sur l'authentification de l'adresse source IP du MTA et non sur une authentification par cryptographie. Ne protège donc pas l'intégrité du contenu du message.

Pour ce qui est de l'intégrité du message, on s'en fou un peu vu qu'il s'agit de spam. La machine source est suffisante.

[Towl]

Tu peux m'expliquer comment se déroule la signature ? Pour moi, un système asymétrique permet d'envoyer des données cryptées à une machine, je vois pas comment le smtp va décrypter sans clé publique ou sans négociation d'une clé commune ?

D'apres ce que j'ai compris, les données ne sont pas chiffrées mais signées. Pour cela il suffit juste que l'émetteur (le MX) chiffre un hash du message avec la clé privée. Le récepteur n'a qu'a déchiffrer le hash (avec la clée publique fournit par le DNS ou autre moyen), et le calculer de son coté. Si il obtient le meme résultat, le message est bien envoyé par le serveur prétendu (avec tous les apport de la crypto appliqué à la signature : non répudiation, intégrité...)

[invite6754323456711]

Tu peux m'expliquer comment se déroule la signature ? Pour moi, un système asymétrique permet d'envoyer des données cryptées à une machine, je vois pas comment le smtp va décrypter sans clé publique ou sans négociation d'une clé commune ?

Voir schéma joint.

Pour l'instant tes seuls arguments sont bof ou c'est basé sur le même principe ... Pas trés scientifique tous cela.

Autres précisions :

Disponible gratuitement, cette technologie DKIM, à laquelle Microsoft souscrit, utilise le système DNS pour la diffusion de clés publiques et n'impose aucune modification des logiciels clients (MUA) comme Outlook, Notes ou Thunderbird

Google utilise DKIM pour son service gmail

En fait Utilisés conjointement (donc pas basé sur les mêmes principes), DKIM et SPF vont permettre plus de vérifications d’intégrité dans la transmission du courriel. L'objectif qui est recherché ne se restreint pas uniquement au SPAM. Comme je l'ai déja précisé :

"Note that DomainKeys does not directly prevent abusive behavior; rather, it allows abuse to be tracked and detected more easily."

Patrick

[Bruno]

D'apres ce que j'ai compris, les données ne sont pas chiffrées mais signées. Pour cela il suffit juste que l'émetteur (le MX) chiffre un hash du message avec la clé privée. Le récepteur n'a qu'a déchiffrer le hash (avec la clée publique fournit par le DNS ou autre moyen), et le calculer de son coté. Si il obtient le meme résultat, le message est bien envoyé par le serveur prétendu (avec tous les apport de la crypto appliqué à la signature : non répudiation, intégrité...)

Ok, donc dans l'histoire la clé privée est diffusée et la clé publique reste sur l'émetteur.

Disponible gratuitement, cette technologie DKIM, à laquelle Microsoft souscrit, utilise le système DNS pour la diffusion de clés publiques et n'impose aucune modification des logiciels clients (MUA) comme Outlook, Notes ou Thunderbird

Bah non, SPF non plus. Par contre du coté du smtp, bonne chance pour le patcher.

[Towl]

Non la clé privée est sur le serveur, la clé publique est diffusée. Tu as la propriété suivante avec les algo assymétrique :


Il devient donc possible de chiffrer avec la clé privée pour déchiffrer avec la clé publique : 1 personne sait chiffrer, tout le monde sait déchiffrer (dit autrement : 1 personne sait signer, tout le monde sait le vérifier)

[Bruno]

Ok, d'habitude on chiffre avec une clé publique et déchiffre avec une clé privée. C'est donc bien ce que je disais : on inverse le modèle courant. (je me comprend)

[invite6754323456711]

Ok, d'habitude on chiffre avec une clé publique et déchiffre avec une clé privée. C'est donc bien ce que je disais : on inverse le modèle courant. (je me comprend)

Une autre propriété intéressante d’une paire de clé d’un système à clé publique : la clé publique est la seule à pouvoir décrypter ce qui est crypté par la clé privé. Pourquoi dans ce cas crypter avec la clé privée alors que la clé publique est accessible à tous ???? Ce processus, c’est en fait la signature numérique : si vous pouvez déchiffrer un message avec ma clé publique, vous êtes sûr qu’il a bien été crypté par ma clé privée dont moi seul peux me servir. Vous pouvez donc m’identifier avec certitude et être assuré de la nature et provenance des données que vous venez de recevoir.



Patrick

[roro123]

Bonjourà tous

Je ne citerai pas vos pseudos individuellement mais je tiens
à vous dire que j'apprécie vos échanges de "pros" que vous êtes.
Mais en ce qui me concerne je suis largué.... par vos explications.

Je suis admiratif devant vos connaissances mais mon petit
niveau et malgré quelques années sur le PC je découvre avec
effroi tout le chemin qui me reste à parcourir.

Merci quand même à tous d'avoir répondu à mon post

Bonne journée

[roro123]

Bonjour à tous

Pardon pour le retard à vous remercier mais j'étais absent.

Merci à tous d'avoir répondu à mon post mais j'avoue que devant
tant de "pros" et de "spécialistes" je suis émerveillé mais aussi inquiet
d'être aussi nul.
Je lis vos échanges de messages mais.... je suis largué car je
ne comprends pas tout.

J'ai donc des progrès à faire
Cela me fait penser au professeur à l'hôpital qui me parlait
dans un langage médical complexe et incompréhensible... pour moi.

Bon après-midi à tous