Journal Chiffrement de SMTP, une obligation?

Posté par  . Licence CC By‑SA.
Étiquettes :
21
12
oct.
2015

Bonjour,

Notre cher gouvernement français souhaite passer entre les différents FAI français et le groupe La Poste une charte pour que les flux de courriels entre eux soit chiffrés.
http://www.nextinpact.com/news/96749-une-charte-avec-fai-francais-pour-chiffrement-emails.htm
Bref qu'ils ajoutent un S au SMTP. Les techniciens espéreront juste que cela n'utilise pas SSL mais plutôt TLS.

Avant d'entrer dans le sujet, un petit rappel rapide. Le courriel est une carte postale que tout intervenant dans le réseau peut lire: FAI, DSLAM, routeur, etc. Dans un courriel, il y a:

  • les métadonnées qui sont souvent là dans un but de faire fonctionner la technologie et
  • le corps du message.

Protéger le corps du message (contenu) c'est bien, protéger aussi les méta-données (le contenant) c'est mieux.

Le courriel n'a pas été prévu à la base pour faire de la confidentialité, ses concepteurs voulaient juste que cela transmettent des informations.
Pour donner de la confidentialité, il est possible de chiffrer le corps du message de bout en bout avec des couples de clés asymétries, le meilleur exemple est GPG. On peut aussi chiffrer le flux de communication entre les clients et les serveurs. Mais on peut surtout chiffrer le flux entre les différents serveurs en utilisant TLS .

Pour plus d'informations:
http://www.iletaitunefoisinternet.fr/lemail-par-benjamin-sonntag/
http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag
(fin de la parenthèse technique)

On peut regretter que le gouvernement (après un discours du premier ministre JM Ayrault en 2014), ne rende pas la chose obligatoire ( une charte cela n'engage que ceux qui y croient).

Désarmons tout de suite l'aspect renseignement. Il est certains que les RG ont des accès dans ces FAI et que le chiffrement de SMTP ne va pas les arrêter (ils feront des demandes aux prestataires). Mais pour le gouvernement, cela permet de protéger les citoyens français et les entreprises. En effet, cela va éviter aux espions des autres états de se servir facilement en informations juste en captant le flux de courriels.
On peut dire que c'est une bonne chose.

Toutefois quand on voit qu'Orange ne demande pas de mots de passe si on se connecte en local à la box. Pour des particuliers, je trouve ça limite. Pour des offres professionnels destiné aux PME, c'est pour moi de la paresse de la part de l'agrume.

Enfin, il y a ceux qui discutent et ceux qui agissent. Et Google est clairement dans la deuxième catégorie. Ils mettent en avant le chiffrement des flux SMTP:
https://www.google.com/transparencyreport/saferemail/
Et on peux tester les serveurs des autres. Ainsi:

domaine du courriel messages sortants messages entrants
bouyguestelecom.fr inconnu 0%
bouygues-telecom.fr inconnu 100%
free.fr moins de 50% 99%
aliceadsl.fr moins de 50% 99%
laposte.net 100% 99,99%
numericable.fr 100% 99,9%
noos.fr inconnu 100%
Orange 100% 99%
wanadoo.fr 100% 99%
sfr.fr 100% 99,9 %
club-internet.fr 100% inconnu
neuf.fr 100% inconnu
ovh.net inconnu moins de 50%

On relève donc que c'est déjà le cas de beaucoup des futurs signataires de la charte. Au moins pour les flux chiffrés venant de gmail. Quand il s'agit de produire des flux chiffré vers gmail c'est moins fréquent mais pas rare.

Ce journal ne serait pas complet si on ne parlait du projet Own-Mailbox qui avorté avant la fin de la campagne Kickstarter (voir la news).
Le projet me semblait intéressant et si il n'offrait une confidentialité parfaite (c'est pas l’objectif du mail), il permettait de faciliter la confidentialité des échanges en utilisant GPG.
Le nouveau projet veut utiliser Tor pour donner de la confidentialité. TLS sera utilisé systématiquement pour communiquer avec Own-Mailbox au niveau http, j'imagine qu'il en sera de même au niveau SMTP et IMAP.

Pour finir, j'aimerais savoir si il existe des outils autre que la page de google que j'ai cité qui permettent de savoir si:
- le fournisseur de courriel propose STMPS et si oui avec quelles technologies (TLS, SSL) et quel algorithme?
- même questions pour IMAP et POP
Bref, des outils à la SSLLabs, histoire de voir si votre fournisseur ne fait pas que du déclaratif.

Enfin je me demande si il y est possible de refuser de communiquer un courriel si le serveur en face ne fait pas de réception/envoi chiffré? On le sait, si vous mettez du chiffrement mais laissez la possibilité d'un mode avec un chiffrement trop faible (RC4 ou bien SSL) ou un mode sans chiffrement un attaquant va essayer au maximum de vous forcer à utiliser ces modes.

