Journal Tout le monde a bien activé TLS sur ses serveurs SMTP ?

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
34
20
fév.
2014

Parce que cela va être obligatoire en France, a annoncé le premier ministre aujourd'hui (dans un premier temps, uniquement pour les services de l'État et pour les FAI). Donc, pour aider les bons français à suivre ces excellentes directives, je suggère de mettre dans les commentaires des liens vers les meilleurs tutoriels sur la configuration et le test (toujours oublié, le test) de TLS sur Postfix, exim, etc.

Merci de ne mettre que des tutoriels récents (en deux coups de Google, on en trouve des tas de vieux qui ne sont plus d'actualité), bien écrits et bien expliqués (c'est là où LinuxFr a une valeur ajoutée : autrement, il suffirait de taper "MON_MTA_FAVORI SMTP TLS" sur Google).

  • # Flou

    Posté par  (site web personnel) . Évalué à 7. Dernière modification le 20 février 2014 à 17:24.

    C'est assez flou comme souhait, mais j'ai l'impression qu'il demande plutôt qu'on utilise LUKS pour chiffrer /var/mail, ce qui n'est pas ce qui se fait de plus pratique — puisqu'il faut alors saisir un mot de passe ou équivalent au démarrage du serveur — ni de plus utile en matière de sécurité, puisque ça ne protège que d'une chose : l'accès aux données par saisie physique du serveur. En particulier, ça n'offre aucune protection contre les attaques effectuées depuis le réseau vers le serveur en fonctionnement.

    • [^] # Re: Flou

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

      Ah, je ne prétends pas être capable de lire la pensée du gouvernement :-) Comme le projet de Merkel d'un Internet européen, c'est en effet le plus grand flou.

  • # Bonne idée

    Posté par  . Évalué à 4. Dernière modification le 20 février 2014 à 17:30.

    Je trouve que c'est une bonne idée. Moi chez Merdicable il n'y a de chiffrement ni pour POP ni pour IMAP ni pour SMTP \o/, je crois que c'est le seul FAI dans ce cas, les autres ont au moins du chiffrement pour POP (mais des fois pas pour IMAP, comme chez Bouhïgue)

    • [^] # Re: Bonne idée

      Posté par  . Évalué à 2.

      Le fournisseur d'adresses e-mail laposte.net n'a également aucun chiffrement possible.

      • [^] # Re: Bonne idée

        Posté par  . Évalué à 3.

        T'es sûr ?

        Sur http://www.arobase.org/gratuit/comparatif.htm je vois que SSL est coché.

        J'ai un mail à laposte.net je vérifierai ce soir mais ça tu m'étonnes un peu.

        Si je me fie à la réponse sur http://www.commentcamarche.net/forum/affich-27758322-configurer-compte-laposte-net-dans-courrier-windows8 c'est pareil.

        • [^] # Re: Bonne idée

          Posté par  . Évalué à 2.

          Oui je suis sûr, du moins je parle du smtp. Comparer :

          laposte.net (pas de TLS)
          $ msmtp --serverinfo --tls --tls-certcheck=off --host smtp.laposte.net
          msmtp: the server does not support TLS via the STARTTLS command

          Gandi (TLS activé)
          $ msmtp --serverinfo --tls --tls-certcheck=off --host smtp.gandi.net
          SMTP server at smtp.gandi.net (mail4.gandi.net [217.70.183.210]), port 25:
          mail4.gandi.net ESMTP Postfix
          TLS certificate information:
          Owner:
          Common Name: pop.gandi.net
          Organizational unit: Domain Control Validated
          Issuer:
          Common Name: Gandi Standard SSL CA
          Organization: GANDI SAS
          Country: FR
          Validity:
          Activation time: mer. 17 avril 2013 01:00:00 WEST
          Expiration time: sam. 18 avril 2015 00:59:59 WEST
          Fingerprints:
          SHA1: 9F:8D:E4:E4:89:A9:30:25:90:41:CE:72:C5:C9:ED:E8:55:93:3D:2C
          MD5: 08:9D:F3:AB:8C:82:CB:D2:AC:01:F9:9C:E9:7E:DB:DD
          Capabilities:
          SIZE 100000000:
          Maximum message size is 100000000 bytes = 95,37 MiB
          PIPELINING:
          Support for command grouping for faster transmission
          ETRN:
          Support for RMQS (Remote Message Queue Starting)
          DSN:
          Support for Delivery Status Notifications
          STARTTLS:
          Support for TLS encryption via the STARTTLS command
          AUTH:
          Supported authentication methods:
          PLAIN LOGIN

          • [^] # Re: Bonne idée

            Posté par  . Évalué à 6. Dernière modification le 20 février 2014 à 22:29.

            laposte.net (pas de TLS)

            msmtp se plaint juste de l'absence de STARTTLS. Tu peux avoir du TLS sans ça, à tester avec :

            $ msmtp --serverinfo --host=smtp.laposte.net --tls=on --tls-starttls=off --tls-certcheck=off
