Traçage protonmail

[Papawaan]

@koopa59 dans un email, tu ne peux rien espérer d’autre que ces infos d’en-tête qui sont laissées par le/les mailrelay. Ici, les infos que les admins du mailrelay de proton on décidé de mettre en le configurant pour cela.
Le protocole SMTP est utilisé depuis les débuts d’internet, il n’a pas évolué du tout, et il est réellement très permissif. Le S c’est pour Simple (Simple Mail Transfer Protocol).
Potentiellement tu peux établir une connection sur le port SMTP (25) d’un mailrelay avec un simple outil comme telnet, et taper ce que tu veux comme en-têtes, expéditeur, dates, etc ; seul le ou les destinataires doit/doivent être correct(s) pour que le mail arrive ; pour le reste, ces infos que le destinataire aura dans le mail – et c’est tout ce qu’il aura – l’expéditeur peut mettre ce qu’il veut, protocolement parlant. C’est d’ailleurs pour cela qu’on reçoit des spams à tout bout de champ.

Pour la petite histoire, il y a quelques années, les mecs chez google qui ont créé maps se sont essayé à ré-inventer un protocole plus actuel pour remplacer les mails que tout le monde utilise.
Ils ont fait un truc beaucoup plus sécurisé, en terme de protocole. Plus riche en fonctionnalités aussi, plus actuel. Assez chouette d’ailleurs. Des spécifications complètement ouvertes.
Google en a codé une implémentation qu’ils ont appelé google waves. Et puis, comme beaucoup de projets chez google, c’est passé à la poubelle.
Je n’en n’ai plus jamais entendu parler depuis!

[duJambon]

La sécurité s’est quand même bien renforcée, chez bluewin le port 25 est fermé depuis longtemps, il faut s’authentifier, tout est crypté et si l’entête du client ne correspond pas à celle attendue chez le mailer, ils rajoutent un “prétendument de:” devant le nom reçu et ajoutent celui du compte client sur la ligne suivante.

Je ne pense pas qu’ils fassent moins bien chez proton.

[Papawaan]

Oui, si tu utilise leur mailrelay, ou n’importe lequel bien configuré chez n’importe quel fournisseur sérieux.
Ce que je voulais dire, c’est que tu peux aussi utiliser un mailrelay moins regardant et avec lequel tu peux envoyer des emails avec des informations d’en-tête arbitraires – d’un point de vue du protocole. C’est ce que font les spammeurs. Le protocole SMTP – c’est de cela dont je parlait – permet d’envoyer des emails contenant des informations sensées tracer les mails ne correspondant pas à la réalité (puis qu’on peut mettre, en réalité, ce que l’on veut: du point de vue du protocole, c’est déclaratif).

Heureusement que bien des mailrelay sont configurés pour ajouter un peu de sécurité. Le cryptage des contenus aussi, ou des échanges entre un client de mail et le serveur.
Il n’en reste pas moins que le protocole que toute la planète utilise largement, le SMTP, a été créé par quelques nerds pour échanger des infos entre deux universités au début des années 1980, sans aucune autre préoccupation (légitimement à l’époque).
C’est à la fois rigolo et effrayant qu’on utilise encore ce protocole pour quelque chose d’aussi répandu, et important, de nos jours!

[Violence]

@Papawaan a dit dans Traçage protonmail :

C’est à la fois rigolo et effrayant qu’on utilise encore ce protocole pour quelque chose d’aussi répandu, et important, de nos jours!

Surtout que c’est surtout utilisé en entreprise et en commerce.

En tant que particulier, c’est à mon avis voué à disparaitre comme le SMS…

[Papawaan]

Je suis bien d’accord @Violence, et probablement le plus tôt sera le mieux.
Mais ça a la peau dure tellement c’est utilisé!
Ca fait déjà des années que c’est voué à disparaître ; la tentative de google, qui a échoué, date d’il y a déjà une quinzaine d’années.

[Raccoon]

Je teste encore l’envoi SMTP via telnet sur le port 25 depuis chez mes clients pour m’assurer que leurs copieurs pourront faire du scan to mail via Exhange Online, à condition d’avoir préalablement créé un connecteur. Et comme tu l’as précisé @Papawaan il n’y a que le mail du destinataire qui doit être authentique, pour tous les autres champs on peut renseigner ce qui nous chante.

[Violence]

@Raccoon a dit dans Traçage protonmail :

Je teste encore l’envoi SMTP via telnet sur le port 25

