Non farlo

Se stai prendendo di mira regimi non sicuri, le conseguenze possono essere gravi. Ad esempio, in Iran, gli omosessuali condannati sono generalmente condannati a morte per impiccagione.

Ci vorrebbe solo il minimo errore da parte del tuo sito o di uno dei tuoi utenti perché questa sia una prova incriminante. Riesci a immaginare il senso di colpa che proveresti se il tuo sito ben intenzionato finisse per essere la prova che ha portato a un'esecuzione?

Operare online in modo sovversivo in un regime repressivo richiede estrema abilità e cautela. Il semplice utilizzo di Tor sarebbe di per sé una bandiera rossa. Mentre i gruppi di hacker come anonymous possono essere in grado di cavarsela, gli utenti normali non possono.

Ci sono stati commenti su altre risposte che dicevano (approssimativamente) "usa HTTPS, va bene". Non posso sottolineare abbastanza fortemente come questo sia un consiglio pericoloso. HTTPS rivela il nome di dominio a cui l'utente accede, lascia traccia sul computer client ed è probabile che gli stati-nazione (incluso l'Iran) possano produrre certificati falsi e intercettare tutto il traffico HTTPS.

Non è una cosa facile da fare. Esistono diversi modi per ottenere qualcosa di simile a quello che desideri.

Innanzitutto, utilizza HTTPS. Ciò impedisce a chiunque di vedere i dati trasferiti diversi dal server e dall'utente (che presumo siano entrambi puliti). Ciò non impedisce alle persone esterne di vedere che l'utente ha visitato il sito, ma solo i dati esatti che vengono trasferiti.

Se ci sono cose nascoste dietro una schermata di accesso, chiunque senza un accesso visita il sito non sarà in grado di vedere di cosa tratta il sito. Questo non è molto positivo in quanto devi fidarti degli utenti che hanno i dettagli di accesso e devi escogitare un modo per reclutare persone fidate per visualizzare il sito.