SMTP server at smtp.laposte.net (smtp.laposte.net [193.251.214.114]), port 465:
    mwinf8508-out ME ESMTP server ready
TLS certificate information:
    Owner:
        Common Name: smtp.laposte.net
        Organization: LA POSTE - DIR DU COURRIER
        Organizational unit: 0002 35600000000295
        Locality: Paris
        State or Province: France
        Country: FR
    Issuer:
        Common Name: AC CERTINOMIS SSL
        Organization: CERTINOMIS
        Country: FR
    Validity:
        Activation time: Fri Aug 30 10:04:51 2013
        Expiration time: Sat Aug 30 10:04:51 2014
    Fingerprints:
        SHA1: AF:ED:D6:3D:8F:18:DF:5C:07:19:14:A0:BC:6B:97:1E:98:6C:77:FB
        MD5:  54:32:B3:38:80:DB:72:D6:72:8F:C4:1E:1A:8B:8C:DC
Capabilities:
    SIZE 44000000:
        Maximum message size is 44000000 bytes = 41.96 MiB
    AUTH:
        Supported authentication methods:
        PLAIN LOGIN

            • [^] # Re: Bonne idée

              Posté par  . Évalué à 2.

              Merci beaucoup, j'avais pas remarqué cette option !

      • [^] # Re: Bonne idée

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 20 février 2014 à 18:03.

        Ça fait quelques années que l'IMAP et le SMTP peuvent être chiffrés, mais c'est vrai que ça a mis du temps à arriver.

    • [^] # Re: Bonne idée

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

      Chez Mandarine j'avais constaté un truc encore plus marrant : leur webmail était disponible en chiffré, sur https://webmail.mandarine.fr/ , en revanche, le temps de l'identification on était redirigé vers une page en clair, avant de retourner vers le webmail chiffré. :-D

      • [^] # Re: Bonne idée

        Posté par  . Évalué à 3.

        Leur portail d'auth est en http mais les requêtes d'authentification se font en https. Un tcpdump ou *shark devrait pouvoir t'en convaincre. Ceci dit, l'intérêt de faire ça reste un mystère.
        Par contre je n'arrive pas à voir correctement leur webmail en https, sans doute parce que dans ce mode toutes les css sont référencées en http. À peu près inutilisable donc …

        • [^] # Re: Bonne idée

          Posté par  . Évalué à 10.

          Et donc un attaquant actif peut changer la page de login qui est en http, et rediriger la requête qui contient les identifiants vers un serveur à lui.
          https n'est pas seulement utile pour les requêtes contenant des données sensibles, mais toutes celles avant aussi…

  • # Lapin compris

    Posté par  . Évalué à 2.

    D'après l'article de 01.net :

    Actuellement, l’accès aux messageries telles que Gmail et Yahoo! sont déjà cryptées en SSL, d’où l’apparition d’un petit cadenas au niveau du navigateur. Cela signifie que le message qui circule entre le terminal de l’utilisateur et le serveur de messagerie est chiffré. C’est le cas de la plupart de messagerie, mais pas toutes. La messagerie laposte.net, « qui concerne des millions de nos concitoyens », ne propose pas cette protection.

    Ça, d'accord. C'est fait presque partout.

    Un second niveau de chiffrement est envisageable au niveau des serveurs, avec l’activation du protocole TLS. Dans ce cas, le message est également chiffré lorsqu’il circule d’un serveur à l’autre.

    Je ne comprends pas. On parle d'authentifier/chiffrer entre le client (IMAP/POP/SMTP) et le serveur (paragraphe 1), ou bien sur tout la chaîne de transmission du message de serveur à serveur (paragraphe 2) ?

    Si 2, ça veut dire

    • que les serveurs qui apparaissent dans les en-têtes

      Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169])

    ne peuvent pas lire le contenu ? Il faut pas du GnuPG ou équivalent, pour ça ?

    • que la connexion entre ces serveurs est sécurisée ? Je m'étais jamais posée la question. C'est de ça, qu'on parle ?

    Au passage, l'aide de Postfix pour TLS : http://www.postfix.org/TLS_README.html

    Ça devrait répondre à ma question, mais TL;DR et le schéma introductif ne m'a pas sauvé.

    • [^] # Re: Lapin compris

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Moi, j'ai compris (mais je ne suis pas sûr qu'Ayrault ait compris ce qu'il demandait) qu'il fallait en effet chiffrer en TLS entre serveurs (RFC 3207). D'où le titre de mon journal.

      • [^] # Re: Lapin compris

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

        mais je ne suis pas sûr qu'Ayrault ait compris ce qu'il demandait

        Pour le coup, je suis sûr qu'il n'a pas compris, parce que c'est dit de façon trop floue pour être issu de quelqu'un qui sait de quoi il parle.

        • [^] # Re: Lapin compris

          Posté par  . Évalué à 10.

          Vous êtes de mauvaise foi, moi ça me paraît très clair. Il a demandé à ce que les offres de messagerie électronique (et non la messagerie elle-même, c’est-à-dire les messages ou les communications permettant de transporter ces messages) soient chiffrées.

          Du coup, voici mon offre chiffrée :

          Abonnement au service : 10,00 € / an
          Envoi d’un message : 0,10 €
          Stockage d’un message reçu : 0,10 € / jour

          Voilà, c’était quand même pas difficile à comprendre, non ?

          → []

          • [^] # Re: Lapin compris

            Posté par  . Évalué à 10.

            Ce n'est pas une offre chiffré, c'est tout à fait lisible. Voilà une offre chiffrée :

            Nobaarzrag nh freivpr : 10,00 € / na

            Raibv q’ha zrffntr : 0,10 €

            Fgbpxntr q’ha zrffntr erçh : 0,10 € / wbhe

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Lapin compris

          Posté par  . Évalué à 3.

          Oui, certes. C'est assez logique qu'il comprenne pas, c'est pas son boulot. L'essentiel étant que ceux qui ont décidé/proposé ont compris. J'ose croire que oui.

          Il vaudrait mieux qu'on (les journalistes, nous) commente un truc clair écrit qu'un discours oral qui a pas vocation à avoir ce degré de précision mais à donner les grandes lignes. (Je précise que j'ai pas écouté le discours. S'il s'enferme dans des pseudo-explications, c'est pas malin.)

          Je sais pas si j'ai activé ça sur mon serveur. J'imagine que non. C'est une installation Postfix Debian sur laquelle j'ai pas modifié grand chose. J'ai quand même ajouté l'authentification SMTP.

          • [^] # Re: Lapin compris

            Posté par  (site web personnel, Mastodon) . Évalué à 5.

            Dans le journal, j'ai donné l'URL du texte écrit (pas un discours) du gouvernement.

            • [^] # Re: Lapin compris

              Posté par  . Évalué à 2.

              Oui, j'ai lu en diag, et il y a une vidéo du discours.

              C'est un peu court, ce texte, je ne vois pas de détails sur ce dont on parle, mais ça doit faire référence à des choses plus détaillées. Choses peut-être pas encore définitives, gravées dans le marbre, et publiques mais ça tombe pas du ciel, ça a du être inspiré par des gens plus qualifiés que le premier ministre (qui s'y connait déjà vachement en trafic aérien, on peut pas être bon en tout).

      • [^] # Re: Lapin compris

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 20 février 2014 à 18:02.

        Moi, j'ai compris […] qu'il fallait en effet chiffrer en TLS entre serveurs

        Sur 01net :

        le chef du gouvernement souhaite « que les offres nationales de messagerie électronique soient chiffrées par leurs fournisseurs et que les messages soient traités par des infrastructures situées sur le territoire national »

        Tu crois vraiment que J-M Ayrault a la moindre idée de ce qu'est le chiffrement des e-mails et qu'il s'est posé la question de la différence entre chiffrement de bout en bout ou de point à point ?

        • Il faut réagir publiquement et activement à ce que fait la NSA.
        • OK, qu'est-ce qu'on fait, on propose l'asile à Snowden ?
        • Non, t'as rien compris, il faut ne pas agir tout en ayant l'air d'agir.
        • On pourrait proposer la protection des données des utilisateurs.
        • Ouais, bonne idée, on va proposer de crypter les messages sur le territoire par les fournisseurs, un truc national pour contrer les États-Unis.
        • Et techniquem…
        • On s'en fout !

        blog.rom1v.com

    • [^] # Re: Lapin compris

      Posté par  . Évalué à 5.

      que la connexion entre ces serveurs est sécurisée ? Je m'étais jamais posée la question. C'est de ça, qu'on parle ?

      C'est de ça, et pour tester : http://www.checktls.com/

      J'ai pas attendu le gouvernement pour sécuriser serveurs de submission ,d'envoi et mx. Maintenant ce qui me ferait tripper c'est un backend dovecot à chiffrement asymétrique, quand il reçoit un mail celui-ci est chiffré avec la clé publique du destinataire, et quand celui-ci se connecte, son mot de passe déverrouille sa clé privée et lui permet d’accéder aux messages.

      Ça permettrait de sécuriser l'access au compte bien plus efficacement qu'un chiffrement au niveau de la partition !

      • [^] # Re: Lapin compris

        Posté par  . Évalué à 2.

        C'est de ça, et pour tester : http://www.checktls.com/

        Ah. Merci pour le lien. Avec mon install Postfix Debian par défaut, j'ai le test "Address" qui passe (à part le warning certificat auto-signé).

        • [^] # Re: Lapin compris

          Posté par  . Évalué à 3. Dernière modification le 20 février 2014 à 19:23.

          Le test pour le chiffrement inter-serveurs c'est "sender"

          Remarque aucun besoin de posséder un certificat SSL pour cette partie-là, on est un client smtp qui se connecte à un mx, c'est au mx de présenter un certificat.

          C'est la différence entre les options smtpd_* de postfix qui s’appliquent au serveurs SMTP (qui écoutent sur les port 25, 587…) et les options smtp_* qui s’appliquent aux clients utilisés pour envoyer ou relayer les mails.

          • [^] # Re: Lapin compris

            Posté par  . Évalué à 2.

            Le test pour le chiffrement inter-serveurs c'est "sender"

            Ah. Je me disais bien que c'était pas logique.

            Et en effet, ce test-là échoue.

            Your email was sent, however it was NOT SENT SECURELY using TLS.

            Merci pour les précisions.

            • [^] # Re: Lapin compris

              Posté par  . Évalué à 3. Dernière modification le 21 février 2014 à 19:50.

              Exemple de config pour postfix sous Debian :

              smtp_tls_security_level            = may
