Journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée

Posté par  . Licence CC By‑SA.
Étiquettes :
11
26
nov.
2015

Gmail vient de publier une étude menée avec les universités du Michigan et de l'Illinois.

Elle révèle que de plus en plus de fournisseurs de courriel envoient les courriels aux abonnés de Gmail via des connexions chiffrées.

Titre de l'image
Depuis Snowden, Google cherche à montrer son engagement dans la vie privée de ses utilisateurs (traduction il n'y a qu'eux et la NSA qui lisent vos courriels). Dans cette optique, ils vont signaler à leurs usagers si le mail reçu a été émis depuis une connexion chiffrée ou pas.

Lien vers l'étude: http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf

Avec le poids qu'a Google, on peut y voir un moyen de pousser à une obligation de proposer TLS dans SMTP, non?

  • # ma grand-mère est morte

    Posté par  . Évalué à 10. Dernière modification le 26 novembre 2015 à 09:19.

    Je ne suis pas un intégriste de la grammaire mais dans un titre ça pique un peu :

    les autres fournisseur s
    de manière chiffr ée

  • # PGP

    Posté par  . Évalué à 9.

    Il y a une seule référence à PGP dans la papier qui dit, dans les grandes lignes, que PGP laisse les méta-datas non chiffrées ce qui n'est pas assez bien, donc l'écarte de l'étude.
    Au final l'étude ne s'intéresse qu'au chiffrement de bout en bout (SSL/TLS, STARTTLS). Le contenue peut toujours être lisible par les robots de google, faut pas déconné quand même.

    • [^] # Re: PGP

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

      Au final l'étude ne s'intéresse qu'au chiffrement de bout en bout

      Non, justement, elle ne s’intéresse qu’au chiffrement de point à point (du client au serveur, d’un serveur à un autre serveur, du serveur au destinataire). Et c’est le seul type de chiffrement auquel les fournisseurs de messagerie peuvent (et doivent) s’intéresser.

      Le chiffrement de bout en bout, c’est de l’expéditeur au destinataire. Et par définition, ce ne peut être que du ressort des utilisateurs finaux.

      Si c’est le fournisseur qui met en place l’utilisation de PGP, ce n’est pas du « bout en bout » — n’en déplaise à certains fournisseurs qui mettent en avant le fait qu’ils utilisent PGP sur leurs serveurs.

      • [^] # Re: PGP

        Posté par  . Évalué à 8.

        En effet meaculpa

      • [^] # Re: PGP

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

        Le chiffrement de bout en bout, c’est de l’expéditeur au destinataire. Et par définition, ce ne peut être que du ressort des utilisateurs finaux.

        Si c’est le fournisseur qui met en place l’utilisation de PGP, ce n’est pas du « bout en bout » — n’en déplaise à certains fournisseurs qui mettent en avant le fait qu’ils utilisent PGP sur leurs serveurs.

        Ça c'est la théorie.

        La pratique c'est qu'une grosse partie des utilisateurs, même en entreprise, utilisent uniquement des webmails parce que "c'est simple", "y a rien à configurer". Dans ce genre de configuration, le support de PGP doit être fait coté serveur également malheureusement.

        • [^] # Re: PGP

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

          le support de PGP doit être fait coté serveur également malheureusement.

          Non, parce que ça ne sert à rien.

          Le but de PGP (ou S/MIME, ou du chiffrement de bout en bout de façon générale) est de protéger le corps du message contre tout le monde, y compris les fournisseurs, jusqu’au destinataire.

          Si le message est (dé)chiffré via PGP sur les serveurs des fournisseurs, cela n’apporte rien de plus par rapport à TLS (qui protège déjà l’ensemble du message — en-têtes + corps — contre tout le monde sauf les fournisseurs).

          PGP côté serveur ne peut servir qu’à attirer des utilisateurs naïfs en leur disant « nous on chiffre avec PGP, confiez-nous vos mails ».

          • [^] # Re: PGP

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

            Bof, t'as audité tout le code source de ton ordi pour vérifier que le texte en clair n'est transféré quelque part ?

            Faire confiance a un fournisseur que tu connais bien ne me semble pas plus débile que faire confiance à des logiciels ?

            • [^] # Re: PGP

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

              C'est un troll, mais bon :

              Tu peux taper ton message sur une machine non connectée, et le chiffrer aussi.

              Tu envoies le message chiffré depuis une autre machine connectée à un réseau.

              Sinon, la confiance c'est celle que tu places dans la communauté qui lit et écrit le code libre de ton OS et de tes logiciels. Le fournisseur que tu « connais bien », il me semble que tu devrais moins lui faire confiance car il te cache tout mais te dis que tout va bien, alors que tes logiciels libres ne te disent rien, mais sont là.

              D'ailleurs, les logiciels cryptographiques sont souvent la cible d'attaques, puisque c'est le but de les tester ainsi. Après, je te déconseille d'utiliser ton propre logiciel par toi et pour toi, car tu devrais moins avoir confiance !

              Bref…

              • [^] # Re: PGP

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

                Non, ça n'était pas un troll, mais une vraie interrogation. Par contre j'aurai dû préciser que je parlais dans le cadre de l'auto-hébergement ou d'hébergement associatif local.

                Comme tu le dis, « la confiance c'est celle que tu places dans la communauté qui lit et écrit le code libre de ton OS et de tes logiciels ». Si je fais confiance à cette communauté, je ne vois pas pourquoi je ne ferai pas confiance à l'asso du coin, surtout que les gens qui sont dans les assos sont souvent aussi des contributeurs d'autres trucs.

                • [^] # Re: PGP

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

                  Si je fais confiance à cette communauté, je ne vois pas pourquoi je ne ferai pas confiance à l'asso du coin

                  Si l'adminsys de l'association te soupçonne de dragouiller sa copine, c'est plus simple de fouiller tes mails dans leur serveur que de faire accepter une backdoor upstream dans Postfix.

        • [^] # Re: PGP

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

          Si c’est le fournisseur qui met en place l’utilisation de PGP, ce n’est pas du « bout en bout »

          Si le fournisseur fournit un client qui parle OpenPGP, ça peut très bien être du bout en bout.

          Apparement pour GMail+Chrome, Google fournit quelque chose : https://linuxfr.org/users/rakoo/journaux/end-to-end-l-extension-pgp-pour-chrome
          J'ai entendu dire qu'il y a des extensions similaires pour Firefox.

          Après ça revient au problème de savoir si tu as confiance en le code que tu fais tourner sur ta machine mais c'est un autre fil de discussion.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: PGP

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

            Si le fournisseur fournit un client qui parle OpenPGP, ça peut très bien être du bout en bout.

            C’est un cas différent.

            Je faisais référence aux fournisseurs qui proposent de générer, stocker, utiliser la clef (prétendument) privée de l’utilisateur sur leurs serveurs.

            C’est une idée très en vogue depuis les révélations de Snowden, elle est souvent présentée comme la solution ultime (forcément, ça utilise PGP, « le programme dont s’est servi Snowden, que même la NSA elle n’a rien pu faire »).

            Exemple dans cette discussion sur la liste de discussion de GnuPG :

            I think you'll find this has been solved for years. The solution is PGP/etc. between mail servers, and TLS/SSL to the user.

            L’emphase est de moi : « PGP pour la communication entre serveurs ». Meh.

            • [^] # Re: PGP

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

              Ce thread soulève un point intéressant : les anti-{spam,virus} et autres filtres ne vont pas bien fonctionner tant que le message est chiffré.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: PGP

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

                Si l’on parle du vrai chiffrement de bout en bout (PGP ou S/MIME (dé)chiffré par l’utilisateur final), alors oui, complètement.

                Pour le spam, je doute que ce soit un gros problème, ça m’étonnerait que les spammeurs s’amusent à chiffrer leurs messages quand leur but est d’en envoyer le plus possible au plus de monde possible (déjà qu’ils ne prennent pas la peine de respecter le protocole SMTP correctement — c’est ce qui rend possible le greylisting par exemple).

                En revanche, le chiffrement de bout en bout pourrait permettre à un attaquant de contourner des protections anti-spear-phishing, où l’attaquant envoie à une cible bien précise un message chiffré contenant, par exemple, un fichier PDF vérolé (que l’antivirus sur le serveur de réception ne détectera évidemment pas).

                • [^] # Re: PGP

                  Posté par  . Évalué à 2.

                  Les spammers feront ce qu'il faut pour envoyer leur mail …
                  Si cela te permet d'éviter les filtres antispams, ils le feront même surement très vite.

                  • [^] # Re: PGP

                    Posté par  . Évalué à 2.

                    L'immense majorité du spam est filtré par des règles relativement basiques.
                    Donc soit ils ne font pas ce qu'il faut (parce qu'ils s'en foutent, ce qui passe suffit largement), soit… c'est tout.

                    • [^] # Re: PGP

                      Posté par  . Évalué à 3.

                      Cela marche peut-être aussi facilement pour des particuliers, mais les ISPs ou les boites comme Gmail ont des systèmes pour détecter le spam qui sont extrêmement complexes.
                      Vade Retro est un nom assez connu dans le monde de l'antispam et leur système semble extrêmement poussé, par exemple il va jusqu'à analyser la couleur du texte par rapport à son background pour vérifier que le texte est lisible.

                      • [^] # Re: PGP

                        Posté par  . Évalué à 2.

                        Ils nous ont installé ça dernièrement … quel plaie !
                        Impossible de by-passer le système, quand on a une bonne gestion de sa boite mail pro on a pas 36 tonnes de pub, voir pas du tout. Un mail de récap par jour seulement ! Impossible d'en mettre plus ! Du coup certain mails sont bloqués pendant une journée sans raison !!!! A moins d'avoir l’œil collé a leur interface assez austère d’ailleurs.
                        Je ne sais pas si c'est l'install qui a été mal faite mais la politique du «je bloque tout et dite moi ce qui est bon» est une vrai catastrophe …

                        Au final une grosse part des utilisateurs se plaignent, comme quoi ils portent bien leur nom … Vade Retro

                        • [^] # Re: PGP

                          Posté par  . Évalué à 2.

                          Je ne me suis pas occupé de l'implémentation chez nous, mais chez nous il renseigne simplement un header.

  • # TLS obligatoire ?

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

    Avec le poids qu'à Google, on peux y voir un moyen de pousser à une obligation de proposer TLS dans SMTP, non?

    Hum, non.

    Si Google voulait rendre TLS obligatoire, il n’aurait qu’à configurer ses serveurs pour interdire les connexions en clair.

    Cette étude sert plutôt à expliquer au contraire pourquoi ils ne peuvent pas le faire — à cause de la « longue traîne » de fournisseurs de messagerie (modestes individuellement, mais représentant collectivement une part non-négligeable du traffic) qui sont incapables d’utiliser TLS.

    On peut toujours espérer que cette étude poussera quelques-uns de ces fournisseurs à se bouger et à améliorer leur prise en charge de TLS, mais je ne me fais pas beaucoup d’illusions.

  • # DANE

    Posté par  . Évalué à 5.

    Ils parlent de DANE dans l'étude, en expliquant bien que l'état actuel de STARTTLS ne permet de valider le certificat (et donc le MitM est facile1), ce que DANE permet (et la bortzRFC). Ce serait bien que Google le mette en place. Ça pousserait sans doute plein de gens à le mettre en place.

    Actuellement, j'ai la flemme de le configurer sur mon serveur vu que de toute façon, mes correspondant son chez gmail, donc ça ne sera pas utilisé.

    1. pour une certaine définition de facile ↩

    « 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: DANE

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

      Ce serait bien que Google le mette en place.

      Aucune chance. Google se moque éperdument de DANE.

      • Aucune zone dépendant de Google (google.com, gmail.com, youtube.com, etc.) n’est signée. Pour Google, DNSSEC (dont DANE dépend : un enregistrement TLSA ne sert à rien s’il n’est pas signé) n’existe pas. Raison avancée : il y a trop de RSA 1024-bits dans DNSSEC, et ce n’est pas assez fort à leur goût.

      • Google promeut à la place son propre Certificate Transparency (qui ne résoud aucun problème), qui s’oppose explicitement à la possibilité offerte par DANE d’utiliser des certificats qui ne soient pas émis par des CA reconnues. Le site de CT peut bien prétendre que DANE could also be used with CT, ce n’est vrai que si DANE est utilisé pour publier un certificat émis par une CA participant à CT (donc les mêmes CA que celles acceptées par les navigateurs). Les logs CT refusent d’enregistrer les certificats émis de façon indépendante.

      • Google n’hésite pas à faire preuve de mauvaise foi quand il s’agit de promouvoir Certificate Transparency par rapport à DANE, par exemple lorsqu’ils affirment que « DANE nécessite de modifier les serveurs » parce qu’il faut bien « servir les enregistrements DNS nécessaires » — faisant semblant d’oublier que ① n’importe quel service web a déjà besoin d’un serveur DNS pour distribuer son adresse, ② n’importe quel serveur DNS est déjà capable de servir des enregistrements TLSA, ③ Certificate Transparency de son côté nécessite rien de moins que de modifier le format X.509 (ajout d’une extension représentant le jeton CT), le protocole TLS (ajout d’une extension pour fournir le jeton CT), le protocole OCSP (idem), et les clients qui doivent supporter toutes ces extensions…

      Bref, si tu veux du DANE, tu auras plus vite fait de le mettre en place toi-même que d’attendre que GMail le fasse. Je l’ai fait, ce n’est pas trivial mais ça ne demande pas non plus d’être ingénieur chez Google.

      • [^] # Re: DANE

        Posté par  . Évalué à 7.

        Pour Google, DNSSEC (dont DANE dépend : un enregistrement TLSA ne sert à rien s’il n’est pas signé) n’existe pas.

        Cependant, leurs résolveurs valident bien DNSSEC, cela prouve bien qu'ils en tiennent compte.

        Google promeut à la place son propre Certificate Transparency

        Uniquement pour le HTTPS, ici je parlais du SMTP qui, avec STARTTLS ne permet aucune vérification du certificat (vu qu'il n'y a pas de nom définit pour le HTTPS). Et je pense que les équipe SMTP et HTTPS sont distinctes chez Google, la première peut vouloir changer des choses.

        Le site de CT peut bien prétendre que DANE could also be used with CT, ce n’est vrai que si DANE est utilisé pour publier un certificat émis par une CA participant à CT (donc les mêmes CA que celles acceptées par les navigateurs)

        Et ce serait déjà une belle avancée pour la sécurité.

        Bref, si tu veux du DANE, tu auras plus vite fait de le mettre en place toi-même que d’attendre que GMail le fasse.

        Je pense que tu as mal lu mon message. Je dis que ça ne sert à rien de le mettre en place vu que si eux ne le font pas, il n'y pas d'échange mail qui en tiendront compte. Alors que s'ils le mettent en place, c'est une bonne motivation.

        « 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: DANE

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

          Et je pense que les équipe SMTP et HTTPS sont distinctes chez Google, la première peut vouloir changer des choses.

          Traite-moi de pessimiste, mais j’en doute, considérant que dans le papier dont on parle :

          • DNSSEC n’est mentionné que pour dire qu’on ne peut pas trop compter dessus (“DNSSEC has not been widely deployed — ben forcément, tout le monde attend que vous le fassiez d’abord, hé patate ! — and so operators cannot rely on this protection” — au cas où quelqu’un aurait un doute, l’incise est de moi) ;

          • DANE n’est mentionné qu’en passant (“Without additional security add-ons (e.g., DANE), this attack remains a real threat.”) ;

          • les deux seules approches évoquées dans les solutions possibles sont un mécanisme de type HPKP (épinglage des clefs publiques pendant le dialogue SMTP, protégeant les connexions futures) ou… Certificate Transparency.

          Je maintiens : il n’y a probablement rien à attendre de Google pour tout ce qui touche à DNSSEC et DANE, ce n’est simplement pas dans leur agenda.

          • [^] # Re: DANE

            Posté par  . Évalué à 3.

            DANE n’est mentionné qu’en passant (“Without additional security add-ons (e.g., DANE), this attack remains a real threat.”) ;

            Et c'est la seule méthode qui permet d'éviter le MitM avec STARTTLS.

            Certificate Transparency

            Qui ne résoud pas le problème de SMTP avec TLS, c'est-à-dire : quel nom d'hôte on vérifie.

            Je maintiens : il n’y a probablement rien à attendre de Google pour tout ce qui touche à DNSSEC et DANE, ce n’est simplement pas dans leur agenda.

            Ça ne coûte rien d'espérer.

            « 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: DANE

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

            Pour information, Viktor Dukhovni, co-auteur du RFC 7672 sur DANE pour SMTP et développeur de l’implémentation correspondante dans Postfix, a publié quelques stats sur la liste dane-users@sys4.de. Les archives de la liste ne sont malheureusement pas accessibles aux non-inscrits, mais en gros :

            • 9389 domaines signés avec des enregistrements TLSA pour SMTP
            • dont plus de la moitié étant gérés par l’hébergeur UD Media ;
            • dont un des plus gros FAI américains, Comcast ;
            • dont 28 domaines considérés comme suffisamment « gros » pour figurer dans les rapports de Google, parmi lesquels :
              • lepartidegauche.fr
              • societe.com
              • bayern.de
              • comcast.net
              • debian.org
              • eu.org
              • freebsd.org
              • ietf.org
              • isc.org
              • netbsd.org
              • openssl.org
              • samba.org
              • torproject.org

  • # Hypocrisie

    Posté par  . Évalué à 6.

    Quelle hypocrisie venant de l'entreprise qui ne supporte la fédération XMPP que si la connexion n'est pas chiffrée.

  • # Du poids de Google Mail chez les visiteurs/contributeurs de LinuxFr.org

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

    Sur les 3 derniers mois :

    • les comptes utilisés sont à 36% en @gmail.com1 ;
    • les comptes ayant commenté au moins une fois sont à 30% en @gmail.com2 ;
    • les comptes ayant écrit un contenu sont à 32% en @gmail.com3 ;
    • pas mal de nos spammeurs ont des adresses @gmail.com aussi…

    (1) domaines des adresses de courriel des 3272 comptes utilisés dans les 90 derniers jours

    +-------------+------+----------+
