Forum Linux.général TLS et Postfix

Posté par  . Licence CC By‑SA.
Étiquettes :
6
27
sept.
2020

Bonjour à tous,

j'ai mis en place un petit serveur mail auto-hébergé fonctionnel en utilisant postfix et dovecot et me demande comment sécuriser correctement la connexion entre le client (moi) et le serveur et entre les différents MTA.

J'ai cru comprendre que la directive "smtp_tls_security_level = may" (entre autres) permet d'activer un mode chiffrement opportuniste nommé STARTTLS et donc que ce dernier est vulnérable aux attaques en MITM.

J'ai donc quelques questions qui me viennent naturellement à l'esprit:

  • Est-il possible de ne pas utiliser STARTTLS avec "smtp_tls_security_level = enforce", par exemple ?

  • Est-il raisonnable d'interdire la communication avec des serveurs n'utilisant pas le chiffrement, sachant qu'ils sont peu nombreux ?

  • Faut-il autoriser l'utilisation d'algorithmes cryptographiques obsolètes, pour garantir une compatibilité optimale ?

Je me doute bien qu'il est possible que mes mails transitent en clair entre deux MTA sur lesquels je n'ai aucun contrôle mais je souhaite au moins pouvoir garantir le chiffrement entre mon serveur smtp et le MTA suivant ainsi qu'entre mon MUA et mon serveur mail.

J'aimerais vraiment être certain de pouvoir recevoir mes mails avec une configuration optimale sans avoir à négliger la sécurité, mais est-ce seulement possible ?