Et pour en revenir au titre, pensez-vous que le SMTP devrait obligatoirement communiquer avec une couche de chiffrement ??

  • # Rectification insignifiante

    Posté par  . Évalué à 4.

    Toutefois quand on voit qu'Orange ne demande pas de mots de passe si on se connecte en local à la box. Pour des particuliers, je trouve ça limite. Pour des offres professionnels destiné aux PME, c'est pour moi de la paresse de la part de l'agrume.

    En fait si mais pas out-of-the-box : il faut créér un deuxième compte associé à la livebox, pour qu'il te demande un mot de passe …

    • [^] # Re: Rectification insignifiante

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

      ça dépend, pour certaines opérations le couple utilisateur/mot de passe est demandé.

      Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

  • # Chiffrement opportuniste

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 12 octobre 2015 à 13:22.

    Attention, actuellement, le chiffrement des transmissions par SMTP est purement opportuniste, donc vulnérable aux attaques avec réécriture — le fameux homme du milieu. C'est à dire qu'au moment de transmettre un message, on se connecte au serveur distant, puis :

    • s'il propose le chiffrement, on démarre une sessions TLS sans vérifier son identité ;
    • sinon, on transmet en clair.

    On ne peut pas raisonnablement refuser de transmettre sans TLS, parce que plein d'adresses seraient alors injoignables par courrier électronique, leurs serveurs ne proposant pas de chiffrement. Il ne sert à rien de vérifier l'identité du serveur destinataire en contrôlant son certificat, parce que ça n'ajouterait rien, puisqu'on accepte de toute façon de transmettre en clair, ce qui est encore moins sûr.

    Donc, dans ce contexte, chiffrer, c'est bien, c'est ce qu'on appelle du chiffrement opportuniste, mais il faut être conscient que ça ne protège que des écoutes passives et aucunement des attaques par réécriture.

    • [^] # Re: Chiffrement opportuniste

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

      Si tu sais que ton correspondant chiffre, tu peux refuser de communiquer en clair (bon ca demande une BDD des personnes chiffrant) il manque certe un truc du genre HSTS pour bien limiter les dégats

    • [^] # Re: Chiffrement opportuniste

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

      ça ne protège que des écoutes passives

      Ben si, justement : ce n'est pas celui qui écoute qui décide, donc si les deux serveurs sont OK, ben c'est chiffré.

      aucunement des attaques par réécriture.

      La, certes…
      Faudrait sans doute un champs DNSSEC qui dise qu'il faut SSL, mai on est encore loin de ça…

      • [^] # Re: Chiffrement opportuniste

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

        ça ne protège que des écoutes passives

        Ben si, justement : ce n'est pas celui qui écoute qui décide, donc si les deux serveurs sont OK, ben c'est chiffré.

        C'est ce que je dis ! J'ai écrit que ça ne protégeait que des écoutes passives, pas que ça ne protégeait pas des écoutes passives…

      • [^] # Re: Chiffrement opportuniste

        Posté par  . Évalué à 3.

        Faudrait sans doute un champs DNSSEC qui dise qu'il faut SSL, mai on est encore loin de ça…

        Pour info, le RFC 7672 spécifie que la seule existence d’enregistrements TLSA pour un serveur mail suffit à indiquer que TLS est obligatoire pour contacter ledit serveur (section 2.2, “TLS Discovery”).

        Postfix implémente ce comportement avec smtp_tls_security_level = dane (Victor Dukhovni, co-auteur du RFC, est un des développeurs de Postfix).

    • [^] # Re: Chiffrement opportuniste

      Posté par  . Évalué à 1.

      C'est d'ailleurs une question à laquelle je n'ai jamais trouvé de réponse très claire.

      Si j'utilise un certificat auto-signé sur mon serveur de messagerie, est-ce que ça va générer des erreurs chez les serveurs qui tentent de m'envoyer un mail ?

      • [^] # Re: Chiffrement opportuniste

        Posté par  . Évalué à 6.

        Si j'utilise un certificat auto-signé sur mon serveur de messagerie, est-ce que ça va générer des erreurs chez les serveurs qui tentent de m'envoyer un mail ?

        Dans le cas général, non. La plupart des serveurs de mail sont configurés pour ne pas exiger que le certificat du pair soit authentifié contre une liste de CA.

        Après, c’est bien sûr à la discrétion de l’administrateur du serveur. Celui qui veut exiger des certificats « authentifiés » peut toujours le faire (smtp_tls_security_level = verify avec Postfix)… au risque de se couper de pas mal d’émetteurs.

        En revanche, si tu utilises un certificat auto-signé, je t’encourage fortement à publier un enregistrement TLSA (et à signer ta zone DNS si ce n’est pas déjà fait). DANE est pris en charge par certains serveurs mails (dont Postfix, encore une fois).

        • [^] # Re: Chiffrement opportuniste

          Posté par  . Évalué à 4.

          À noter que Facebook a des données intéressantes sur le chiffrement SMTP et sur la validation des certificats en particulier.

          Ce que je retiens notamment, c’est que ce qui dissuade de valider strictement les certificats n’est pas la proportion de certificats auto-signés (qui sont en fait négligeables contrairement à ce que je pensais, de même que les certificats signés par des CA non-reconnues), mais la proportion de certificats incorrects : dans 99.35% des cas (!), la validation stricte échoue parce que le nom mentionné dans le certificat ne correspond pas au nom du serveur.

          (Du coup, avec autant de mauvais certificats qui traînent, tu peux être tranquille avec ton certificat auto-signé, les administrateurs ne sont pas près de pouvoir exiger des certificats valides…)

          • [^] # Re: Chiffrement opportuniste

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

            Ce que je retiens notamment, c’est que ce qui dissuade de valider strictement les certificats n’est pas la proportion de certificats auto-signés (qui sont en fait négligeables contrairement à ce que je pensais, de même que les certificats signés par des CA non-reconnues), mais la proportion de certificats incorrects

            Non, c'est plus simple que ça. Ce qui dissuade de valider les certificats, c'est que, quand on accepte par ailleurs de transmettre les messages en clair quand le serveur en face ne prend pas en charge TLS, ça ne sert tout simplement à rien du tout.

            En effet, valider les certificats sert à se prémunir des attaques par réécriture, où l'attaquant fournit son propre certificat usurpé, ce qui est alors détecté. Sauf que, dans un tel cas d'attaque, le première chose que l'attaquant va faire, c'est transmettre la réponse initiale du serveur destinataire, en en enlevant l'indication de prise de TLS. Le serveur émetteur continuera donc en clair, et l'interception pourra avoir lieu.

            Par conséquent, vérifier les certificats des serveurs destinataires qui prennent en charge TLS n'apporte de protection contre aucun type d'attaque. Cette vérification n'a d'intérêt que si on n'accepte pas de transmettre en clair, or ce n'est pas une option réaliste aujourd'hui.

            • [^] # Re: Chiffrement opportuniste

              Posté par  . Évalué à 1.

              Hélas, ce n'est pas parce que ça n'a pas de sens que ce n'est pas fait; d'ou ma question initiale.

              • [^] # Re: Chiffrement opportuniste

                Posté par  . Évalué à -6. Dernière modification le 13 octobre 2015 à 13:56.

                La vérification du certificat ne sert à rien…. voilà autre chose!

                On va la faire avec du web :
                - je fais mon petit site
                - je l'appelle google.com
                - je crée mon certificat autosigné pour google.com
                - je modifie le contenu de ton DNS (facile si tu es sur mon réseau wifi)
                - toi tu vas sur google => donc chez moi et tout te parait normal, puisque ca ne sert à rien de vérifier le certificat.

                Si ca c'est pas une attaque, je ne sais pas ce que c'est.

                La vérification du certificat sert à authentifier le correspondant.
                Et ce n'est pas pcq google.com est accessible en http qu'il ne faut pas vérifier son certificat qd on fait du https.

                Idem pour le smtps.

                • [^] # Re: Chiffrement opportuniste

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

                  Cf plus bas.

                  La vérification de la validité du certificat ne DOIT pas être faite et est de toute façon très difficile à faire.

                  Les RFC l’indiquent clairement, on ne peut faire la supposition que les valideurs potentiels auront une stack de CA correctes à disposition, en plus d’avoir des problèmes de détermination du domaine à valider (une vérif du domaine de destination est impossible par manque de SNI sur SMTP et le domaine du MX est faillible par l’attaque que tu annonces).

  • # réponses

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

    • Non ce n'est pas une bonne chose !: L'ANSII ne va pas jusqu'au bout de sa logique: les bad guy utilisent le chiffrement donc ce n'est pas la peine de freiner le chiffrement à moins que l'on ne vise pas les bad guy.
    • C'est possible de refuser de communiquer avec un serveur ne faisant pas de chiffrement mais aucun moyen de savoir ce qu'il fera ensuite avec tes envois
    • La seule solution viable en l'absence de volonté des autorités pour enfin sécuriser le maximum les communications de bout à bout me semble caliopen https://caliopen.org/

  • # starttls.info

    Posté par  . Évalué à 5.

    Pour finir, j'aimerais savoir si il existe des outils […] à la SSLLabs, histoire de voir si votre fournisseur ne fait pas que du déclaratif.

    Il y a starttls.info (moins complet que SSLLabs pour les serveurs web néanmoins… et qui ne prend pas davantage en charge DANE).

    • [^] # Re: starttls.info

      Posté par  . Évalué à 6.

      Je ne saisi pas pourquoi le site teste startTLS alors que ce n'est pas la seule méthode de connexion (TLS) chiffré. Après il est vrai que startTLS permet de garder le même numéro de port que pour les connexions non chiffrés et évite de donner un port dédié comme le demande TLS.

      Je note qu'il faut parfois relancer 2 fois le test pour être sur du résultat.

      Résultats

      • bouyguestelecom.fr grade A 92% avec mail.messaging.microsoft.com et bouyguestelecom-fr.mail.protection.outlook.com (qu'es-ce que vient faire MS dans cette histoire) ??
      • bouygues-telecom.fr => pas de Start TLS
      • free.fr => pas de Start TLS pour mx2.free.fr mais grade B (72%) pour mx1.free.fr
      • aliceadsl.fr => pas de Start TLS pour mx2.free.fr mais grade B (72%) pour mx1.free.fr
      • laposte.net grade C (50%)
      • numericable.fr grade D (39%)
      • noos.fr grade E (33%)
      • Orange grade F
      • wanadoo.fr échec de l'analyse
      • sfr.fr grade A (89,2%)
      • club-internet.fr grade A (83,2%)
      • neuf.fr grade A (83.2%)
      • ovh.net => pas de Start TLS
      • gandi.net mail4.gandi.net pour grade: A (84.6%) mais mail8.gandi.net pas de Start TLS

      • [^] # Re: starttls.info

        Posté par  . Évalué à 4.

        Je ne saisi pas pourquoi le site teste startTLS alors que ce n'est pas la seule méthode de connexion (TLS) chiffré.

        Parce que c’est ce qui compte vraiment quand tu veux envoyer un mail à une destination quelconque.

        Le comportement classique d’un serveur à qui on demande de transférer un mail à alice@example.org est de contacter la machine mentionnée dans le MX de example.org, sur le port 25. Je ne pense pas que beaucoup de serveurs prennent le temps d’essayer une connection sur le port 465 pour voir si une une connection chiffrée (SMTP-over-TLS) serait disponible par là.

        SMTP-over-TLS n’est guère utilisable qu’entre des machines qui se connaissent, et qui savent qu’elles doivent se contacter sur le port 465.

        bouyguestelecom.fr grade A 92% avec mail.messaging.microsoft.com et bouyguestelecom-fr.mail.protection.outlook.com (qu'es-ce que vient faire MS dans cette histoire) ??

        Apparemment c’est Microsoft qui fournit le service de mail pour bouyguestelecom.fr :

        $ dig bouyguestelecom.fr. MX
[…]
;; ANSWER SECTION:
bouyguestelecom.fr. 3600    IN  MX  0 bouyguestelecom-fr.mail.protection.outlook.com.
bouyguestelecom.fr. 3600    IN  MX  1 mail.messaging.microsoft.com.
[…]

        • [^] # Re: starttls.info

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

          Parce que c’est ce qui compte vraiment quand tu veux envoyer un mail à une destination quelconque.

          A contrario STARTTLS est envoyé en clair dans la conversation, donc si un maychant homme du milieu passe par là il peut très bien retirer le bout qui annonce la possibilité de faire du STARTTLS.

          En plus de ça c'est plus difficile de faire l'équilibrage de charges, parce qu'il faut un terminateur TLS qui sache parler le SMTP (en tout cas jusqu'à ce que la négociation soit finie). Et recommencer pour chaque protocole qui utilise STARTTLS.

          Bref, c'est pratique parce que ça évite de casser trop de choses, mais l'argument "le client sait qu'il peut tenter le SMTP direct" ne tient pas, parce que de la même manière en forçant SMTP-over-TLS on pourrait dire "le client sait qu'il peut tenter TLS+SMTP".

      • [^] # Re: starttls.info

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

        Je viens de tester starttls.info sur mon propre serveur de mail, le service ouvre de nombreuses connexions et donc Postfix refuse les nouvelles connexions au bout d'un moment ("connection rate limit exceeded"), le service continue à réessayer sans ralentir et finit par me sortir une erreur "le serveur a refusé le test". Pas encore au point comme truc :-)

  • # Refuser un courriel sans chiffrement

    Posté par  . Évalué à 7.

    Enfin je me demande si il y est possible de refuser de communiquer un courriel si le serveur en face ne fait pas de réception/envoi chiffré?

    Oui. Pour Postfix :

    smtp_tls_security_level = encrypt

    pour refuser de transmettre un mail à un pair sans chiffrement, et similairement

    smtpd_tls_security_level = encrypt

    pour refuser de recevoir un mail sans chiffrement.

    À noter néanmoins que ce dernier cas est formellement interdit pour un serveur mail public par le RFC 3207 :

    A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.

    • [^] # Re: Refuser un courriel sans chiffrement

      Posté par  . Évalué à 4.

      À noter néanmoins que ce dernier cas est formellement interdit pour un serveur mail public par le RFC 3207

      Informations importantes. Merci

  • # Postfix

    Posté par  (site web personnel) . Évalué à 8. Dernière modification le 12 octobre 2015 à 17:44.

    Comme on l'a vu, il n'est pas réaliste pour l'administrateur d'un serveur de courrier d'imposer le chiffrement pour toutes les transmissions sortantes. En revanche, il peut être utile de le faire pour les noms de domaines destinataires dont on sait qu'ils le prennent en charge avec une configuration correcte.

    Voici donc comment le faire avec Postfix. Avertissement : je n'ai pas essayé, pas encore du moins. Dans /etc/postfix/master.cf, définir un nouveau transport forcetls :

    # ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      unix  -       -       -       -       -       smtp
force-tls unix  -       -       -       -       -       smtp -o smtp_tls_security_level=verify

    Ensuite, définir une table de transports, dans /etc/postfix/main.cf :

    transport_maps = hash:/etc/postfix/transport

    Créer cette table, en y mettant les noms de domaines pour lesquels on veut transmettre exclusivement en TLS avec vérification :

    laposte.net     force-tls:

    Hacher cette table, puis redémarrer Postfix :

    # postmap /etc/postfix/transport
# service postfix restart

    À noter qu'avec cette configuration, pour un nom de domaine donné, Postfix ira chercher les MX, par résolution DNS souvent non sécurisée — DNSSEC est encore loin d'être la norme — puis, s'il fait partie de cette liste des noms de domaines pour lesquels il doit transmettre exclusivement en TLS avec vérification, vérifier que le certificat utilisé couvre bien le nom du MX choisi — et non le nom de domaine destinataire.

    Cela laisse donc un vecteur d'attaque, par réécriture des réponses DNS, qui permet à l'attaquant d'indiquer son propre MX qui prendra en charge TLS avec un certificat qui couvre bien son nom. Postfix permet d'éviter cela en vérifiant à la place que le certificat utilisé couvre bien le nom de domaine destinataire. Cela a plus de sens, puisqu'on cherche à s'assurer qu'on est bien en train de transmettre aux serveurs d'un nom de domaine destinataire donné, et non à un MX précis. L'ennui, c'est qu'il semble qu'il est justement courant d'utiliser un certificat qui couvre le nom de MX et non le nom de domaine destinataire, ce qui est donc moins sûr, mais beaucoup plus pratique lorsqu'on fait de l'hébergement virtuel de noms de domaines multiples, faute de SNI : cette vérification correcte serait donc en pratique peu utilisable… À vérifier toutefois ; pour info, cela se fait avec une autre valeur de smtp_tls_security_level ou en modifiant globalement le smtp_tls_verify_cert_match.

    • [^] # Re: Postfix

      Posté par  . Évalué à 8.

      Dans /etc/postfix/master.cf, définir un nouveau transport forcetls

      Pourquoi ne pas plutôt utiliser smtp_tls_policy_maps, qui (avec Postfix ≥ 2.3) sert à précisément à ça ?

    • [^] # Vérif du certificat

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

      Postfix permet d'éviter cela en vérifiant à la place que le certificat utilisé couvre bien le nom de domaine destinataire

      C’est plus compliqué que ça.

      En pratique, il ne faut pas vérifier le nom de domaine du certificat, car à l’inverse de HTTPS, SMTP+STARTTLS ne permet pas SNI, ie. de sélectionner un certificat pour chaque domaine de destination, sauf à sous-entendre que 1 domaine = 1 serveur SMTP & 1 IP.
      C’est par exemple particulièrement vrai pour les fournisseurs mutualisés, comme OVH, Google ou Microsoft, qui n’ont qu’un seul MX pour l’ensemble des domaines servis.
      Au mieux on pourrait seulement vérifier que domaine du certificat = domaine du MX (ou de son reverse), mais en aucun cas la vérification domaine du certificat = domaine du récepteur n’est possible. Une usurpation du DNS ne pourra donc pas être détectée par ce moyen.

      De plus, les RFC mentionnent aussi qu’il faut considérer que les serveurs SMTP émetteurs n’ont pas les compétences nécessaires pour vérifier la chaîne de validité, par exemple pas de liste de CA valides (cf https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.3).
      Un MitM serait dans tous les cas facilement faisables, via un simple certificat auto-signé usurpant le domaine visé…

      En clair, le mail est non sécurisable parce que personne ne l’a envisagé comme ça quand il a été définit au début du monde, et toutes les couches de sécu actuelles sont des hacks plus ou moins ignobles et (in)efficaces pour corriger le tir.

  • # OpenSSL

    Posté par  . Évalué à 3.

    Salut,

    cbri écrivit :

    Pour finir, j'aimerais savoir si il existe des outils autre que la page de google que j'ai cité qui permettent de savoir si […] le fournisseur de courriel propose STMPS et si oui avec quelles technologies (TLS, SSL) et quel algorithme ?

    Tu peux utiliser l'option s_client de la commande openssl(1) pour cela. Par exemple, pour obtenir ces informations du serveur SMTP de Yahoo.

    openssl s_client -connect smtp.mail.yahoo.com:465

  • # Outil de test + STARTTLS

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

    Pour finir, j'aimerais savoir si il existe des outils autre que la page de google que j'ai cité qui permettent de savoir si

    Il y a l’outil que j’ai développé : https://tls.imirhil.fr/
    Sources dispo ici : https://github.com/aeris/cryptcheck

    Le problème de la notation pour le mail, c’est que c’est beaucoup plus compliqué que pour HTTPS, SMTP étant un protocole asynchrone. En particulier, il vaut mieux utiliser un protocole totalement moisi comme SSLv3, DES ou MD5 que d’émettre le message en clair, ce qui est le cas si les 2 serveurs n’arrivent pas à se mettre d’accord sur une suite de chiffrement.
    Un serveur noté « F » n’est donc pas complètement anormal tant qu’on aura pas améliorer l’ensemble des serveurs du monde.

    À noter aussi que la présence (ou l’absence) de STARTTLS n’est pas authentifiée comme dans le cas de HTTPS, et donc qu’un attaquant dans le réseau n’a qu’à simplement droper le petit paquet réseau contenant la chaîne « STARTTLS » dans les échanges SMTP pour que le serveur émetteur considère que le destinataire ne supporte pas le chiffrement et envoie alors le message en clair.
    C’est à la portée de n’importe qui, y compris d’un pixel sur le parvis de la Défense avec un routeur TP-Link à $20… Je vous laisse le soin de comprendre ce qu’une agence gouvernementale est capable de faire sur le sujet :)

    • [^] # Re: Outil de test + STARTTLS

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

      Je lis dans le readme:
      "3DES is considered weak and must be avoided, using it cap your score to "C"."

      Alors que la RFC 7525 qui te sert de référence dit le contraire :
      "Cipher suites that offer between 112-bits and 128-bits of security are not considered weak at this time (…) 112 bits in the case of 3DES"

      Pas très cohérent…

      Ensuite, quand je lis:
      "Only a perfect setup gets a perfect score and a "A" rank :)."

      Je me pose des questions car ce "perfect" bloque plein d'utilisateurs considérés encore comme sûrs, c'est "perfect" vis à vis de quoi? Pas de la relation utilisabilité/sécurité en tout cas. Ca m'a l'air bien relatif, perso un serveur est parfait si il sait faire des compromis vis à vis de ses utilisateurs, et il est imparfait si il bloque des utilisateurs sans raison de sécurité au moment du test (par exemple, taper sur un serveur qui ne supporte que 3DES aujourd'hui est normal car il restera pour le futur, taper parce qu'un serveur accepte entre autre 3DES en 2015, date à laquelle on ne considère pas 3DES comme cassé, pour des raisons de gestion de l'histoire, me semble illégitime)

      Le soucis avec ce genre de notation "dogmatique" (oui, j'ose utiliser le mot) est qu'il n'est pas utilisable pour le monde réel (celui où 3DES est encore considéré comme acceptable pour quelques années et où IE8 sur WinXP est encore utilisé tout en allant vers la mort).

      Du coup, un serveur du monde réel qui ne veut pas se couper de gens sans raison de sécurité en 2015 se tape un "C" sur cryptcheck la où il obtient un "A+" sur SSLLabs…

      Bref, outil à utiliser si vous savez en avance la pile de sécurité de vos utilisateurs (et que vous savez que vous utilisateurs sont des adorateurs de la sécurité qui vont refuser de se connecter à un serveur TLSv1.1 par exemple), et rien d'autre, à moins que j'ai loupé quelque chose.

      • [^] # Re: Outil de test + STARTTLS

        Posté par  . Évalué à 1.

        Je suis un peu d'accord avec tes propos.

        Pourquoi Noos aurait-il la note M et Orange la note F alors que Noos est capable du meilleur (TLS 1.2, PFS) comme du pire (anonymous, SSL2). Orange ne proposant TLSv1 (avec PFS), SSLv3

        Je serais curieux de savoir si des serveurs de courriels arrivent à avoir au-dessus de F

        [SMTP] tls.imirhil.fr (13/10/2015 09:24:05) F

        Le test que propose Aeris est plus orienté https et il semble garder les mêmes critères pour SMTP.
        À la lecture des différentes commentaires qui appuient bien sur la grosse dette historique de SMTP, on ne peut pas utiliser les mêmes critères de jugement.

        • [^] # Re: Outil de test + STARTTLS

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

          Pourquoi Noos aurait-il la note M et Orange la note F alors que Noos est capable du meilleur (TLS 1.2, PFS) comme du pire (anonymous, SSL2). Orange ne proposant TLSv1 (avec PFS), SSLv3

          « M » = certificat mismatch. C’est-à-dire qu’un utilisateur se taperait une alerte de sécurité puisque le certificat ne correspond pas au domaine à protéger.

          À la lecture des différentes commentaires qui appuient bien sur la grosse dette historique de SMTP, on ne peut pas utiliser les mêmes critères de jugement.

          Tout à fait. Mettre un « A » en place sur SMTP, c’est forcer 90% (au doigt mouillé) du trafic SMTP à passer en clair puisque le serveur en face n’arrivera pas à négocier une suite de chiffrement.

        • [^] # Re: Outil de test + STARTTLS

          Posté par  . Évalué à 3.

          Je pense que ce test n'est pas pertinent pour les MX qui seront bloqués à F. Comme ça a déjà été dit le chiffrement entre les MX est opportuniste et doit donc être le plus tolérant possible car ce sera toujours mieux qu'en clair.

          Mon serveur de submission à lui la note de C.

          • [^] # Re: Outil de test + STARTTLS

            Posté par  . Évalué à 3.

            les MX qui seront bloqués à F […] Mon serveur de submission à lui la note de C.

            L’inverse me semblerait plus logique…

            Les serveurs de soumissions, qui sont directement contactés par les utilisateurs finaux (et donc potentiellement une large gamme de systèmes plus ou moins obsolètes comme Windows XP, Android 2.3, etc.) ont intérêt à être tolérant.

            Mais les MX, qui sont essentiellement contactés par d’autres serveurs (c’est quand la dernière fois que vous avez envoyé un mail en contactant directement le MX de votre correspondant depuis votre propre poste, sans passer par un relai ?) peuvent probablement se permettre d’être moins laxistes, du moins d’après mes observations.

            Mon propre MX est noté A, et dans mes logs je constate que la plupart des connections entrantes sont bien chiffrées, et que celles qui ne le sont pas viennent de serveurs qui n’ont dès le départ même pas tenté de négociation TLS.

            • [^] # Re: Outil de test + STARTTLS

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

              Non, c’est bien l’inverse.

              Les serveurs de soumission, ce sont tes propres clients qui les utilisent, tu as donc la main dessus et tu peux imposer de la crypto correcte et obligatoire dessus.

              Les MX, tout le monde peut les utiliser, et donc tu ne maîtrises pas du tout la configuration TLS minimale qu’ils vont supporter ou non. Il faut donc être le plus laxiste dessus.

              Donc sur du submission (587), TLS (natif, pas STARTTLS) imposé avec config draconienne (les MUA thunderbird/outlook/kontact/claws-mail supportent une crypto correcte), sur du smtp (25), STARTTLS facultatif avec le maximum de ciphers actives (mauvais support de la crypto par la plupart des MTA, dont les scripts PHP moisis de mailing et autre).

      • [^] # Re: Outil de test + STARTTLS

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 13 octobre 2015 à 10:19.

        "3DES is considered weak and must be avoided, using it cap your score to "C"."
        Alors que la RFC 7525 qui te sert de référence dit le contraire :

        3DES a un autre biais, sa taille de bloc, qui n’est que de 64 bits, soit bien trop faible.
        L’ANSSI déconseille aussi ce cipher (cf http://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf page 10 & 11) et recommande au moins du 128 bits (en taille de clef & en taille de bloc).

        Je me pose des questions car ce "perfect" bloque plein d'utilisateurs considérés encore comme sûrs, c'est "perfect" vis à vis de quoi?

        C’est « perfect » au sens qu’on n’a aucun des warning/erreurs précédents.

        il est imparfait si il bloque des utilisateurs sans raison de sécurité au moment du test

        Faux.

        Le fait d’avoir du 3DES actif côté serveur suffit à pouvoir tomber dessus en cas de mauvaise configuration (ordre des suites côté client) ou en cas d’attaque (downgrade attack).
        On n’est donc pas à l’abris d’une merde dès que 3DES est dispo quelque part.

        On a aussi vu que le non support de PFS exposait violamment à la NSA (par exemple via Heartbleed) en cas de compromission de la clef privée dans le futur.
        Idem, sauf à utiliser uniquement des suites PFS (puisque la présence d’une non PFS rendrait la connexion potentiellement non fiable), on est à poil.

        Du coup, un serveur du monde réel qui ne veut pas se couper de gens sans raison de sécurité en 2015 se tape un "C" sur cryptcheck la où il obtient un "A+" sur SSLLabs…

        Ne pas se couper des gens à l’heure actuelle, c’est exploser en plein vol à la prochaine grosse faille de sécu sur ces protocoles. TLSv1.0 & TLSv1.1 sont dorénavant faillibles à du Poodle, et une escalade de cette faille rendrait vulnérables tous les utilisateurs de ces protocoles.
        La note « A » est donc la seule configuration valable actuellement qui résistera dans le temps et évitera d’avoir à patcher à l’arrache (ou non, cf RC4 & MD5 qui persistent malgré les risques…).
        Tant qu’on ne fait pas mal à l’utilisateur, la sécu ne s’améliore pas. La preuve, même les CA ne savent pas commencer à bosser avant d’être plus que le dos au mur (voire même plutôt déjà encastrées dedans), cf https://cabforum.org/pipermail/public/2015-September/005935.html

        • [^] # Re: Outil de test + STARTTLS

          Posté par  . Évalué à 2.

          Tant qu’on ne fait pas mal à l’utilisateur, la sécu ne s’améliore pas. La preuve, même les CA ne savent pas commencer à bosser avant d’être plus que le dos au mur (voire même plutôt déjà encastrées dedans), cf https://cabforum.org/pipermail/public/2015-September/005935.html

          Sauf que dans ton exemple c'est pas un utilisateur lambda. C'est un CA, normalement spécialiste de la sécurité qui t'explique qui n' pas eu le temps en 2 ans de faire la migration (à croire qu'ils n'avaient jamais commencé à intégrer cette technologie avant, bonjour la veille).

          Je suis d'accord avec toi, il faut parfois taper pour que la sécurité avance. Mais autant taper sur les intermédiaires qui ont fait de manière incomplète leur travail. Parce que passez des heures avec des utilisateurs lamba qui ne savent pas ce qu'est HTTP ou SMTP pour leur faire comprendre qu'il faut passer à TLS 1.2 et activer PFS…
          Il faut que cela soit près pour que l'utilisateur lambda est juste une mise à jour/mise à niveau de ses outils à faire.

          • [^] # Re: Outil de test + STARTTLS

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

            Sauf que dans ton exemple c'est pas un utilisateur lambda. C'est un CA

            Oui, mais je pars du principe que si une CA a 3 ans de retard en terme de mise-à-jour, un utilisateur lambda doit en être à 10 ou 15 ans :P

            Et les CA n’ont pas fait la migration justement pour la bonne raison « qu’on ne veut pas perdre nos utilisateurs sous WinXP ou qu’on ne veut pas migrer nos applis inmaintenables ». Idem pour la sécu des banques : « on ne veut pas voir notre support exploser ni perdre 1% de chiffre d’affaire ».
            Poule, œuf, tout ça tout ça…
            Si on veut améliorer la sécu, ça va « forcément » passer par une décision unilatérale et violente des navigateurs et autres, qui va laisser beaucoup de monde sur le carreau.

            Cf par exemple la position de Google sur le sujet qui est encore plus extrémiste que moi : https://googleonlinesecurity.blogspot.sg/2015/09/disabling-sslv3-and-rc4.html.
            TLS 1.2 avec du AES-GCM (ça ça pique vraiment vu le très mauvais support actuel) et du ECDSA P-256 (idem, ça pique beaucoup), c’est actuellement bien indiqué comme « la configuration pérène jusqu’en 2020 qui ne nécessitera pas de revoir sa configuration tous les 6 mois ».

            • [^] # Re: Outil de test + STARTTLS

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

              Cf par exemple la position de Google sur le sujet qui est encore plus extrémiste que moi

              Je ne vois pas ce qu'il a de plus ou d'extrémiste, il dit que TLS1.2 et TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 doivent être supporté, pas que ce soi les seuls.

              • [^] # Re: Outil de test + STARTTLS

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

                Faut savoir lire entre les lignes :D

                Ils veulent ne plus avoir à toucher à leur config d’ici 2020. Ça signifie que tout le reste sera désactivé à plus ou moins court terme, et de force dans les prochaines versions de leur navigateur (ça a commencé avec RC4, ça sera SHA-1 au 1er janvier 2016, puis 3DES et TLS < 1.2).

            • [^] # Re: Outil de test + STARTTLS

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

              Si on veut améliorer la sécu, ça va « forcément » passer par une décision unilatérale et violente des navigateurs et autres, qui va laisser beaucoup de monde sur le carreau.

              Je confirme, et j'ai vécu ça au travail. On héberge des clients, et un jour, on nous a demandé d'appliquer une politique de sécurité précise, qui incluait entre autre la désactivation de la prise en charge SSLv3. Cette politique de sécurité n'étant pas du tout optionnelle, on l'a appliquée, sachant très bien que ça allait râler. Et ça n'a pas loupé, une semaine après, on a vu arriver des demandes provenant de notre support client, qui ont donné lieu à des échanges comme :

              • Tel client a une erreur « trucbidule SSLv3 not supported », il faut que vous répariez ça.
              • C'est normal et voulu, on a désactivé SSLv3. Le client doit mettre à jour ses systèmes. (Ticket fermé par le sysadmin)
              • Ça ne va pas, ils ne peuvent plus du tout utiliser leur plate-forme. Il faut que vous réactiviez ça. (Ticket rouvert par le support client)
              • On l'a désactivé parce que c'est interdit par la nouvelle politique de sécurité et on ne reviendra pas dessus. Le client doit mettre à jour ses systèmes. Il n'y a pas de solution alternative. (Ticket fermé par le sysadmin)
              • On ne peut pas demander ça au client, c'est un problème critique de production. Réactivez SSLv3. (Ticket rouvert par le support client)
              • C'est interdit, on ne peut pas faire ça. Je transfère à la hiérarchie pour confirmation. (Ticket envoyé à la hiérarchie par le sysadmin)
              • Je confirme, il est interdit de réactiver SSLv3. C'est la politique de sécurité de l'entreprise, pas de discussion possible. (Ticket fermé par la hiérarchie)

              • [^] # Re: Outil de test + STARTTLS

                Posté par  . Évalué à 2.

                Après cela dépend si vous avez prévenu le client ou pas. J'ose espérer que vous avez réalisé une rapide analyse de qui utilisaient encore SSL3 et que vous leur aviez expliqué que dans un mois cela ne marcherait plus.

                Sinon, je comprends pourquoi le client râle.

                • [^] # Re: Outil de test + STARTTLS

                  Posté par  (site web personnel) . Évalué à 3. Dernière modification le 13 octobre 2015 à 15:44.

                  Après cela dépend si vous avez prévenu le client ou pas

                  Même quand on prévient longtemps à l’avance, les correctifs ne sont jamais fait avant d’avoir plus que dépassé la ligne rouge…

                  Même les root CA à la base de la base de la sécurité de HTTPS se réveillent 3 moins avant une dead-line annoncée depuis 3 ans déjà et annoncent qu’elles dépasseront cette dead-line d’au moins 1 an…
                  Windows XP est toujours en vie et non patchable alors qu’il ne supporte pas autre chose que SSLv3, idem pour les distributeurs de billet…
                  La dette technique est tellement monstrueuse sur le sujet que personne ne souhaite faire d’effort parce que ça lui coûterait trop (en matériel, en développement, en perte de client, de chiffre d’affaire ou de part de marché).

                  Les seules évolutions notables sur le sujet sont toujours venus des navigateurs, et en imposant une décision unilatérale violente (SHA-1, RC4, SSLv3, désactivation des plugins…)

                  • [^] # Re: Outil de test + STARTTLS

                    Posté par  . Évalué à 2.

                    Les seules évolutions notables sur le sujet sont toujours venus des navigateurs, et en imposant une décision unilatérale violente (SHA-1, RC4, SSLv3, désactivation des plugins…).

                    Donc juste pour le web. Pour ce qui est du courriel, vu la variété de clients lourd ce type d'approche est clairement pas possible. Comment peut-on faire pour fortement inciter les autres à passer à des flux de courriel chiffrés

            • [^] # Re: Outil de test + STARTTLS

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

              Point à noter aussi. La NSA vient de dropper le support de AES-128 (AES-256 recommandé) ainsi que de SHA-256 (SHA-384 minimum).

              https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

              Des failles existantes qu’elle connaîtrait et pas nous ? :D

    • [^] # Re: Outil de test + STARTTLS

      Posté par  . Évalué à 2.

      Merci de ton retour.

      Voilà ce que cela donne sur les grands fournisseurs de mails français:

      domaine Score
      bouyguestelecom.fr C
      bouygues-telecom.fr STARTTLS
      free.fr STARTTLS
      aliceadsl.fr STARTTLS
      laposte.net F
      numericable.fr F
      noos.fr M
      Orange.fr F
      wanadoo.fr F
      sfr.fr analyse en cours
      club-internet.fr M
      neuf.fr M
      ovh.net STARTTLS
      gandi.net M

      Seul bouygues-telecom.fr obtient une note au dessus de F, ce qui rejoint le test starttls.info (cf commentaire) par contre google déclare que malgré ça, bouygues-telecom.fr ne chiffre pas les courriels qu'il envoie ou qu'il reçoit. En résumé, ils ont un bon outil mais ne l'utilisent pas.

  • # GPG et TLS, c'est du brol

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

    GPG et TLS, c'est du brol.

    Rien de tel que Mixmaster ou les mails sont coupés en morceaux et mixés.

    On ne peut pas faire confiance aux "relais", que ce soit ton ISP ou ton fournisseur de webmail.

  • # Un pas en avant

    Posté par  . Évalué à 0. Dernière modification le 13 octobre 2015 à 14:22.

    On peut regretter que le gouvernement (après un discours du premier ministre JM Ayrault en 2014), ne rende pas la chose obligatoire ( une charte cela n'engage que ceux qui y croient).

    Faut être optimiste, ça viendra !

Suivre le flux des commentaires

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