Un modo migliore è avere contenuti "normali" per nascondere gli altri contenuti e non è possibile stabilire quale tipo di contenuto viene richiesto. Il modo migliore per farlo è che, ogni volta che offri un link, offri un URL che funzionerà solo una volta (o meno sicuro, uno che funzionerà solo in combinazione con un cookie che è unico per quell'utente) questo darà la plausibile negabilità dell'utente di ciò che stavano guardando. Nessuno può dimostrare di non aver visitato il contenuto "normale" poiché chiunque osservi i trasferimenti di dati, visitando le stesse pagine otterrebbe un messaggio di errore o un contenuto "normale" (a seconda di come lo si imposta)

Spero che i suggerimenti di cui sopra siano d'aiuto, il motivo per cui non c'è niente come 'cambiare l'impostazione xxx sul server' è che vuoi che qualsiasi utente sia in grado di visitare il sito, questo deve includere coloro che perseguiteranno anche quelli che visitano.

I tuoi requisiti come dichiarato sono fisicamente impossibili.

Pensa in questo modo: se stavi inviando una lettera a qualcuno in un altro paese e volevi essere sicuro che un gruppo potente e pericoloso fosse entrambi

1. ignaro del contenuto della lettera

e

2. ignaro che il destinatario abbia ricevuto una tua lettera

come faresti?

La sicurezza dalla tua parte potrebbe essere fantastica, ma non importa una volta che la lettera lascia il tuo paese.

Se la lettera viene intercettata in qualsiasi punto dalla tua scrivania alla scrivania del destinatario, il destinatario è a rischio.

Pertanto la sicurezza è responsabilità condivisa di

• tu (il server web)

• il tuo sistema postale (il tuo ISP / host web)

• il sistema postale internazionale (il pubblico internazionale Internet - strisciando con lo spionaggio del governo!)

• il sistema postale dei destinatari (il loro ISP)

• il tuo destinatario (il loro PC, browser web, ecc.)

Nei casi in cui wh Se il destinatario ha la formazione e gli strumenti per stabilire connessioni sicure, può essere pratico comunicare in modo sicuro semplicemente assicurando i 2 punti finali.

Questo requisito è che entrambi i punti finali devono partecipare attivamente in un collegamento di comunicazione sicuro è una limitazione tecnica intrinseca di Internet globale, inclusa qualsiasi tecnologia "costruita" su di essa. La rete "predefinita" non ha una sicurezza di anonimato "incorporata" ed è quindi molto facile da spiare da chi ha il controllo dell'infrastruttura fisica.

Esistono modi tecnici migliori per costruire reti globali come F2F meshnets radio, ma esistono ancora solo piccoli esempi limitati.

Potrebbe essere necessario esaminare metodi di distribuzione alternativi e parlare con i propri utenti e altre organizzazioni per vedere cosa pensano sia pratico.

Questa è un'aggiunta alla risposta di @ TopherBrink, con la quale sono molto d'accordo. Prima di tutto sì, usa HTTPS e HSTS e hai cose dietro una schermata di accesso. Secondo, dobbiamo vedere un po 'di etica:

Discussione etica

Questo è Internet, tutto il contenuto è lì, se qualcuno lo vuole lo otterrà. Potrebbe essere bloccato dai firewall e qualcuno troverà un perforatore o utilizzerà un proxy / VPN, potrebbe essere filtrato dal DNS e qualcuno creerà un sito Web di IP da utilizzare.

Se il contenuto è pericoloso lì sono rischi giganteschi in diversi paesi: prigione, tortura, pena di morte. Ma contro questi rischi hai praticamente due opzioni:

1. Non farlo e consenti a qualcun altro di servire il contenuto a queste persone. Ci sarà qualcun altro, questo è Internet.

2. Fai del tuo meglio per negare la responsabilità . Non considero la negabilità come scarsa sicurezza, ma in realtà non hai opzioni.

E ho visto gli adolescenti essere in grado di utilizzare una VPN basata su tutorial trovati su Internet. Il problema è che, sebbene la loro configurazione funzionasse, perdeva una buona quantità di informazioni. In generale, se non offri il contenuto a qualcun altro, anche se il contenuto necessita di proxy / VPN per accedervi.

La causa etica è più complessa del non servirlo e del non essere indirettamente responsabile della morte di qualcuno. Se rinunci a servire il contenuto, sei comunque responsabile della morte di qualcuno se è stato sorpreso ad accedere a contenuti da un luogo che era peggio protetto di quello che potresti fare.

Sfuggire alla responsabilità non è un punto etico. Pertanto difenderò l'opzione meno popolare e sosterrò di farlo . Ma fai del tuo meglio per negare la responsabilità.

Nota etica finale

Ricorda sempre che alcuni utenti sono semplicemente stupidi e quindi non c'è modo di proteggerli. Se non puoi affrontare il fatto che prima o poi dovrai sacrificarne uno per il bene di molti, allora non farlo . Ma non farlo per questo motivo. Non solo perché è pericoloso.

Proposta di negazione (cioè un modo per farlo)

Il problema più grande è che devi trovare un modo per fornire accessi a utenti affidabili utenti e non darli a quelli non fidati. Un modo per aggirare il problema è avere due siti web, diciamo: safewebsite.com e secretwebsite.com.

(Entrambi i domini in esecuzione solo su HTTPS e implementazione di HSTS)

safewbsite.com conterrà contenuto sicuro, sarà accessibile senza un accesso per impostazione predefinita ma gli utenti potranno registrarsi.

secretwebsite.com restituirà sempre la stessa pagina "sicura" per chiunque. L'unico modo per ottenere il resto del contenuto è essere autorizzato, ovvero essere un utente registrato di secretwebsite.com . Ora, non c'è modo di registrarsi su secretwebsite.com (restituisce solo una singola pagina). L'unico modo per secretwebsite.com di darti il ​​token corretto (diciamo un cookie per semplicità) è inviare un GET all'URL corretto. Pronuncia https://secretwebsite.com/logon/6733abf78..77bab99 (o codificato base64, qualunque cosa). Quell'URL è il tuo token di sessione.

(l'utilizzo di GET per l'autenticazione è cattivo , ma poiché siamo su HTTPS e l'URL è un token corretto, difficile da indovinare, è accettabile ).

Il token deve essere difficile da usare con la forza bruta. E l'unico modo per ottenere un token corretto (un collegamento corretto a secretwebsite.com ) è da safewebsite.com.

Ora puoi scegliere (letteralmente cherrypick) utenti di safewebsite.com che possono accedere a secretwebsite.com .

Il merito di questo approccio è che crei un'area triage (il sito web sicuro) da cui puoi scegliere gli utenti che saranno sufficientemente responsabili per accedere al sito web segreto. Se costruisci correttamente il meccanismo di sessione, puoi dare e prendere la possibilità di accedere al sito web segreto dai tuoi utenti.

Il problema è che questo funzionerà solo per un piccolo numero di utenti ed è suscettibile di ingegneria sociale contro di te. Fare e algoritmo per valutare la veridicità di un utente non è cosa da poco (se possibile), quindi non c'è modo di automatizzare la selezione dell'utente. Un altro problema è che devi impedire a safewebsite.com di diventare un terreno di discussione su come accedere a sectretwebsite.com , da allora perdi completamente il controllo su chi è affidabile e chi non lo è.

Riepilogo sulla sicurezza

Aspetti positivi:

• secretwebsite.com non esiste, ok? No, non è così, è sempre "in costruzione". Il fatto che qualcuno abbia visto qualcosa è una creazione della sua mente.
• Puoi eliminare gli accessi di utenti problematici. O meglio, devi eliminarli. Se un utente parla apertamente di secretwebsite.com su safewebsite.com sta facendo più male che bene a entrambi i siti web.
• Doni responsabilità a te stesso e i tuoi utenti. Per renderlo un po 'più plausibile puoi randomizzare la dimensione della pagina (falsa) inviata da secretwebsite.com (quindi sostenere che qualcuno ottiene una pagina di dimensioni diverse non è fattibile).
• C'è anche un punto di confusione. Poiché nessuno sa come accedere effettivamente a secretwebsite.com (l'URL appare a determinati utenti e non ad altri in base al tuo capriccio, che non può essere quantizzato), puoi chiudere secretwebsite. com temporaneamente in tempi pericolosi.

Aspetti negativi:

• La negabilità non funziona contro un aggressore che vuole farti qualcosa solo perché ha bisogno di fare qualcosa a qualcuno (vale a dire, ha bisogno di un capro espiatorio ). La negabilità non impedirà mai a nessuno di essere un capro espiatorio, ma nemmeno qualsiasi altra misura di sicurezza se l'aggressore ha potere fisico e giudiziario su di te.
• Dovrai affrontare le leggende metropolitane su secretwebsite.com . È importante che tu non permetta loro di vagare liberamente su safewebsite.com , altrimenti avrai una correlazione visibile.
• La negabilità funziona perché nella società moderna sospetto non è mai uguale a proof (cioè suspicion! = proof ). Nel momento in cui un aggressore può fare affidamento sul suo sospetto per condannare qualcuno, può farlo a suo piacimento. Il lato positivo è che un tale aggressore può essere sospettoso nei confronti di chiunque, e passare attraverso i loop del sito Web è molto faticoso rispetto a catturare qualcuno a caso per strada.
• È molto lavoro. Se la comunità dei tuoi utenti cresce, avrai bisogno di una moderazione molto etica, difficile da trovare.

Note extra:

• È pericoloso? Sì, le persone potrebbero essere scoperte. Ma sarebbero comunque capri espiatori. Un regime autoritario ha bisogno di capri espiatori, devi assicurarti che i tuoi utenti siano più difficili da trasformare in capri espiatori di altri.
• Hai detto molto, ma un sito web del genere funzionerebbe nel mondo reale? Sì , funziona. C'era una volta che ho contribuito a creare uno di questi siti web. Sono passati 5 anni e il sito web è ancora vivo. Sia il lato sicuro che quello segreto.
• Puoi dirci qual è il sito web? No , leggi sopra per i motivi.

Sono per lo più d'accordo con ciò che ha scritto Topher Brink. Solo alcuni punti in più.

Probabilmente non è sufficiente avere solo contenuti sicuri, devi anche avere un traffico considerevole per accedere a tali contenuti. Hit dei motori di ricerca, simili. In caso contrario, qualsiasi visita al tuo sito potrebbe essere associata ai contenuti sensibili anche se sono presenti altri contenuti in giro.

Se i certificati falsi possono essere un problema nel paese in questione, potresti chiedere alle persone di verificare i checksum dei certificati . Ma dal momento che il modo più plausibile per introdurre certificati falsi sarebbe l'installazione di browser manomessi, non mi fiderei nemmeno di quei checksum. Quindi non utilizzare questo targeting per paesi in cui non puoi aspettarti che gli utenti abbiano browser puliti. Lo stesso vale per i keylogger autorizzati dallo stato e simili. La privacy fornita dalla tecnologia termina sulla loro macchina e se quella macchina non è privata, la connessione non può esserlo.

Ricorda che i link monouso dovrebbero essere generati dal sito e dovrebbero essere disponibile per ogni visitatore. Forse nascosto otticamente come un collegamento nero su qualche punto insignificante alla fine di una frase, con il cursore del mouse mantenuto come quello utilizzato per la selezione del testo. Ma le persone non dovrebbero mai scrivere questi collegamenti, usarli per visite successive o per darli ad amici. Dovrebbero essere in grado di dire ai loro amici "basta fare clic lì e vedrai le cose che devi vedere" senza trasmettere alcun URL incriminante. E dovrebbero sempre e solo dirlo verbalmente, faccia a faccia, non nelle comunicazioni elettroniche poiché il fatto che tu sappia come entrare è di per sé incriminante.

Dovresti assicurarti che le pagine sicure e sensibili siano il più simili possibile, rispetto alle tracce che potrebbero lasciare su una macchina. Stesso titolo HTML, stessa favicon, stessi cookie. Preferibilmente anche gli stessi file di immagine. Se ciò non è possibile, dovrai dire ai tuoi utenti di svuotare la cache dopo la visita e spiegare loro come farlo. È meglio anche spiegare loro come utilizzare la funzionalità di navigazione anonima dei browser più comuni. Almeno dopo aver verificato che questi non lasciano tracce rilevabili di utilizzo, cosa che si potrebbe sperare ma non ne sono certo.

E dovresti includere tutte le linee guida rilevanti per il comportamento degli utenti (pulire la cache, guarda chi sta guardando, assicurati che il tuo computer sia senza compromessi, nessuna istruzione scritta ad altri, non accettare mai certificati non sicuri, trasmettere queste istruzioni ad altri, ...) vengono mostrati ai visitatori in modo ben visibile e frequente. Ma alla fine puoi solo sperare che seguano questa guida, non puoi controllare questi aspetti da remoto.

Risposta concettuale

Senza descrivere il "come" in dettaglio, credo che questa descrizione di "cosa" dovresti fare possa aiutare a sviluppare qualcosa che funzioni nel miglior modo possibile.

Situazione

Sembra che ci siano alcuni passaggi chiave nel processo dal punto di vista degli utenti.

1. Connettiti al server
2. Sfoglia contenuto sul server
3. Lascia il server

Sfida

Non dovrebbe essere possibile dimostrare di aver visualizzato qualcosa relativo all'argomento X. Il loro Internet potrebbe essere monitorato in modo permanente e il loro computer potrebbe essere confiscato dopo che hanno finito.

Soluzione

Credo che con queste parti della soluzione insieme, avrai una situazione ragionevole.

1. Assicurati che non sia possibile dimostrare che ci si connette a contenuti sull'argomento X. Sembra che il modo più pratico per farlo sarebbe quello di avere qualcuno che si connette a un sito generico , che contiene anche l'argomento X. Qualcosa da considerare qui, è che anche se i governi non può tecnicamente dimostrare che le persone si sono collegate al tuo sito per visualizzare l'argomento X, questo può comunque essere dedotto se il tuo sito viene conosciuto solo per questo e non per il suo contenuto normale.
2. Assicurati che una volta connesso , non è possibile dimostrare che l'argomento X sia stato visitato. Ovviamente la connessione dovrebbe essere crittografata (https ?!) e il sito non dovrebbe conservare log che potrebbero incriminare le persone, il sito dovrebbe anche essere sicuramente ospitato in un paese sicuro .
3. Assicurati che non vengano lasciate tracce dal lato client. Questo non è stato molto toccato dalle altre risposte, ma è fondamentale se il PC del visitatore può essere ispezionato il giorno successivo. A meno che non sbaglio, questo squalifica automaticamente la disponibilità del contenuto in un normale browser. Forse non è necessario, ma una soluzione potrebbe essere che i visitatori del sito (non solo quelli che visitano l'argomento X) non visualizzino il contenuto normalmente, ma tramite un client dedicato. Questo client dovrebbe essere progettato in modo tale da non conservare la cronologia, la cache, i video scaricati e così via.

Vale il rischio?

Come accennato in precedenza, offrire questo tipo di contenuti a persone che potrebbero andare in prigione se vengono scoperte non è una decisione da prendere alla leggera. Il mio consiglio qui sarebbe di farlo solo se ti aspetti che trovino comunque contenuti simili (in un modo meno sicuro).

Non possiamo. Il cliente deve partecipare. Non possiamo utilizzare una coppia sicura / segreta di siti web se la base di utenti cresce. Un singolo collegamento trapelato può essere utilizzato per provare i contenuti del sito web segreto, semplicemente per come funziona HTTPS. Il contenuto fornito dal tuo sito web è firmato dal tuo sito web, con un certificato accessibile pubblicamente. (Altrimenti non possiamo sapere che stiamo ottenendo il sito web giusto, vedi.) Se qualcuno può dimostrare che il certificato è tuo e ha una copia della firma che hai inviato al browser (che può ottenere semplicemente facendo clic su un pochi menu in Firefox, a proposito) possono provare che il contenuto che dicono che hai servito è autentico.

Vale anche la pena notare che non possiamo semplicemente evitare la firma sul sito web contenuto, per non perdere anche l'integrità del nostro contenuto.

Quindi nessuna negazione, se qualcuno trapela. (Questo è in riferimento alla risposta di grochmal.)

Tor è la nostra migliore risposta, ma è incompleta. Non c'è una buona risposta alla domanda che stai facendo. Tuttavia, Tor bridge / trasporti collegabili potrebbero essere utili.