Journal Pourquoi j'ai été obligé de désactiver TLS dans Postfix

Posté par  . Licence CC By‑SA.
Étiquettes :
20
7
déc.
2020

Hier soir, la tristesse m'a envahie. La tristesse de l'administrateur système, hein, pas celui qui vient de voir un de ses proches succomber au Covid-19. Ça empêche donc de dormir 10 à 15 minutes, et ça permet de faire de l'humour dans un journal.

Reprenons.

Je suis donc en quête de la création d'un espace client patient sur le site d'une clinique locale afin de faire la pré-admission en ligne de l'un de mes enfants en vue d'une intervention chirurgicale programmée. On est donc dans la santé. Petit détail amusant : chaque page de création de compte, y compris le choix d'un mot de passe est verrouillée par un reCaptcha, avec donc la potentialité d'une exfiltration des données. Ahah, je suis déjà tout sourire.

Pour créer un compte, on rentre son nom, son adresse de courriel, et on attend l'arrivée d'un message d'activation sur l'adresse sus-mentionnée. Et là, c'est le drame :

déc. 06 21:53:51 belette64 postfix/smtpd[145475]: connect from smtp.clinique-rivegauche.fr[185.221.88.243]
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: setting up TLS connection from smtp.clinique-rivegauche.fr[185.221.88.243]
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: smtp.clinique-rivegauche.fr[185.221.88.243]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: SSL_accept:before SSL initialization
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: SSL_accept:before SSL initialization
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: SSL3 alert write:fatal:handshake failure
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: SSL_accept:error in error
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: SSL_accept error from smtp.clinique-rivegauche.fr[185.221.88.243]: -1
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2282:
déc. 06 21:53:52 belette64 postfix/smtpd[145475]: lost connection after STARTTLS from smtp.clinique-rivegauche.fr[185.221.88.243]

Oui, je fais du Name'n'Shame, au détriment de ma vie privée. Au passage, techniquement, j'ai dû mettre smtpd_tls_loglevel = 2 pour avoir ce genre de détail.

Et là, dilemme. Je n'ai pas de message d'activation parce que visiblement, le serveur en face tente de faire du SSLv3, et que ça ne va pas marcher. D'ailleurs, il n'y a pas que ça qui est mal configuré.

J'ai évidemment contacté le service qui gère ça, mais en attendant… j'ai… désactivé… TLS.

J'ai mis smtpd_tls_security_level = none.

Et, une fois le message reçu (quand même), je remplis le dossier, et là, surprise ! Il faut attendre la validation de l'espace par les équipes administratives, et je serai prévenu par … courriel ! Donc je ne peux même pas le remettre « comme il faut » tant que je n'aurais pas avancé dans cette étape.

J'ai voulu désactiver TLS uniquement pour certains clients, mais on dirait que ce n'est pas possible. En tout cas, pas facilement.

Question subsidiaire d'une naïveté confondante : me suis-trompé dans mon diagnostic ? Est-ce que c'est bien de la faute du serveur ? C'est la première fois que j'ai ce genre de souci, et le message de postfix n'est pas d'une clarté limpide…

  • # Pas de cipher commun

    Posté par  (site web personnel) . Évalué à 10.

    Le client ne propose que le cipher RC4 que tu n'autorises pas, donc la transaction échoue.
    Autoriser RC4 pourrait être un compromis moins risqué que la désactivation de TLS, par contre ça peut être impossible en fonction de la distro. RC4 a été assez récemment désactivé un peu partout car considéré comme non sûr.

    Ce qui est bizarre c'est que le client ne réessaie pas en clair. Quel était la valeur précédente de smtpd_tls_security_level ? Chez moi c'est configuré à may comme recommandé par la doc Postfix pour autoriser les clients qui ne veulent pas faire du TLS.

    • [^] # Re: Pas de cipher commun

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 07 décembre 2020 à 10:53.

      RC4 a été assez récemment désactivé un peu partout car considéré comme non sûr.

      C'est un peu le problème d’œuf et la poule, tant que X est accepté les gens envoient X sans reconfigurer.
      Le problème ici est peut-être de vouloir être trop "à jour" avant les gros, il faut que d'abord le plus gros client de cet émetteur décide avant que les petits le fasse… Question de poids, oui, mais c'est la vie.

      Bref, des fois il faut savoir ne pas faire plus de sécurité que nécessaire.

      Autoriser RC4 pourrait être un compromis moins risqué que la désactivation de TLS

      Quand on est petit et qu'on ne peut pas forcer l'entité en face, il faut savoir préférer un peu de sécurité à pas du tout :), en effet.

      • [^] # Re: Pas de cipher commun

        Posté par  . Évalué à 7. Dernière modification le 07 décembre 2020 à 11:06.

        Quand on est petit et qu'on ne peut pas forcer l'entité en face, il faut savoir préférer un peu de sécurité à pas du tout :), en effet.

        Vu la plate-forme, je pense que je suis aussi gros qu'eux. C'est juste que là, c'est moi qui a besoin d'eux, et pas l'inverse.

        C'est le premier serveur que je vois qui échoue comme ça.

      • [^] # Re: Pas de cipher commun

        Posté par  . Évalué à 4. Dernière modification le 08 décembre 2020 à 00:07.

        Du coup, cela me conduit à me poser une question:

        Est-ce qu'il existe un soft qui taggerait les mails en fonction du protocole utilisé?
        Genre: "Attention, ce mail peut venir d'une source peu sure!"

    • [^] # Re: Pas de cipher commun

      Posté par  . Évalué à 8.

      J'étais à may oui, je ne force pas le TLS, d'ailleurs, c'est normalement interdit par la RFC (selon la doc de Postfix, je ne suis pas allé vérifier).

      C'est bizarre aussi qu'il ne réessaye pas en clair, mais vu la configuration du certificat X.509, on dirait que personne n'est allé plus loin que le template.

  • # Solution : un deuxième smtpd avec NAT

    Posté par  . Évalué à 10.

    Donc, voilà ma solution.

    • Repasser smtpd_tls_security_level = may dans main.cf
    • Ajouter un service dans master.cf :
    10025   inet    n       -       y       -       -       smtpd
  -o smtpd_tls_security_level=none
    • Ajouter une règle de pare-feu pour rediriger le trafic en direction du port 25 vers le port 10025 seulement pour les hôtes spécifiés :
    table ip nat {
    # […] Autres chaînes

    chain PREROUTING {
        type nat hook prerouting priority dstnat; policy accept;
        tcp dport 25 ip protocol tcp ip saddr { 185.221.88.243 } redirect to :10025
    }
}

    Je ne le mets pas ici, mais il faut également lister le port 10025 dans la liste des ports acceptés en entrée, sinon, ça ne marche pas.

    Voilà, c'est crade, et ça marche : ma journée de sysadmin est validée !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.