Journal L'IETF se lance dans la lutte contre l'espionnage

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
43
7
nov.
2013
Ce journal a été promu en dépêche : L’IETF se lance dans la lutte contre l’espionnage.

Des tas de gens et d'organisations ont été secoués par les révélations du héros Edward Snowden concernant l'ampleur de l'espionnage réalisé par la NSA (et, certainement, par bien d'autres organisations). Bien sûr, les experts en sécurité savaient depuis longtemps mais ils avaient le plus grand mal à se faire entendre, les dirigeants et les utilisateurs préféraient se moquer de ces experts, en les qualifiant de paranoïaques. Les révélations de Snowden ont montré que les paranoïaques ne l'étaient en fait pas assez et que l'ampleur de l'espionnage dépassait les pires prévisions.

Cela a nécessité des changements de direction à pas mal d'endroits. Par exemple, l'IETF, l'organisation qui établit les normes techniques de l'Internet. Traditionnellement, elle se préoccupait peu de vie privée, parfois considérée comme « un problème politique, ce n'est pas pour nous ». Cela a changé dans les dernières années mais les révélations Snowden ont mené à une brusque accélération. À la réunion de l'IETF à Vancouver, du 3 au 8 novembre, on a donc beaucoup parlé de vie privée. Tous les groupes de travail avaient consacré du temps à un examen de leurs protocoles, sous l'angle de la protection de la vie privée. Et la plénière technique du 6 novembre, avec Bruce Schneier en invité vedette, avait été entièrement consacré à cette question. La décision la plus spectaculaire a été l'accord très large de l'IETF (par le biais du fameux "hum", l'IETF n'ayant pas de procédures de vote) pour se lancer à fond dans cette voie.

  • # Et le spam ?

    Posté par  . Évalué à -9.

    Si en même temps, ils pouvaient implémenter dans les protocoles des mécanismes efficaces contre le spam, ça ferait 2 gros problèmes réglés.

    • [^] # Re: Et le spam ?

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

      Sauf que cela n'a rien à voir et qu'en matière d'ingéniérie, tout mélanger n'est pas la meilleure façon d'avancer.

      • [^] # Re: Et le spam ?

        Posté par  . Évalué à 1. Dernière modification le 08 novembre 2013 à 22:33.

        Je pense que c'est lié. Sécuriser les protocoles de communication inclut notamment de bien identifier ses correspondants et cela permettra de lutter contre le spam.
        Par exemple, j'étais tout le temps embêté par les appels publicitaires des centres d'appels avec des numéros cachés. Depuis que j'ai la Freebox, je bloque les appels anonymes et je suis tranquille.

        • [^] # Re: Et le spam ?

          Posté par  . Évalué à 4.

          Je pense que c'est lié. Sécuriser les protocoles de communication inclut notamment de bien identifier ses correspondants et cela permettra de lutter contre le spam.

          Je ne comprends pas du tout ton raisonnement. Par exemple, la communication entre moi et LinuxFr.org est chiffrée (SSL/TLS) et donc sécurisée mais le serveur ne peut pas m'identifier, ni me différencier d'un bot. Et le but du mail, c'est quand de pouvoir recevoir des messages de n'importe qui (et heureusement).

          Par exemple, j'étais tout le temps embêté par les appels publicitaires des centres d'appels avec des numéros cachés. Depuis que j'ai la Freebox, je bloque les appels anonymes et je suis tranquille.

          Il n'y a pas de mail anonyme avec SMTP, tu as toujours au moins l'adresse IP du serveur de ton correspondant-

          « 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: Et le spam ?

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

          Euh, pas d'accord. Le verbe « sécuriser » est bien trop vague et décrit des tas de choses différentes et incompatibles. Dans le contexte de cet article, on parlait surtout de protection de la vie privée. Cela peut mener à des techniques comme les communications « sourceless » où on ne saurait pas qui nous parle. Excellent pour la vie privée, pas génial pour refuser le spam. Non, faut pas se faire d'illusions, il y aura des choix à faire.

          • [^] # Re: Et le spam ?

            Posté par  . Évalué à 1.

            sécurisé dans le cadre de la communication:
            1- authenticité
            2- intégrité
            3- confidentialisé

            c'est pas compliqué :-)

            "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Et le spam ?

      Posté par  . Évalué à 10. Dernière modification le 07 novembre 2013 à 21:28.

      Le problème du spam a l'air difficilement soluble quand même… On ne peut pas vouloir à la fois que tout le monde puisse nous envoyer des messages et que certaines personnes ne le puissent pas…

      Please do not feed the trolls

    • [^] # Re: Et le spam ?

      Posté par  . Évalué à 7.

      si deja tous les emetteurs utiliser SPF et DKIM
      ET
      que tous les recepteurs faisaient les controles de base (reverse IP, SPF, DKIM)

      seulement comme ca refuse encore certains emails legitimes, on desactive parfois les controles
      du coup le spam continue de circuler.

  • # Phrase célèbre

    Posté par  . Évalué à 10.

    les dirigeants et les utilisateurs préféraient se moquer de ces experts, en les qualifiant de paranoïaques

    Seuls les paranoïaques survivent ;)

  • # Les "petits frères" de l'IETF aussi

    Posté par  . Évalué à 5.

    D'autres organisations gravitant autour de l'IETF et des standards d'Internet sont aussi concerné.
    Par exemple, je viens de tomber sur un message de la XMPP Standards Foundation pour proposer de rendre obligatoire le chiffrement de communication sur le réseau.

    • [^] # Re: Les "petits frères" de l'IETF aussi

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

      C'est évidemment une excellente idée (Peter St Andre a été très applaudi à la réunion IETF) mais attention, le chiffrement ne protège qu'en transit. Si on a Google Hangouts comme serveur XMPP, la NSA a quand même toutes les infos, puisque c'est Google qui leur donne. Donc, il faut utiliser un serveur XMPP non-PRISM.

      • [^] # Re: Les "petits frères" de l'IETF aussi

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

        À noter que si le draft (http://tools.ietf.org/html/draft-saintandre-xmpp-tls-02) et le manifeste deviennent relativement courants, il sera impossible de dialoguer avec un contact google, puisqu’ils ne fournissent pas de chiffrement en server-to-server (même « opportuniste » aka pas de vérification de certificat).

      • [^] # Re: Les "petits frères" de l'IETF aussi

        Posté par  . Évalué à 3.

        Et comme pour l'email, il faut egalement que nos contacts ne soient pas sur un serveur XMPP prism-compatible…

      • [^] # Re: Les "petits frères" de l'IETF aussi

        Posté par  . Évalué à 4.

        Sans compter que les métadata sont quand même en clair.

        « 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: Les "petits frères" de l'IETF aussi

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

        le chiffrement s2s et c2s n'est qu'une partie qui ne protège pas des administrateurs des serveurs (donc Google ici), il faut au minimum ajouter le chiffrement de bout en bout (OTR/GPG), et encore ça ne résout pas tout (on sait toujours à qui et quand on écrit - bref les informations de routage -, le volume approximatif du message, etc.).

        Même en dehors de l'affaire PRISM, le fait que les messages soient en clair côté serveur peut poser problème si on ne l'administre pas nous même, ou si on n'a pas une confiance extrême en l'équipe qui administre. D'ailleurs faire administrer un serveur par quelqu'un de proche (famille, association proche, etc), peut inciter plus facilement à jeter un œil aux logs (petit(e) ami(e) jaloux par exemple).

        S'ajoute à ça des problèmes qui ne sont pas forcément encore pris en compte dans XMPP: l'usage actuel des clients qui gère le chiffrage de bout en bout chiffre les messages texte, mais pas les données supplémentaires (par exemple texte riche avec XHTML-IM).

        La situation semble être en passe de s'améliorer (XEP-0200 par exemple, enfin faudrait que je vois ça plus en détails pour être sûr), il faut voir comment ça évolue en particulier du côté des clients.

  • # Mon compte-rendu de la plénière

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

    http://www.bortzmeyer.org/ietf-securite-espionnage-bis.html

Suivre le flux des commentaires

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