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.
- Le communiqué officiel sur le résultat du hum et la proposition qui avait été faite par les dirigeants de l'IETF
- Les excellentes notes de Tim Bray sur les revues de sécurité des principaux protocoles IETF
- Les supports des orateurs à la plénière
- La vidéo de la plénière La partie sur la surveillance commence après 23 minutes environ quand Alissa Cooper monte à la tribune
- Le RFC 6973 sur la vie privée dans les protocoles Internet
- Le groupe IETF perpass qui travaille à identifier les problèmes liés à la surveillance massive, et à trier les solutions (qui seront ensuite étudiées par les groupes de travail spécialisés)
# Et le spam ?
Posté par NumOpen . É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 Stéphane Bortzmeyer (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 NumOpen . É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 claudex . Évalué à 4.
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).
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 NumOpen . Évalué à 0.
Non, tu as l'adresse IP du serveur émetteur mais le correspondant peut être un bot qui usurpe une identité. Et pour l'adresse IP, je ne suis pas sûr non plus que ce soit impossible de la maquiller.
[^] # Re: Et le spam ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Usurper une adresse IP, en TCP (le protocole de transport qu'utilise SMTP) est très difficile, pour un attaquant aveugle (non situé sur le chemin). Cf. RFC 5961 http://www.bortzmeyer.org/5961.html
[^] # Re: Et le spam ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Une réponse plus détaillée en http://www.bortzmeyer.org/usurpation-adresse-ip.html
[^] # Re: Et le spam ?
Posté par Stéphane Bortzmeyer (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 J Avd . É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 Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Et c'est tout ? La résistance aux pannes n'est pas incluse dans la sécurité (elle s'entend en général mal avec l'authenticité et l'intégrité) ?
[^] # Re: Et le spam ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Je ne vois pas non plus la protection de la vie privée dans cette liste très curieuse et très limitée de ce qu'est la sécurité (cette protection s'entend souvent mal avec l'authentification).
[^] # Re: Et le spam ?
Posté par Zylabon . É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 NeoX . É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 stopspam . Évalué à 10.
Seuls les paranoïaques survivent ;)
# Les "petits frères" de l'IETF aussi
Posté par jfmartin . É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 Stéphane Bortzmeyer (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 mathieui (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 Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
De toute façon, il semble bien, vus les derniers changements, que Google Hangouts ne permettra plus bientôt d'interagir avec le reste du monde XMPP (comme c'est déjà le cas de Facebook Chat). En tout cas, Google n'a jamais répondu aux demandes de clarification de sa position.
[^] # Re: Les "petits frères" de l'IETF aussi
Posté par flagos . É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 claudex . É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 Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Sur le problème des métadonnées, voir http://www.bortzmeyer.org/metadonnees.html
[^] # Re: Les "petits frères" de l'IETF aussi
Posté par Goffi (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 Stéphane Bortzmeyer (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.