| domain      | cnt  | pct      |
+-------------+------+----------+
| gmail.com   | 1165 | 35.60513 |
| free.fr     |  386 | 11.79707 |
| yahoo.fr    |  164 |  5.01222 |
| laposte.net |  121 |  3.69804 |
| hotmail.com |   80 |  2.44499 |
| hotmail.fr  |   57 |  1.74205 |
| wanadoo.fr  |   32 |  0.97800 |
| orange.fr   |   32 |  0.97800 |
| yahoo.com   |   24 |  0.73350 |
| no-log.org  |   19 |  0.58068 |
+-------------+------+----------+

    (2) domaines des adresses de courriel des 1341 comptes utilisés pour commenter dans les 90 derniers jours

    +-------------+-----+----------+
| domain      | cnt | pct      |
+-------------+-----+----------+
| gmail.com   | 396 | 29.53020 |
| free.fr     | 171 | 12.75168 |
| laposte.net |  59 |  4.39970 |
| yahoo.fr    |  57 |  4.25056 |
| hotmail.com |  34 |  2.53542 |
| hotmail.fr  |  23 |  1.71514 |
| wanadoo.fr  |  11 |  0.82028 |
| yahoo.com   |  10 |  0.74571 |
| no-log.org  |  10 |  0.74571 |
| orange.fr   |   9 |  0.67114 |
+-------------+-----+----------+

    (3) domaines des adresses de courriel des 469 comptes utilisés pour écrire un contenu dans les 90 derniers jours

    +-------------+-----+----------+
| domain      | cnt | pct      |
+-------------+-----+----------+
| gmail.com   | 148 | 31.55650 |
| free.fr     |  47 | 10.02132 |
| yahoo.fr    |  23 |  4.90405 |
| hotmail.com |  15 |  3.19829 |
| laposte.net |  14 |  2.98507 |
| hotmail.fr  |  10 |  2.13220 |
| orange.fr   |   6 |  1.27932 |
| live.fr     |   5 |  1.06610 |
| yopmail.com |   5 |  1.06610 |
| wanadoo.fr  |   4 |  0.85288 |
+-------------+-----+----------+

Suivre le flux des commentaires

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