Merci d'avance pour vos réponses !

  • # No subject

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

    J'ai cru comprendre que la directive "smtp_tls_security_level = may" (entre autres) permet d'activer un mode chiffrement opportuniste nommé STARTTLS et donc que ce dernier est vulnérable aux attaques en MITM.

    Plus précisément, le niveau may implique les deux comportements suivants :

    • ton serveur demande au serveur d’en face que la communication soit chiffrée, mais accepte d’envoyer le mail en clair si le serveur d’en face ne propose pas le chiffrement (ou si un attaquant actif supprime l’option STARTTLS en chemin) ;
    • même si la communication est chiffrée, ton serveur ne vérifiera pas la validité du certificat d’en face.

    Est-il possible de ne pas utiliser STARTTLS avec "smtp_tls_security_level = enforce", par exemple ?

    Comment ça, ne pas utiliser STARTTLS ? A priori tu veux forcer l’utilisation de STARTTLS, au contraire…

    Pour rendre le chiffrement obligatoire, tu peux en principe (mais voir la question suivante d’abord) utiliser smtp_tls_security_level = encrypt. La différence par rapport au niveau inférieur may est qu’à ce niveau, ton serveur coupera court à la communication si le serveur d’en face n’utilise pas TLS (que ce soit parce qu’il ne supporte pas le chiffrement ou parce qu’un attaquant a supprimé l’option STARTTLS en chemin).

    Est-il raisonnable d'interdire la communication avec des serveurs n'utilisant pas le chiffrement, sachant qu'ils sont peu nombreux ?

    Peu nombreux, peu nombreux… la dernière fois que j’ai analysé les logs de mon serveur pour voir l’utilisation du chiffrement, il y avait encore environ 15% de serveurs qui n’acceptaient que des communications en clair. Pour moi c’est encore beaucoup trop pour que je sois confortable avec l’idée d’interdire toute connexion en clair.

    Faut-il autoriser l'utilisation d'algorithmes cryptographiques obsolètes, pour garantir une compatibilité optimale ?

    Il y a quelques années j’aurais dit « oui », en partant du principe qu’une communication chiffrée avec un algorithme obsolète est toujours mieux qu’une communication en clair.

    Je n’en suis plus si sûr aujourd’hui. Toujours d’après les logs de mon serveur, il semble que les serveurs mails dans la nature se répartissent désormais en deux grandes catégories :

    • ceux qui supportent le chiffrement : ceux-là supportent les dernières versions de TLS (1.2, 1.3) et les algorithmes les plus modernes ;
    • ceux qui ne supportent pas du tout le chiffrement.

    Concrètement, contrairement à ce qui se passait il y a encore deux ou trois ans, je ne vois plus dans mes logs aucune trace de serveurs « intermédiaires », qui supporteraient le chiffrement mais n’offreraient que des versions dépassées de TLS (SSLv3, TLS 1.0, TLS 1.1) et/ou que des algorithmes « faibles . C’est bien sûr à pondérer avec le fait qu’il ne s’agit que de ce que voit mon serveur (je ne prétends pas que c’est représentatif de tout le paysage des serveurs mails), mais je ne pense pas qu’on perde beaucoup aujourd’hui à refuser de supporter des protocoles et algorithmes dépassés.

    • [^] # Re: No subject

      Posté par  . Évalué à 1.

      Merci bien pour cette réponse claire et précise !
      C'était bien de l'option "encrypt" dont je voulais parler, j'ai écrit mon texte à l'aide de mes souvenirs approximatifs de la doc :(
      Donc STARTTLS permet également de faire du chiffrement non opportuniste. Je pensais le contraire, qu'il s'agissait d'une autre option.
      Si j'utilise l'option "encrypt" (et prend le risque de ne pas pouvoir communiquer avec certains serveurs), il n'y a donc plus vraiment de risques de me faire intercepter mes mails facilement.
      Google (désolé) publie des statistiques sur le sujet (lien) et les serveurs smtp qui n'ont pas activé STARTTLS semblent vraiment rares (cela ne dit rien sur les protocoles utilisés).

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4. Dernière modification le 28 septembre 2020 à 15:00.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: No subject

          Posté par  . Évalué à 1. Dernière modification le 28 septembre 2020 à 15:23.

          Du coup, quelle serait la limite acceptable pour forcer le chiffrement, 1%, 2% ?
          Je trouve vraiment dommage, qu'en 2020, le chiffrement ne soit pas obligatoire et déployé universellement sur les serveurs smtp.
          Sinon j'ai également vu ces directives apparaître lors de mes recherches sur le sujet. Ça a l'air vraiment bien, merci.
          Je me demande combien de domaines utilisent l'enregistrement TLSA et DNSSEC…
          J'ai une dernière question, pourquoi Thunderbird différencie SSL/TLS de STARTTLS dans les options qui me permettent de me connecter à mon serveur (vu que STARTTLS est toujours utilisé) ?

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 5.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: No subject

              Posté par  (site web personnel) . Évalué à 7. Dernière modification le 28 septembre 2020 à 16:47.

              Edit: Ah zut, j’ai répondu au mauvais commentaire ><, désolé, c’est une réponse au commentaire grand-parent…

              Du coup, quelle serait la limite acceptable pour forcer le chiffrement, 1%, 2% ?

              Ça dépend de plusieurs choses. Déjà, s’agit-il d’un serveur perso dont tu es le seul utilisateur, ou fournis-tu un service pour d’autres utilisateurs (à la manière d’un CHATON par exemple) ?

              Si tu es le seul utilisateur, es-tu prêt à accepter que 1% de tes mails n’arrivent pas à leurs destinataires parce que les serveurs desdits destinataire n’acceptent pas le chiffrement ? Sachant que dans ce 1% tu pourrais très bien avoir un mail destiné à ton banquier, au propriétaire de ton logement, à l’entreprise à laquelle tu envoies un CV, etc…

              Si tu as d’autres utilisateurs en plus de toi-même, es-tu prêt à répondre aux utilisateurs qui se plaignent d’avoir des mails qui n’arrivent pas que c’est normal, tu as consciemment fait le choix de rendre le chiffrement obligatoire et que c’est le problème des autres serveurs qui ne supportent pas le chiffrement ?

              Je me demande combien de domaines utilisent l'enregistrement TLSA et DNSSEC…

              Au 31 août 2020, 2 151 862 domaines supportent TLSA.

              J'ai une dernière question, pourquoi Thunderbird différencie SSL/TLS de STARTTLS dans les options qui me permettent de me connecter à mon serveur (vu que STARTTLS est toujours utilisé) ?

              Pour la connexion entre un MUA (comme Thunderbird) et un serveur (par opposition aux connexions de serveur à serveur), il y a toujours deux options :

              • une connexion chiffrée dès le départ sur un port dédié (typiquement 465 au lieu de 25 pour SMTP, 993 au lieu de 143 pour IMAP) ;
              • une connexion établie initialement en clair sur le port standard, qui bascule en mode chiffré lorsque les deux parties se mettent d’accord pour ça (via une commande interne au protocole, qui dans le cas des protocoles SMTP et IMAP s’appelle STARTTLS).

              Formellement, le premier mode est appelé « TLS implicite », parce que l’utilisation de TLS est implicitement requise par le simple fait d’établir une connexion sur le port dédié aux connexions TLS ; le second mode, par opposition, est dit « explicite », parce que l’utilisation de TLS est explicitement négociée une fois la connexion initiale établie.

              Mais ces appellations de « TLS implicite » et « TLS explicite » sont assez récentes (à ma connaissance c’est le RFC 8314 qui les a formalisées pour la première fois), pendant longtemps les serveurs et les clients ont utilisé diverses appellations plus ou moins heureuses¹ pour désigner les deux modes.

              Dans le cas de Thunderbird, SSL/TLS désigne le mode implicite, STARTTLS désigne le mode explicite.

              ¹ Les moins heureuses de ces appellations étant SSL pour désigner le mode implicite et TLS pour désigner le mode explicite, alors que ça n’a rien à voir…

              • [^] # Re: No subject

                Posté par  . Évalué à 1.

                Encore merci à vous, je pense avoir tout compris.
                Mon serveur est un serveur perso, mais le fait de ne pas pouvoir recevoir certains mails importants m'effraie donc je vais activer le mode opportuniste et également utiliser dane.

                • [^] # Re: No subject

                  Posté par  . Évalué à 5.

                  Je l’ai vu précisé nul part donc je voulais juste rappeler que Postfix est segmenté en plusieurs services qui gèrent des chose différentes. Notamment dans le cas qui te concerne, tu as le service smtp qui gère l’envoie de courriels et qui est configuré par les directives commençants par smtp_ et le service smtpd qui gère la réception des courriels et qui est configuré par les directives commençants par smtpd_.

                  Par exemple :

                  smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

                  Configure Postfix pour utiliser DANE lors de l’envoi d’un courriel.

                  De même que :

                  smtpd_use_tls = true

                  Configure Postfix pour annoncer le support de STARTTLS lors de la réception d’un courriel.

                  • [^] # Re: No subject

                    Posté par  . Évalué à 1.

                    Je suis au courant de cette segmentation et j'ai un peu fait la même chose dans ma configuration.

                    Trafic entrant:

                    smtpd_tls_security_level = may
                    smtpd_tls_auth_only = yes

                    Trafic sortant:

                    smtp_dns_support_level = dnssec
                    smtp_tls_security_level = dane

                    J'ai également exclu SSLv2, SSLv3, TLSv1 et TLSv1.1 pour les deux catégories.

                    • [^] # Re: No subject

                      Posté par  . Évalué à 1. Dernière modification le 03 octobre 2020 à 03:06.

                      Hormis les considérations entre MTA évoquées plus haut*, ta question portait initialement sur la communication entre MUA et MTA/MDA. Que je sache, il n'y a aucune différence entre TLS et STARTLS en ce qui concerne la possibilité d'un MITM (et vouloir s'en prémunir me semble vain, voir de nouveau*) et il te faudra configurer correctement les 2 côtés, c'est-à dire imposer (START)TLS et contrôler le certificat côté client (=> éviter de se reposer sur une CA externe pour les plus paranos).

                      Le plus important reste que ton MTA/MDA n'accepte que le mails destinés à lui où émis par un utilisateur duement "authentifié". Dans ce cas, (START)TLS permet simplement de savoir que tu parles à ton serveur, je n'y vois pas d'autre avantage. Techniquement on peut s'authentifier en "clair" de manière sécure, juste que sans certificat tu ne sais pas à qui tu parles… Ce qui n'est pas spécialement un problème, voir *.

                      *: personnellement il me semble absurde d'exiger que la communication entre ton MTA et le next-hop soit chiffrée sans avoir aucune garantie sur la suite du parcours… utiliser pgp pour la confidentialité/intégralité!

                      • [^] # Re: No subject

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

                        Que je sache, il n'y a aucune différence entre TLS et STARTLS en ce qui concerne la possibilité d'un MITM

                        Si par « TLS » et « STARTTLS » tu parles de TLS implicite et explicite comme décrit plus haut :

                        Sans vérification du certificat, aussi bien le TLS implicite que le TLS explicite sont vulnérables à une « vraie » attaque MITM (où l’attaquant se fait passer pour la partie d’en face), mais seul le TLS explicite est vulnérable au STARTTLS stripping.

                        En TLS explicite, l’attaquant peut forcer les deux parties à communiquer en clair simplement en retirant l’option STARTTLS (TLS stripping), sans même avoir à jouer le rôle d’un véritable « homme du milieu » (donc sans jamais avoir besoin d’un faux certificat). C’est impossible en TLS implicite.

                        Certes, même en TLS explicite tu peux configurer le client et/ou le serveur pour rendre TLS obligatoire (i.e. refuser de continuer la communication si l’option STARTTLS est absente), mais dans ce cas l’attaque par TLS stripping se transforme en déni de service (en retirant l’option, l’attaquant force les deux parties à abandonner la communication).

                        il me semble absurde d'exiger que la communication entre ton MTA et le next-hop soit chiffrée sans avoir aucune garantie sur la suite du parcours

                        Rappel : OpenPGP ne protège que le corps du message, pas toutes les métadonnées associées. Il est toujours absolument pertinent de chercher autant que possible à utiliser SMTP sur TLS (chiffrement point à point des métadonnées) même si le corps est déjà chiffré en mode « end-to-end » avec OpenPGP.

                        • [^] # Re: No subject

                          Posté par  . Évalué à 1. Dernière modification le 03 octobre 2020 à 16:53.

                          En TLS explicite, l’attaquant peut forcer les deux parties à communiquer en clair simplement

                          C'est pour ca que j'ai appuyé sur le fait que le client doit être aussi correctement configuré, tant sur le choix de l'option tls que sur la vérification de CA. Donc non, pas possible de forcer le downgrade (ou alors il y a un bug dans le client), c'est orthogonal à STARTTLS vs TLS… (nb: certaines version de TLS sont aussi succeptible à des "downgrades"-attack). Si j'ai coché "starttls" dans la config de mon client, qu'on appelle ça explicite ou implicite*, il n'est pas sensé basculer en plain-text.

                          TLS stripping se transforme en déni de service

                          Si tu as un MITM, ce sera sans doute là la cause de ton déni de service. TLS ou startls ne sont pas plus immunisés l'un que l'autre. À nouveau, le TLS stripping n'est pas possible si le client est correctement configuré/implémenté.

                          OpenPGP ne protège que le corps du message, pas toutes les métadonnées associées.

                          toutafé, il ne protège pas l'envelloppe. de ce point de vue là, tls leak "juste" l'addresse ip, ce qui peut donner pas mal d'info aussi…

                          Que penses-tu de mon argument de ne pas avoir de certitude quant à la suite du chemin ? N'as tu pas peur de te reposer sur un faux-sentiment de sécurité ?

                          *: ceci est une boutade, pas la peine de me dire que j'ai rien compris à la rfc :p

                          • [^] # Re: No subject

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

                            C'est pour ca que j'ai appuyé sur le fait que le client doit être aussi correctement configuré […] Donc non, pas possible de forcer le downgrade (ou alors il y a un bug dans le client

                            Donc tu te reposes sur le fait que tous tes clients sont 1) correctement configués et 2) non-buggés. C’est assez osé à mon sens comme pré-requis.

                            En TLS explicite, continuer la communication en clair si aucune des parties ne voit l’option STARTTLS est un comportement assez courant (et pour cause, c’est le comportement par défaut : la communication est d’abord en clair, et seulement éventuellement bascule en chiffré), je ne ferais pas confiance aux clients pour ne pas adopter ce comportement. À l’inverse, en TLS explicite, je ne connais aucun client qui bascule silencieusement vers le port non-chiffré si la connexion au port chiffré échoue.

                            Si j'ai coché "starttls" dans la config de mon client, qu'on appelle ça explicite ou implicite*, il n'est pas sensé basculer en plain-text.

                            Et pourtant en TLS implicite, ça arrive. « Mauvais client, changer de client », peut-être, mais en attendant, si j’ai un moyen en tant qu’administrateur de forcer le chiffrement sans compter sur le bon vouloir ou le bon comportement du client, je le fais.

                            Que penses-tu de mon argument de ne pas avoir de certitude quant à la suite du chemin ? N'as tu pas peur de te reposer sur un faux-sentiment de sécurité ?

                            L’argument du « je ne contrôle pas ce qui se passe en dehors de chez moi alors ça sert à rien que je me casse le cul à faire attention chez moi » ? Euh, pas grand’chose de bien, pourquoi ?

                            Ceci est absurde comme argument, le starttls stripping n'apporte rien si l'attaquant est déjà en position d'impersonniser le serveur.

                            D’une, je pense que retirer une simple option lors de l’établissement de la connexion SMTP, c’est quand même plus simple que « d’impersonniser un serveur ». Justement le STARTTLS stripping dispense l’attaquant de devoir monter un vrai MITM. Rendre le STARTLS stripping impossible complique la tâche de l’attaquant qui n’a dès lors plus le choix, il doit faire un vrai MITM.

                            De deux, très fréquemment le STARTTLS stripping est le fait d’un opérateur réseau pour qui ce genre de manipulation sur les paquets qu’il achemine est extrêmement facile. De nombreux fournisseurs d’accès sont connus pour ce genre de pratiques appliquées à grande échelle contre tous leurs abonnés. Pourquoi leur faciliter la tâche ?

                            • [^] # Re: No subject

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

                              Ouh, je me suis mélangé les pinceaux à deux reprises entre TLS implicite et explicite, sorry about that …

                              s/À l’inverse, en TLS explicite, je ne connais aucun client/À l’inverse, en TLS implicite, je ne connais aucun client/
s/Et pourtant en TLS implicite, ça arrive/et pourtant en TLS explicite, ça arrive/

                            • [^] # Re: No subject

                              Posté par  . Évalué à 1.

                              Donc tu te reposes sur le fait que tous tes clients sont 1) correctement configués et 2) non-buggés. C’est assez osé à mon sens comme pré-requis.

                              Ben oui malheureusement il n'est pas possible de faire autrement, c'est ce que j'essaye de dire depuis le début: il est impossible de se prémunir d'un MITM si le client ne vérifie pas le certificat. Mais pas la peine de paniquer, c'est ce que font les client sérieux depuis plus 15 ans…

                              Deusio je n'ai jamais dit qu'on ne pouvait pas forcer un canal sécurisé côté serveur, mais ça n'a rien à voir avec STARTTLS ou pas. voir ci dessous

                              L’argument du « je ne contrôle pas ce qui se passe en dehors de chez moi alors ça sert à rien que je me casse le cul à faire attention chez moi »

                              Ca s'appelle un reality check. mettre une porte blindé sur une cabane en bois, je ne trouve pas cela très productif :)

                              C'est d'autant plus amusant de venir me reprocher cela alors que tu souhaites vouloir ignorer le problème de la configuration du client :D

                              Je pense que s'assurer que le client en bien configuré ou a le bon comportement est plus nécessaire: pour continuer mon analogie, vérifier le certificat équivaudrait à monter des murs en brique sur sa cabane.

                              Justement le STARTTLS stripping dispense l’attaquant de devoir monter un vrai MITM. Rendre le STARTLS stripping impossible complique la tâche de l’attaquant qui n’a dès lors plus le choix, il doit faire un vrai MITM.

                              Ca ne sert à rien de répéter cet argument pour le rendre vrai. Il suffit d'empêcher le relais pour les users non authentifiés et forcer l'authentification sur un canal sécurisé (comme je l'avais indiqué dans mon premier commentaire déjà). Point.

                              Voir http://www.postfix.org/SASL_README.html#server_sasl_enable

                              To offer SASL authentication only after a TLS-encrypted session has been established specify this:

/etc/postfix/main.cf:
    smtpd_tls_auth_only = yes

                        • [^] # Re: No subject

                          Posté par  . Évalué à 1.

                          Désolé, je reposte pour compléter un peu.

                          Sans vérification du certificat […] seul le TLS explicite est vulnérable au STARTTLS stripping.

                          Ceci est absurde comme argument, le starttls stripping n'apporte rien si l'attaquant est déjà en position d'impersonniser le serveur.

                          Au lieu de dire que "TLS imlicite est mieux" (c'est faux), il faut dire "il faut vérifier la CA" et imposer le chiffrement côté client. Notons aussi que certains clients n'ont pas d'option STARTLS ou TLS/SSL, simplement SSL qui veut dire n'importe lequel du moment que c'est chiffré, ce qui est un comportement raisonnable et sécurisé.

                          • [^] # Re: No subject

                            Posté par  . Évalué à 1.

                            nitpick: s/il faut vérifier la CA/il faut vérifier le certificat/

Suivre le flux des commentaires

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