Aujourd'hui, surtout en plein scandale PRISM, la vie privée est un sujet important et pris au sérieux. Mais, historiquement, la plupart des protocoles de la famille TCP/IP, à la base de l'Internet, ont été conçus sans tenir compte des questions de vie privée et certains de ces protocoles sont donc excessivement iniscrets. L'IETF tente de changer la tendance et d'améliorer les choses pour les futurs protocoles.
C'est ce que propose le tout nouveau RFC 6973 "Privacy Considerations for Internet Protocols". Plein d’intéressants exemples et discussions, je crois que c'est une bonne lecture pour les ingénieurs et étudiants en réseaux informatiques.
Le RFC : http://www.rfc-editor.org/rfc/rfc6973.txt
Mon résumé en français : http://www.bortzmeyer.org/6973.html
# "Code is law"
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est intéressant de rapprocher cette expression
« bof, c'est de la politique, ça ne nous concerne pas, et d'ailleurs la technique est neutre »
A celle de Lawrence Lessig : "Code is law".
"La première sécurité est la liberté"
[^] # Re: "Code is law"
Posté par Spack . Évalué à 3.
Ou à celle des pirates des caraïbes:
http://www.youtube.com/watch?v=Y6OvsJqimfg
--> []
# protocoles
Posté par Nico C. . Évalué à 3.
Pour moi, les protocoles, c'est une chose importante, soit. Mais dans le cadre de PRISM, leur securisation n'a aucune importance ou presque puisque la NSA est branchée directement chez le fournisseur du service.
Le vrai probleme avec PRISM est : quelles garanties sur nos données pouvons nous avoir des services online ? Quelles garanties pouvons nous avoir d'un service online hebergé aux USA ?
Et meme si le service online garantit un cryptage des données (comme Dropbox ou Apple iCloud par exemple), comment pouvons nous être sur que c'est bien le cas ET que nous sommes vraiment les seuls a accéder a nos données ? Que peut mettre en place un service online pour nous donner la possibilité de verifier ? Quels sont les criteres qui me permettrait d'etre sur que je suis le seul a acceder a mes données ?
Ensuite effectivement, il y a la problematique des protocoles mais je pense que meme si c'est loin d'etre parfait, il y a deja pas mal de matiere sur le sujet.
[^] # Re: protocoles
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
A coté de prism, il semble y avoir un paquet de connexions sur les points d’interconnexion ou sur les câbles sous-marins. PRISM n'est pas le seul problème.
Concernant le cryptage dans le cloud, il suffit que la clef ne soit jamais dans les mains du fournisseur, et donc de crypter soi-même.
"La première sécurité est la liberté"
[^] # Re: protocoles
Posté par Nico C. . Évalué à 1. Dernière modification le 25 juillet 2013 à 10:35.
Ouais mais il me semble que tu parles juste d'un bete stockage sur disque comme un Dropbox par exemple. Effectivement, dans ce cas, c'est tout a fait possible de gerer soi meme le cryptage mais comment faire dans le cadre de services comme facebook, flickr, etc qui sont un peu plus qu'un bete stockage ?
Ou alors il faudrait pondre des protocoles applicatifs qui garantissent la securité des données jusqu'au niveau du stockage (en base) ainsi le fournisseur du service pourrait mettre en place un service mais seulement en manipulant des données securisées auxquelles il n'a aucun acces.
Mais je ne sais pas si y'a des travaux de genre qui existent ni meme ca pourrait etre techniquement envisageable…
[^] # Re: protocoles
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
A moins d'avancé majeurs des les fonctions de manipulations de donnés crypté, c'est la loi qui fera le ménage.
Il faut le consentement des personnes pour revendre leur données, c'est le minimum. L'Europe est en pleine discussion actuellement sur le sujet.
"La première sécurité est la liberté"
[^] # Ayant-droits ?!
Posté par Yannick (site web personnel) . Évalué à 2.
En gros, tu viens de comprendre le style de problématique des ayants-droits, pour la musique par exemple…
C'est ça que je trouve amusant (quoique), sur ce sujet, au final. On a le même problème qu'eux : Garantir que l'on fait ce qu'on veux bien avec nos données. Même (surtout) si elle sont dans la nature…
[^] # Re: Ayant-droits ?!
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Cela n'a rien avoir. Les ayants droit ont vendu leur support. Nous n'avons rien vendu du tout.
"La première sécurité est la liberté"
[^] # Re: Ayant-droits ?!
Posté par Yannick (site web personnel) . Évalué à 1.
Je ne vois pas en quoi la vente ou non intervient dans la question. Ou alors tu parle du fait que, comme t'as payé la musique, tu ne veux pas de limite dessus. Je suis d'accord sur ce point. D'ailleurs, dans la remarque, je pensait plus à la musique piratée qu'à la musique achetée.
A partir de là, on glisse vers le débat "Es-ce une bonne idée de pouvoir contrôler des données diffusées après diffusion ?". Ça dépends : Pour les photos personnelles tu va dire oui, pour la musique achetée, non, pour un code source libre, non. La maison de disque qui voit de la musique copiée, le gros éditeur de logiciel qui rachète la start-up, ne sont pas forcement du même avis. Et si en plus il faut faire le distinguo entre la musique acquise légalement ou pas…
J'ai bien peur, qu'en dehors du problème technique, on a un problème philosophique qui pointe le bon de son nez.
[^] # Re: protocoles
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Le "il suffit" est trop court. Il faut aussi être sûr du logiciel, donc, au minimum, logiciel libre, sinon, aucune sécurité.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 27 juillet 2013 à 10:56.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: protocoles
Posté par Adrien . Évalué à 2.
Dans PRISM, il y a également la question de la surveillance de masse. Est-il bon qu'une entité puisse pratiquer un espionnage massif d'internet, même uniquement sur les données publique ?
Là on touche aux questions fondamentales du contrôle d'internet, de sa décentralisation.
[^] # Re: protocoles
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6.
Oui, j'ai peut-être eu tort de mentionner PRISM, c'était pour attirer l'attention mais, en effet, techniquement, c'est un problème différent.
Par contre, c'est tout à fait faux de dire qu'il y a déjà "pas mal de matière sur le sujet [les protocoles]" ou alors il faut citer des références. Pour le DNS, par exemple, je n'ai jamais rien vu.
Enfin, "cryptage" n'est pas le bon mot http://www.bortzmeyer.org/cryptage-n-existe-pas.html
[^] # Re: protocoles
Posté par Nico C. . Évalué à 0.
Les "grands" protocoles comme HTTP, FTP, SMTP, POP, XMMP, etc ont leur declinaison securisée par du SSL/TLS. Je crois savoir que DNSSEC existe mais je ne sais presque rien a son sujet ni meme si il est deployé a large echelle.
De meme, d'apres ce que je sais, IPv6 dispose de fonctionnalités de securisation tres avancees…
[^] # Re: protocoles
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6.
Et en quoi est-ce que TLS va protéger la vie privée ? Il y aura la requête DNS, les adresses IP utilisées et même (cf. mon article, qui notait ce point du RFC) le fait que cette machine s'était déjà connectée… Bref, TLS ne protège que le contenu, ce qui est déjà pas mal mais n'est pas le sujet du RFC, qui se focalise sur les méta-données, bien plus dures à protéger.
DNSSEC garantit l'authenticité des requêtes, mais ne fait rien pour la confidentialité.
Quant à IPv6, non, il a pile la même sécurité qu'IPv4 http://www.bortzmeyer.org/ipv6-securite.html
[^] # Re: protocoles
Posté par Nico C. . Évalué à 1.
oui oui j'ai bien compris. C'est pour ca que je dis "meme si c'est loin d'etre parfait, il y a deja pas mal de matiere sur le sujet".
Pour IPv6, je croyais qu'une déclinaison d'IPsec était intégrée au protocole. Visiblement, je me trompe. Et idem, ca ne resout pas le probleme soulevé par la RFC en question ni le problème de la "collaboration" des services avec les agences indiscrètes.
Après, j'ai du mal a imaginer comment pouvoir proteger les informations de destination au moins. Meme sur un courrier le plus sensible au monde, il faut bien indiquer en clair le destinataire…
[^] # Re: protocoles
Posté par reno . Évalué à 2.
Je crois que ça a été le cas puis après c'est devenu optionnel, pas vraiment surprenant: les agences de sécurité du monde entier n'aime pas le chiffrage par défaut: ça rend leur travail plus compliqué.
Non, tu peux "cacher" le message dans un fichier a large diffusion (stéganographie) mais bon
1) il reste le problème de l'échange des clefs
2) ce n'est pas efficace 1) il faut que ton message représente un petit pourcentage du fichier autrement ça va se voir.
3) ce n'est pas efficace 2) on voit mal des millions d'utilisateurs utiliser ce mécanisme comme ça se passe pour l'email.
# Protocole indiscret ?
Posté par cfx . Évalué à 4.
J'ai un peu de mal à saisir le concept de "protocole indiscret" :
Sinon, quand je lis :
et :
je me dis que cela va devenir compliqué…
[^] # Re: Protocole indiscret ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Un exemple est fourni par IP lui-même. Le mode non-connecté fait qu'il faut mettre l'adresse IP source dans chaque paquet (il faut bien que les réponses et les avis de non-remise soient transmis). Donc, le destinataire connait l'adresse IP source. Ce n'était pas obligatoire. X.25 avait un autre système où le réseau établissait la connexion et où le destinataire ne connaissait pas forcément le numéro de l'appelant (merci à Rémi Desprès pour ses explications à ce sujet).
Mon but n'est pas de dire qu'il faut revenir à X.25 :-) simplement de montrer qu'il y a eu des choix, qu'ils n'étaient pas obligatoires (« une autre technique est possible ») et que ces choix ont des conséquences pour la vie privée. C'est le thème principal de ce RFC : un protocole n'est pas purement technique.
Autre exemple, le DNS : le résolveur transmet au serveur faisant autorité la totalité de la requête, pas juste le domaine pour lequel le dit serveur fait autorité. Le serveur de la racine sait ainsi qu'on regarde linuxfr.org. Il y a des bonnes raisons pour cela (le problème est en effet complexe, ici, la bonne raison, c'est le fait que le résolveur ne connaisse pas les "zone cuts") mais d'autres protocols faisaient différemment.
[^] # Re: Protocole indiscret ?
Posté par cfx . Évalué à 2.
Oui, mais si j'ai bien compris, comme de toute façon on ne peut pas faire confiance au réseau qui peut être écouté, quand bien on peut avoir un protocole avec lequel le destinataire ne connait pas l'adresse de l'appelant, un mec bien placé qui écoute la communication peut avoir l'info qu'il faut. Alors certes, le problème n'est peut-être pas forcément le même, l'info n'est pas récupérée par la même personne (destinataire vs. écoutant), mais au final ça change rien au problème de respect de la vie privée…
[^] # Re: Protocole indiscret ?
Posté par claudex . Évalué à 3.
Sauf si tu chiffre. Dans le cas d'HTTPS par exemple, l'écoutant ne sait rien de la conversation mais le destinataire, oui.
« 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: Protocole indiscret ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Mais si, l'écoutant sait des choses, même avec TLS, comme le fait qu'il y a une communication, combien d'octets sont échangés et même (avec la reprise de session) si ce client était déjà passé.
Le RFC se focalise sur la discrétion des protocoles. La question de la protection du contenu est déjà bien connue, celle des protocoles semble avoir été pas mal négligée.
[^] # Re: Protocole indiscret ?
Posté par claudex . Évalué à 3.
Évidemment, ce que je voulais dire, c'est qu'il y a moyen de protéger le message de l'écoutant (mais pas les métadata).
« 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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9. Dernière modification le 27 juillet 2013 à 14:22.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Protocole indiscret ?
Posté par Arthur Accroc . Évalué à 2.
Un contre-exemple justement à propos du courriel a déjà été présenté ici-même.
Par contre, il illustre qu’envoyer quelque chose à un destinataire sans indiquer comment le joindre (et sans serveur centralisé) est plus compliqué…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Protocole indiscret ?
Posté par cfx . Évalué à 2. Dernière modification le 25 juillet 2013 à 13:13.
Si mes souvenirs sont bons, Bitmessage c'est : « on broadcast (à un groupe), et décode celui qui peut » ?
En effet, c'est une solution pour certains points évoqués.
Cependant, en mettant de coté l'aspect chiffrement sur lequel repose Bitmessage, si la solution au respect de la vie privée est le broadcast, il y a pour moi comme un problème conceptuel…
[^] # Oui, mais que faire ?
Posté par Arthur Accroc . Évalué à 5.
D’un autre côté, il n’y a pas 36 possibilités.
– Tu communiques directement avec le destinataire. Ton FAI, donc Thalès (bientôt) et les barbouzes du gouvernement (déjà) sont au courant de votre relation.
– Tu utilises un service centralisé. L’opérateur du service, donc les barbouzes US (typiquement, pour un service situé aux États-Unis) sont au courant (voire les entreprises US si le renseignement a un intérêt commercial).
– Tu l’envoies « dans la nature ». Il est beaucoup plus difficile de déterminer qui est le destinataire prévu, mais quant au contenu, tu ne peux qu’espérer que ton chiffrement tienne (au moins jusqu’à ce que le contenu n’ait plus d’intérêt)…
– Tu utilises une infrastructure d’anonymisation non triviale, comme Tor. Problème : Tormail ne répond pas aujourd’hui. Problème supplémentaire : certains opérateurs Tor peuvent ne pas être bien intentionnés (pirates, barbouzes), donc là encore, tu as intérêt en ce qui concerne le contenu à ce que ton chiffrement tienne…
Évidemment, si l’on considère la situation actuelle, protéger le contenu des regards indiscrets serait déjà un grand pas (même sans cacher les relations).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Je pige pas là..
Posté par Ely . Évalué à -4.
Depuis quand c'est aux protocoles et non pas aux applications de faire attention aux données qui transitent ?
[^] # Re: Je pige pas là..
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Il faut lire le RFC (ou mon résumé) qui justement explique cela. Indication : il n'y a pas que les données, les méta-données sont très sensibles aussi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.