smtp_tls_CApath                    = /etc/ssl/certs/
smtp_tls_session_cache_database    = btree:${data_directory}/smtp_scache
smtp_tls_session_cache_timeout     = 3600s
smtp_tls_loglevel                  = 0

              Résultat : Your email was successfully sent securely using TLS.

              • [^] # Re: Lapin compris

                Posté par  . Évalué à 2.

                Merci. C'est plus court que la page d'aide de Postfix que j'ai citée plus haut.

      • [^] # Re: Lapin compris

        Posté par  . Évalué à 2.

        checkthis.com n'a pas l'air d'apprécier le greylisting…

  • # Certificat client ?

    Posté par  . Évalué à 2.

    J'ai voulu configurer TLS avec certificat client sur mon serveur de courriel, mais il semble que la moitié cliente de l'installation ne soit pas en mesure de faire face à la demande :
    https://bugs.kde.org/show_bug.cgi?id=305396 (si ça vous concerne, ajoutez des votes au bogue !)

    • [^] # Re: Certificat client ?

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

      si ça vous concerne

      Ben en fait ça ne peut pas concerner foule, la solution est sous-entendue dans le bug report:
      "see Thunderbird for ease of use"

      --> []

  • # OpenSMTPD

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

    Avec l'excellent OpenSMTPD, voici les bouts importants pour une config qui permet d'activer le TLS:

    pki pkiname certificate "/chemin/vers/mon/certificat.crt"
