Essayer de créer un site Web sûr où la sécurité est gérée par le site Web et non par l'utilisateur
Je travaille avec les droits civils des enfants et des jeunes et j'essaie de créer un site Web pour les jeunes et les enfants LGBT et leurs familles. Le site Web doit être sûr car il est encore très dangereux dans de nombreux pays d'admettre être gay (ou LGBTQ).
J'ai une série de courts métrages pour enfants que je voudrais rendre accessibles gratuitement sur un site Web, mais les jeunes, les familles et les enseignants qui accèdent au site doivent être introuvables.
Puis-je créer un site Web où la sécurité réside dans le site Web?
Les personnes et les enfants qui viennent sur le site ne mettront pas en place leurs propres mesures de sécurité pour ne pas être retracés.
Ne le faites pas
Si vous ciblez des régimes dangereux, les conséquences peuvent être graves. Par exemple, en Iran, les homosexuels condamnés sont généralement condamnés à mort par pendaison.
Il ne faudrait que la moindre défaillance de la part de votre site ou de l'un de vos utilisateurs pour que ce soit une preuve incriminante. Pouvez-vous imaginer la culpabilité que vous ressentiriez que votre site bien intentionné a fini par être une preuve qui a conduit à une exécution?
Pour opérer en ligne de manière subversive dans un régime répressif, il faut une extrême habileté et prudence. Utiliser Tor serait un drapeau rouge en soi. Bien que les groupes de pirates comme anonymes puissent s'en tirer, les utilisateurs normaux ne le peuvent pas.
Il y a eu des commentaires sur d'autres réponses disant (grosso modo) "utilisez HTTPS, ça va". Je ne saurais trop insister sur le fait que ce conseil est dangereux. HTTPS révèle le nom de domaine auquel l'utilisateur accède, il laisse des traces sur l'ordinateur client, et il est probable que les États-nations (y compris l'Iran) peuvent produire faux certificats et intercepter tout le trafic HTTPS.
Ce n'est pas une chose facile à faire. Il existe plusieurs façons d'obtenir quelque chose comme ce que vous voulez.
Tout d'abord, utilisez HTTPS. Cela empêche quiconque de voir les données transférées autres que le serveur et l'utilisateur (qui, je suppose, sont tous deux propres). Cela n'empêche pas les personnes externes de voir que l'utilisateur a visité le site, uniquement les données exactes qui sont transférées.
Si vous avez des choses cachées derrière un écran de connexion, toute personne sans connexion visitant le site ne pourra pas voir de quoi il s'agit. Ce n'est pas très bon car vous devez faire confiance aux utilisateurs qui ont des informations de connexion et vous devez trouver un moyen de recruter des personnes de confiance pour consulter le site.
Une meilleure façon est d'avoir un contenu "normal" pour cacher l'autre contenu et aucun moyen de déterminer quel type de contenu est demandé. La meilleure façon de le faire est, chaque fois que vous servez un lien, vous fournissez une URL qui ne fonctionnera qu'une seule fois (ou moins sécurisée, qui ne fonctionnera qu'en conjonction avec un cookie unique à cet utilisateur), cela donnera le déni plausible de l'utilisateur de ce qu'il regardait. Personne ne peut prouver qu'il n'a pas visité le contenu `` normal '', car quiconque regarde les transferts de données, visiter les mêmes pages recevrait un message d'erreur ou du contenu `` normal '' (selon la façon dont vous l'avez configuré)
J'espère que les suggestions ci-dessus vous aideront, la raison pour laquelle il n'y a rien de tel que `` changer les paramètres xxx sur le serveur '' est que vous voulez que tout utilisateur puisse visiter le site, cela doit inclure ceux qui persécuteront ceux qui visitent également.
Vos exigences, comme indiqué, sont physiquement impossibles.
Pensez-y comme ça. Si vous postez une lettre à quelqu'un dans un autre pays et que vous voulez être sûr qu'un groupe puissant et dangereux est à la fois
- ignorant le contenu de la lettre
et
- ignorant que le destinataire a reçu une lettre de votre part
comment feriez-vous?
La sécurité de votre côté pourrait être fantastique mais cela n'a pas d'importance une fois que la lettre quitte votre pays.
Si la lettre est interceptée à n'importe quel endroit de votre bureau au bureau du destinataire, votre destinataire est en danger.
La sécurité est donc la responsabilité partagée des
vous (le serveur web)
votre système postal (votre FAI/hébergeur)
le système postal international (l'Internet public international - rampant d'espionnage gouvernemental!)
le système postal de vos destinataires (leur FAI)
votre destinataire (son PC, navigateur Web, etc.)
Dans les cas où le destinataire a la formation et les outils nécessaires pour établir des connexions sécurisées, il peut être pratique de communiquer en toute sécurité en sécurisant simplement les 2 points d'extrémité.
Cette exigence selon laquelle les deux points d'extrémité doivent participer activement à une liaison de communication sécurisée est une limitation technique inhérente à l'internet mondial, y compris toute technologie "construite" dessus. Le réseau "par défaut" n'a pas de sécurité d'anonymat "intégrée" et est donc très facile à espionner par ceux qui contrôlent l'infrastructure physique.
Il existe de meilleurs moyens techniques de construire des réseaux mondiaux tels que des réseaux de radio F2F, mais il n'existe pour l'instant que de petits exemples limités.
Vous devrez peut-être examiner d'autres méthodes de distribution et parler à vos utilisateurs et à d'autres organisations pour voir ce qu'ils pensent être pratique.
Ceci est un ajout à la réponse de @ TopherBrink, avec lequel je suis très d'accord. Tout d'abord oui, utilisez HTTPS et HSTS, et il y a des choses derrière un écran de connexion. Deuxièmement, nous devons voir une certaine éthique:
Discussion éthique
C'est Internet, tout le contenu est là, si quelqu'un le veut, il l'obtiendra. Il peut être bloqué par des pare-feu, et quelqu'un trouvera un perforateur ou utilisera un proxy/VPN, il peut être filtré DNS et quelqu'un fera un site Web d'adresses IP à utiliser.
Si le contenu est dangereux, il y a énormes risques dans plusieurs pays: prison, torture, peine de mort. Mais contre ces risques, vous avez à peu près deux options:
Ne le faites pas et autorisez quelqu'un d'autre à servir le contenu à ces personnes. Il sera quelqu'un d'autre, c'est Internet.
Faites un meilleur effort sur le déni. J'ignore le déni comme une mauvaise sécurité, mais vous n'avez pas vraiment d'options.
Et j'ai vu des adolescents pouvoir utiliser un VPN basé sur des tutoriels trouvés sur Internet. Le problème est que, bien que leur configuration ait fonctionné, il fuyait beaucoup d'informations. En général, si vous ne diffusez pas le contenu, quelqu'un d'autre le fera, même si le contenu a besoin de procurations/VPN pour y accéder.
La cause éthique est plus complexe que de ne pas la servir et ne pas être indirectement responsable de la mort de quelqu'un. Si vous abandonnez la diffusion du contenu, vous êtes toujours responsable de la mort de quelqu'un s'il a été surpris en accédant au contenu à partir d'un endroit moins sécurisé que ce que vous pourriez faire.
Échapper à la responsabilité n'est pas un point éthique. Par conséquent, je défendrai l'option la moins populaire et soutiendrai faites-le. Mais faites le meilleur effort possible sur le déni.
Note éthique finale
Rappelez-vous toujours que certains utilisateurs sont simplement stupides et qu'il n'y a donc aucun moyen de les protéger. Si vous ne pouvez pas gérer le fait qu'à un moment ou à un autre, vous devrez en sacrifier un pour le bien de beaucoup, alors ne le faites pas. Mais ne le faites pas pour cette raison. Pas simplement parce que c'est dangereux.
Proposition de déni (c.-à-d. Une façon de le faire)
Le plus gros problème est que vous devez trouver un moyen de donner des connexions aux utilisateurs de confiance et non de les donner à des utilisateurs non fiables. Une façon de contourner cela pour avoir deux sites Web, disons: safewebsite.com et secretwebsite.com.
(Les deux domaines s'exécutant uniquement sur HTTPS et implémentant HSTS)
safewbsite.com contiendra du contenu sécurisé, sera accessible sans connexion par défaut mais les utilisateurs pourront s'enregistrer.
secretwebsite.com renverra toujours la même page "sûre" pour n'importe qui. La seule façon d'obtenir le reste du contenu est d'être autorisé, c'est-à-dire d'être un utilisateur des registres de secretwebsite.com. Maintenant, il n'y a aucun moyen de s'enregistrer sur secretwebsite.com (il ne renvoie qu'une seule page). La seule façon pour secretwebsite.com pour vous donner le bon jeton (disons un cookie httpsonly pour plus de simplicité), c'est en émettant un GET à l'URL correcte. Dire https://secretwebsite.com/logon/6733abf78..77bab99 (ou encodé en base64, peu importe). Cette URL est votre jeton de session.
(utiliser GET pour l'authentification est mauvais, mais comme nous sommes sur HTTPS et que l'URL est un jeton approprié, difficile à deviner, il est acceptable).
Le jeton doit être difficile à utiliser brutalement. Et le seul moyen d'obtenir un jeton correct (un lien correct vers secretwebsite.com) est de safewebsite.com.
Maintenant, vous pouvez choisir (littéralement cherrypick) les utilisateurs de safewebsite.com qui peut accéder à secretwebsite.com.
Le mérite de cette approche est que vous créez une zone de triage (le site Web sécurisé) à partir de laquelle vous pouvez choisir des utilisateurs qui seront suffisamment responsables pour accéder au site Web secret. Si vous construisez correctement le mécanisme de session, vous pouvez donner et prendre la possibilité d'accéder au site Web secret de vos utilisateurs.
Le problème est que cela ne fonctionnera que pour un petit nombre d'utilisateurs, et est susceptible de faire de l'ingénierie sociale contre vous. La fabrication et l'algorithme pour évaluer la véracité d'un utilisateur ne sont pas anodins (si possible), il n'y a donc aucun moyen d'automatiser la sélection des utilisateurs. Un autre problème est que vous devez empêcher safewebsite.com de devenir un terrain de discussion sur la façon d'accéder à sectretwebsite.com, depuis lors, vous perdez complètement le contrôle de qui a confiance et qui ne l'est pas.
Résumé de la sécurité
Bons points:
secretwebsite.comn'existe pas, OK? Non, ce n'est pas le cas, c'est toujours "en construction". Le fait que quelqu'un ait vu quelque chose là-dedans est une création de son propre esprit.- Vous pouvez supprimer les identifiants des utilisateurs problématiques. Ou mieux, vous devez les retirer. Si un utilisateur parle ouvertement de
secretwebsite.comsursafewebsite.comil fait plus de mal que de bien aux deux sites. - Vous vous refusez à vous-même et à vos utilisateurs. Pour le rendre un peu plus plausible, vous pouvez randomiser la taille de la (fausse) page envoyée depuis
secretwebsite.com(donc argumenter que quelqu'un obtient une page de taille différente n'est pas viable). - Il y a aussi un point de confusion. Puisque personne ne sait réellement accéder à
secretwebsite.com(l'URL apparaît à certains utilisateurs et pas à d'autres en fonction de votre caprice, qui ne peut pas être quantifié), vous pouvez arrêtersecretwebsite.comtemporairement en période dangereuse.
Mauvais points:
- Le déni ne fonctionne pas contre un attaquant qui veut vous faire quelque chose juste parce qu'il a besoin de faire quelque chose à quelqu'un (à savoir, il a besoin d'un bouc émissaire). Le déni n'empêchera jamais personne d'être un bouc émissaire, mais aucune autre mesure de sécurité ne sera prise si l'attaquant a un pouvoir physique et judiciaire sur vous.
- Vous devrez traiter avec des légendes urbaines sur
secretwebsite.com. Il est important de ne pas leur permettre de se déplacer librement sursafewebsite.com, sinon vous aurez une corrélation visible. - Le déni fonctionne parce que dans la société moderne la suspicion n'est jamais la même chose que la preuve ( c'est à dire
suspicion != proof). Dès qu'un attaquant peut se fier à ses soupçons pour condamner quelqu'un, il peut le faire à son gré. Le bon côté, c'est qu'un tel attaquant peut se méfier de quiconque, et parcourir des boucles de site Web est beaucoup de travail par rapport à attraper quelqu'un au hasard dans la rue. - C'est beaucoup de travail. Si la communauté de vos utilisateurs grandit, vous aurez besoin d'une modération très éthique, ce qui est difficile à trouver.
Notes supplémentaires:
- Est-ce dangereux? Oui, les gens peuvent se faire prendre. Mais ils seraient de toute façon des boucs émissaires. Un régime autoritaire a besoin de boucs émissaires, vous devez vous assurer que vos utilisateurs sont plus difficiles à transformer en boucs émissaires que les autres.
- Vous en avez dit beaucoup, mais un tel site Web fonctionnerait-il dans le monde réel? Oui, cela fonctionne. Il était une fois, j'ai aidé à créer un de ces sites Web. C'était il y a 5 ans, et le site Web est toujours vivant. Les deux côtés sûrs et secrets.
- Pouvez-vous nous dire de quel site il s'agit? Non, lisez ci-dessus pour les raisons.
Je suis principalement d'accord avec ce que Topher Brink a écrit . Encore quelques points.
Il ne suffit probablement pas d'avoir uniquement un contenu sûr, vous devez également disposer d'un trafic considérable pour accéder à ce contenu. Résultats des moteurs de recherche, les goûts. Sinon, toute visite de votre site peut être associée au contenu sensible même s'il existe d'autres contenus.
Si les faux certificats peuvent être un problème dans le pays en question, vous pouvez demander aux gens de vérifier les sommes de contrôle des certificats. Mais comme le moyen le plus plausible d'introduire de faux certificats serait de falsifier les installateurs de navigateur, je ne ferais pas confiance à ces sommes de contrôle non plus. N'utilisez donc pas ce ciblage de pays où vous ne pouvez pas vous attendre à ce que les utilisateurs aient des navigateurs propres. Il en va de même pour les enregistreurs de frappe sanctionnés par l'État et autres. La confidentialité fournie par la technologie se termine sur leur machine, et si cette machine n'est pas privée, la connexion ne peut pas l'être.
Vous devez vous rappeler que les liens à usage unique doivent être générés par le site et doivent être disponibles pour chaque visiteur. Peut-être optiquement caché comme un lien noir sur une période insignifiante à la fin d'une phrase, avec le curseur de la souris conservé comme celui utilisé pour la sélection de texte. Mais les gens ne devraient jamais avoir à écrire ces liens, à les utiliser pour des visites de retour ultérieures ou à les donner à des amis. Ils devraient pouvoir dire à leurs amis "cliquez simplement là et vous verrez des choses que vous devez voir" sans transmettre d'URL incriminante. Et ils ne devraient jamais le dire verbalement, face à face, pas dans les communications électroniques, car le fait que vous connaissiez la voie à suivre est en soi incriminant.
Vous devez vous assurer que les pages sécurisées et sensibles sont aussi similaires que possible, en ce qui concerne les traces qu'elles pourraient laisser sur une machine. Même titre HTML, même favicon, mêmes cookies. De préférence, même les mêmes fichiers image. Si ce n'est pas possible, vous devrez dire à vos utilisateurs de purger leur cache après la visite et leur expliquer comment procéder. Il est également préférable de leur expliquer comment utiliser la fonction de navigation anonyme de la plupart des navigateurs courants. Au moins après avoir vérifié que ceux-ci ne laissent aucune trace détectable d'utilisation, ce qui pourrait être espéré mais je n'en suis pas certain.
Et vous devez inclure toutes les directives pertinentes pour le comportement des utilisateurs (nettoyer le cache, regarder qui regarde, s'assurer que votre ordinateur n'est pas compromis, aucune instruction écrite aux autres, ne jamais accepter les certificats non sécurisés, relayer ces instructions aux autres,…) sont montrés aux visiteurs bien en évidence et fréquemment . Mais au final, vous ne pouvez qu'espérer qu'ils suivront ces conseils, vous ne pouvez pas contrôler ces aspects à distance.
Réponse conceptuelle
Sans décrire le "comment" en détail, je pense que cette description de "ce que" vous devriez faire peut aider à développer quelque chose qui fonctionne le mieux possible.
Situation
Il semble qu'il y ait quelques étapes clés dans le processus du point de vue des utilisateurs.
- Connectez-vous au serveur
- Parcourir le contenu sur le serveur
- Quittez le serveur
Défi
Il ne devrait pas être possible de prouver qu'ils ont vu quelque chose en rapport avec le sujet X. Leur Internet peut être surveillé en permanence et leur ordinateur peut être confisqué une fois qu'ils ont terminé.
Solution
Je crois qu'avec ces solutions réunies, vous aurez une situation raisonnable.
- Assurez-vous qu'il ne peut pas être prouvé que l'on se connecte au contenu du sujet X. Il semble que la façon la plus pratique de le faire serait de demander à quelqu'un de se connecter à un site général, qui contient également le sujet X. Quelque chose à considérer ici, c'est que même si les gouvernements ne peuvent pas prouver techniquement que les personnes connectées à votre site pour afficher le sujet X, cela peut toujours être déduit si votre site n'est connu que pour cela, et non pour son contenu normal.
- Assurez-vous qu'une fois connecté, il ne peut pas être prouvé que le sujet X a été visité. Bien sûr, la connexion doit être cryptée (https?!) Et le site ne doit pas conserver de journaux qui pourraient incriminer les gens, le site devrait certainement aussi être hébergé dans un pays sûr.
- Assurez-vous qu'aucune trace ne soit laissée derrière le côté client. Cela n'a pas été beaucoup touché par les autres réponses, mais c'est crucial si le PC du visiteur peut être inspecté le lendemain. À moins que je ne me trompe, cela disqualifie automatiquement la mise à disposition du contenu dans un navigateur classique. Ce n'est peut-être pas nécessaire, mais une solution pourrait être que les visiteurs du site (non seulement ceux qui visitent le sujet X) ne voient pas le contenu normalement, mais via un client dédié. Ce client devrait être conçu de manière à ne pas conserver l'historique, le cache, les vidéos téléchargées, etc.
Est-ce que ça en vaut la peine?
Comme mentionné précédemment, offrir ce type de contenu aux personnes qui peuvent aller en prison si elles se font prendre n'est pas une décision à prendre à la légère. Ma recommandation ici serait de ne le faire que si vous vous attendez à ce qu'ils trouvent de toute façon un contenu similaire (de manière moins sécurisée).
Nous ne pouvons pas. Le client doit participer. Nous ne pouvons pas utiliser une paire de sites Web sûrs/secrets si la base d'utilisateurs se développe. Un seul lien divulgué peut être utilisé pour prouver le contenu du site Web secret, simplement pour le fonctionnement de HTTPS. Le contenu fourni par votre site Web est signé par votre site Web, avec un certificat accessible au public. (Sinon, nous ne pouvons pas savoir que nous obtenons le bon site Web, vous voyez.) Si quelqu'un peut prouver que le certificat est le vôtre et a une copie de la signature que vous avez envoyée à son navigateur (qu'il peut obtenir simplement en cliquant sur un quelques menus dans Firefox, d'ailleurs) ils peuvent prouver le contenu qu'ils disent que vous avez servi est authentique.
Il convient également de noter que nous ne pouvons pas simplement éviter la signature sur le contenu du site Web, de peur de perdre également l'intégrité de notre contenu.
Donc pas de déni, si quelqu'un fuit. (C'est en référence à réponse de grochmal. )
Tor est notre meilleure réponse, mais elle est incomplète. Il n'y a pas de bonne réponse à la question que vous posez. Pourtant, ponts Tor/transports enfichables peut être utile.