??? Le smtp non sécurisé est à bannir.
Perso ce port est bloqué par défaut sur nos réseaux.

J’ai peut être mal compris.

[Papawaan]

Il faut différencier le protocole (SMTP) et la communication entre le client de mail (thunderbird, telnet, … send_a_spam.exe, …) et le mailrelay. Historiquement, non sécurisée, non cryptée, sur le port 25. Maintenant c’est vrai et heureusement, on s’est entendu pour ajouter de la sécurité ; exemple une com encryptée STARTTLS sur le port 587. Si les deux parties (client et mailrelay) le supportent, ce canal de communication remplace celui sur le port 25 non sécurisé. Ceci dit, ce que le client et le mailrelay s’échangent – encryption mise à part – est la même chose dans les deux cas. C’est dicté par le protocole, encore et toujours, SMTP.
Le fait de ne plus utiliser de connection en clair sur le port 25 mais encryptée sur le port 587, par exemple, évite que le flux puisse être intercepté et compris par un tiers entre le client et le mailrelay (en théorie, si encrypté, il peut toujours potentiellement être intercepté mais plus compris!)

Avec un mailrelay qui écoute sur le port 25 sans sécurité, on peut illustrer cela facilement.
Il suffit d’apprendre comment marche le protocole SMTP ; c’est facile, c’est vraiment Simple.
ex
une fois connecté au mailrelay via telnet <mailrelay> 25
on peut taper des lignes de texte, conformes au protocole, et qui seront donc interprétées par le mailrelay pour exédier un mail. C’est d’ailleurs assez amusant.
Exemple:

RCTP To: <[email protected]>
Received: from lutin_456 ([195.186.120.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) C-du-sérieux) by dovecot-proxy-lutin-789 with LMTPS id CookieAuLait:T9855
From: Santa <[email protected]>
Subject: Tu as reçu un cadeau!

Cher Monsieur, veuillez noter que ce mail est bidon :-)
^D

C’est ce que fait, ni plus ni moins un client de mail (enfin si, un peu plus quand même ; il rajoute des champs valables en en-tête, encode le contenu du message éventuellement en html ou en base64, ce genre de petites fioritures).
Le destinataire ([email protected]) recevra un mail ayant comme objet “Tu as reçu un cadeau!” et provenant de “Santa” avec un reply to “[email protected]”.
Plus, si on les regarde, la ligne d’en-tête “from lutin_456 etc etc” que j’ai ajoutée, plus les lignes d’en-tête qui seront ajoutées par les mailrelays dans la chaîne de distribution du mail.

On pourrait créer un petit soft qui ferait la connection STARTTLS sur le port 587 du mailrelay, pour y déposer le même mail expédié par Santa (ce que ne permet pas telnet – ou peut-être utiliser curl au lieu de telnet, il doit y avoir moyen avec curl ? … à creuser à l’occasion).
Oui @Violence tu as raison, on n’utilise plus si on travaille bien le port 25 non sécurisé, mais on utilise toujours le protocole SMTP, qui lui, protocolement parlant, ne l’est pas du tout.

[Papawaan]

Bon on a fait une sévère digression par rapport à la question initiale …

[Violence]

@Papawaan a dit dans Traçage protonmail :

Oui @Violence tu as raison, on n’utilise plus si on travaille bien le port 25 non sécurisé, mais on utilise toujours le protocole SMTP, qui lui, protocolement parlant, ne l’est pas du tout.

Oui nous sommes bien d’accord

[duJambon]

Reste à passer l’authentification et le mailer qui ajoute l’entête du client authentifié…

C’est plus simple de passer par un gmail ou autre.

De plus, malgré toutes les conneries au-dessus du premier relais, le premier point correct donnera l’endroit de l’injection et le log de celui-ci donnera l’ip de l’injecteur. Un gouvernement suffisamment motivé pourra toujours remonter la chaine de vpn jusqu’à la source, simple question de temps.

[Raccoon]

@Violence a dit dans Traçage protonmail :

@Raccoon a dit dans Traçage protonmail :

Je teste encore l’envoi SMTP via telnet sur le port 25

??? Le smtp non sécurisé est à bannir.
Perso ce port est bloqué par défaut sur nos réseaux.

J’ai peut être mal compris.

Tu as bien compris mais seule l’IP publique du client est autorisée à utiliser son Exchange Online comme relai.
Il y a encore beaucoup de copieurs qui ne sont pas compatibles oauth2 et quand les gens veulent du scan to mail il n’y a pas d’autres choix.