Mails entrants rejetés "no shared cipher"

Support
,
1

Mon serveur YunoHost

Matériel: Raspberry Pi à la maison
Version de YunoHost: 4.0.8.3
J’ai accès à mon serveur : En SSH | Par la webadmin |
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Description du problème

Bonjour à tous,
Un de mes utilisateurs a eu un mail entrant rejeté par le serveur pour cause d’absence de ciphers partagés entre l’envoyeur et le serveur Yunohost. Je partage les logs trouvés dans /var/log/mail.log :

Dec  6 03:07:50 apps postfix/smtpd[15220]: connect from envoyeur.fr[IP]
Dec  6 03:07:50 apps postfix/smtpd[15220]: SSL_accept error from envoyeur.fr[IP]: -1
Dec  6 03:07:50 apps postfix/smtpd[15220]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2259:
Dec  6 03:07:50 apps postfix/smtpd[15220]: lost connection after STARTTLS from envoyeur.fr[IP]
Dec  6 03:07:50 apps postfix/smtpd[15220]: disconnect from envoyeur.fr[IP] ehlo=1 starttls=0/1 commands=1/2

Et après 286 tentatives d’envois, l’envoyeur a reçu

Échec de la remise pour ces destinataires ou groupes :

'monutilisateur@mondomaine.fr' (monutilisateur@mondomaine.fr)
Le serveur a essayé de remettre ce message sans succès et a cessé d'essayer. Essayez de renvoyer ce message. Si le problème persiste, contactez le support technique.

Informations de diagnostic pour les administrateurs :

Serveur de génération : serveurenvoyeur
Serveur de réception : monserveur (monip)
Total retry attempts: 286

monutilisateur@mondomaine.fr
06/12/2020 08:51:15 - Remote Server at monserveur (monip) returned '550 4.4.7 QUEUE.Expired; message expired'
06/12/2020 08:41:09 - Remote Server at monserveur (monip) returned '451 4.4.0 SMTPSEND.SuspiciousRemoteServerError; remote server disconnected abruptly; retry will be delayed'

En-têtes de message d'origine :

Received: from serveurenvoyeur by

serveurenvoyeur with Microsoft SMTP Server (TLS) id

 15.0.1320.4; Fri, 4 Dec 2020 09:53:07 +0100

Received: from serveurenvoyeur ([MAC]) by

 serveurenvoyeurl ([MAC]) with mapi id

 15.00.1320.000; Fri, 4 Dec 2020 09:53:07 +0100

From: envoyeur
To: receveur

Subject: sujet

Thread-Topic: sujet

Thread-Index: AdbKGseu0/jLe89fRa2Nb7991+OmiA==

Date: Fri, 4 Dec 2020 08:53:06 +0000

Message-ID: <7883aa4c450b4a9bbc0543c83f420991@serveurenvoyeur>

Accept-Language: fr-FR, en-US

Content-Language: fr-FR

X-MS-Has-Attach: yes

X-MS-TNEF-Correlator:

x-ms-exchange-transport-fromentityheader: Hosted

x-originating-ip: IP

x-gfi-smtp-submission: 1

x-gfi-smtp-hellodomain: serveurenvoyeur

x-gfi-smtp-remoteip: IP

Content-Type: multipart/mixed;

        boundary="_009_7883aa4c450b4a9bbc0543c83f420991serveurenvoyeur_"

MIME-Version: 1.0

Dernier fait intéressant, le même interlocuteur a envoyé un message sans pièce jointe le même jour qui a été distribué.
J’ai réalisé un test du domaine de l’envoyeur sur ssl labs, et il se trouve que l’envoyeur ne propose que des ciphers ‘weak’ ou ‘insecure’. Du coup plusieurs question émergent :

  • Quels sont les risques à communiquer avec un cipher ‘weak’ ou ‘insecure’ ?
  • Pourquoi le mail avec PJ est rejeté et le mail sans PJ distribué ?
  • Où trouver un peu de culture générale sur le chiffrement TLS qui soit lisible (même en anglais) ?

Merci d’avance pour vos lumières,
Marin

2

Est_ce que l’expéditeur est sur un domaine très connu et utilisé OU est-ce un tout petit serveur mail ?

Quels sont les risques à communiquer avec un cipher ‘weak’ ou ‘insecure’ ?

Le risque c’est que la communication soit lue et/ou modifiée par un tiers.

Pourquoi le mail avec PJ est rejeté et le mail sans PJ distribué ?

Je ne sais pas

3

Merci pour la réponse !

C’est un serveur mail derrière le nom de domaine d’une moyenne entreprise (courtier en assurance), qui a priori de ce que je comprends des logs a son propre serveur mail.

Donc si je comprends bien, mon serveur en tant que tel ne prend pas de risque de compromission en acceptant la handshake avec ce serveur peut sécurisé ? Et c’est quand même un sacré mystère cette histoire de PJ… Merci en tous cas !

4

Donc soit c’est leur configuration qui pose soucis, soit c’est celle de YunoHost. En l’état, je pense que c’est la leur…

Yunohost suit les recommandations “intermediate” de Mozilla.

Euh en réfléchissant un peu, il y a tout de même le risque de déchiffrer la connexion, et donc de connaître ton mot de passe d’utilisateur YunoHost, ce qui peu aboutir à plein de soucis… Car la config par défaut implique le même niveau de sécurité que ce soit pour les communications avec ton client mail qu’avec les autres serveurs mails.

Dans ce topic tu peux trouver une astuce pour différencier le niveau de chiffrement entre les serveurs versus entre ton client mail et ton serveur. Au cas où tu décides d’autoriser TLS1 et TLS1.1 pour les vieux serveurs mails…

NB: ceci dit comme toujours avec les configs mails, c’est assez complexe, donc à toi de voir ce que tu souhaites vraiment faire.

Tu pourrais aussi écrire un mail à postmaster@ DOMAINE de l’assureur pour entrer en communication avec le gestionnaire de ce serveur pour savoir ce que vous pourriez faire.

5

Super, merci beaucoup pour les infos. Je pense également que c’est leur configuration qui pose problème, ce que confirme https://www.ssllabs.com/ et le fait que c’est mon premier problème de mail rejeté…

Voilà c’était mon gros doute, la compromission éventuelle de mots de passe. Reste à faire les choix en conscience entre “l’universalité” de ma comptabilité et les risques impliqués. Je note aussi la possibilité d’imposer des chiffrements différents entre serveur/client et serveur/serveur ! Dans tous les cas je vais prévenir le postmaster du domaine.
Merci encore et bonne journée,
Marin

6

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.