pki pkiname key "/chemin/vers/ma/cle.key"

listen on lo
listen on eth0 tls-require auth-optional pki pkiname hostname "mon.hostname.du.feu.de.dieu"

    Testé sur www.checktls.com, le score est à 100% (modulo mon certificat qui n'est signé par personne de connu). Note: auth-optional est facultatif, mais c'est comme ça que c'est chez moi de toute façon.

  • # XMPP

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

    Les communications, c'est pas que SMTP, c'est aussi XMPP. Avec Prosody que j'utilise, voici les bouts de config intéressants pour du TLS/SSL:

    modules_enabled = {
...
                "tls"; -- Assez explicite
...
}

-- These are the SSL/TLS-related settings. If you don't want
-- to use SSL/TLS, you may comment or remove this
ssl = {
        key = "/chemin/vers/ma/cle.key";
        certificate = "/chemin/vers/ma/cle.crt";
}

-- Force certificate authentication for server-to-server connections?
-- This provides ideal security, but requires servers you communicate
-- with to support encryption AND present valid, trusted certificates.
-- NOTE: Your version of LuaSec must support certificate verification!
-- For more information see http://prosody.im/doc/s2s#security

s2s_secure_auth = true

-- Many servers don't support encryption or have invalid or self-signed
-- certificates. You can list domains here that will not be required to
-- authenticate using certificates. They will be authenticated using DNS.

s2s_insecure_domains = { "gmail.com", "ddg.gg", "juick.com" }

-- Even if you leave s2s_secure_auth disabled, you can still require valid
-- certificates for some domains by specifying a list here.

s2s_secure_domains = { "jabber.org" }

-- Pinnage de certificats, pour tous ceux qui ne veulent pas se soumettre à la cabale PKIstique mondiale
s2s_trusted_fingerprints = {
        --["jabber.org"] = "11:C2:3D:87:3F:95:F8:13:F8:CA:81:33:71:36:A7:00:E0:01:95:ED";
        --["matthewwild.co.uk"] = {
                --"FD:7F:B2:B9:4C:C4:CB:E2:E7:48:FB:0D:98:11:C7:D8:4D:2A:62:AA";
                --"CF:F3:EC:43:A9:D5:D1:4D:D4:57:09:55:52:BC:5D:73:06:1A:A1:A0";
        --};
        ["superhorse.se"] = "71:E6:7E:1E:DA:1F:01:E9:56:94:2C:52:D0:B5:86:07:F6:3D:7F:83";
        ["ddg.gg"] = "2A:72:69:C0:E4:36:1C:B4:98:05:D5:72:AC:CB:B9:E4:00:65:D7:30"
}

    Globalement, spécifier que le TLS est voulu et le chemin vers ses certificat et clé, et on a un serveur sécurisé. Pour tester, je ne peux que recommander xmpp.net.

  • # un petit tuto serait la bienvenue

    Posté par  . Évalué à -6.

    @ Stephane Bortzmeyer
    Bonjour,

    j'ai galéré comme un fou pour configurer mon serveur DNS: les tutos disponibles sont rarement à jour, ou comportent même des erreurs.

    J'ai réussi à faire fonctionner le mien (Debian/squeeze) mais les testeurs de DNS montrent qu'il n'est pas parfait.

    Comme spécialiste du DNS, vous serait-t-il possible de nous fournir un fichier de conf (bind et outbound) "standard" "kimarche" avec quelques explications si possible. En effet, mon fichier de conf ne me permet pas d'être valide pour la partie de mon domaine en .fr, et je ne sais pas pourquoi. (par contre, pour le .eu, .net et .org, c'est bon).

    Avec mes remerciements par avance,

    Eric

    • [^] # Re: un petit tuto serait la bienvenue

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

      Bonjour,

      pour te répondre partiellement, bien que je ne suis pas Stéphane, le .fr est particulier.

      Il n'est pas configuré comme les autres, c'est comme ça.

      L'organisme qui gère le .fr a bien plus de contrôle que le registrar qui gérerait tes enregistrements DNS, c'est un peu comme si tu leur envoies ta config, et c'est eux qui l'appliquent (et peuvent donc la changer/censurer arbitrairement).

      Je me trompe probablement, mais c'est ainsi que j'en avais compris le mécanisme pour le .fr.

      Regarde la doc concernant djbdns, ça te donnera des pistes.

      Sinon, il y a l'excellent Power DNS.

      Bon courage

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: un petit tuto serait la bienvenue

        Posté par  . Évalué à -2.

        merci

      • [^] # Re: un petit tuto serait la bienvenue

        Posté par  . Évalué à 4.

        Je me trompe probablement,

        Oui, complètement.
        L'afnic gère la délégation (les enregistrements NS plus la glue if need be), pas le contenu de la zone. Par contre, elle te demande de passer le zonecheck sur la zone et t'envoie mourir si ça ne passe pas. Par contre, en aucun cas, elle ne va aller voir ton hébergeur de DNS pour bricoler le contenu de la zone si ça ne plaît pas.

      • [^] # Re: un petit tuto serait la bienvenue

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Non, c'est tout à fait faux. Le TLD "fr" est un TLD comme un autre et n'a rien de particulier.

        Quant aux affirmations comme quoi le registre de "fr" aurait la main sur votre config… c'est du délire, tout simplement.

        djbdns est à fuir absolument. Logiciel non maintenu et à qui il manque la plupart des fonctions utiles (DNSSEC, IPv6, etc).

    • [^] # Re: un petit tuto serait la bienvenue

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

      Euh, je veux bien, mais cela n'a aucun rapport avec le journal, qui parlait de TLS sur SMTP…

      Question fichiers de conf' tous faits, il y avait ceux de mon exposé à IEUFI. Mais, évidemment, cela dépend des cas.

      Pour le reste, franchement, en l'absence des messages d'erreur, je ne peux rien faire. « Ça ne marche pas » n'est pas un message d'erreur :-) Prenons un exemple concret, le TLD cambodgien :

      % zonecheck kh
ERROR: Unable to find nameserver IP address(es) for kh.cctld.authdns.ripe.net

      Là, on peut agir : la zone "kh" liste parmi ses serveurs de noms un kh.cctld.authdns.ripe.net qui n'existe pas (comme on peut le vérifier avec dig). Il faut remplacer par le nom correct.

      • [^] # Re: un petit tuto serait la bienvenue

        Posté par  . Évalué à 0.

        Bonsoir

        effectivement … je ne devais carrément pas être bien réveillé. (et en plus je m'étonnais du score négatif :) )

        mes excuses et merci pour le lien.

Suivre le flux des commentaires

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