Come proteggere le comunicazioni tra un front-end Web e il server Web quando / dove il protocollo HTTPS è compromesso?

3

Un paese dell'Asia centrale ha emanato una legge che impone a tutti gli ISP di decodificare il traffico HTTPS di transito e di crittografarlo con uno speciale certificato rilasciato dal governo. Ogni client deve installare il certificato per poter accedere alle risorse HTTPS (semplicemente non funzioneranno senza questo). Almeno ci si può aspettare che alcuni altri paesi seguano. Inutile dire che questo significa che HTTPS non è una soluzione sufficiente per garantire la privacy dei dati trasmessi tra i client e i server. Quali sono alcune idee ragionevoli / interessanti sui modi per affrontare questo problema in pratica?

Conosco VPN e SSH, ma questa sembra una soluzione abbastanza maldestra: i governi che bloccano HTTPS probabilmente bloccheranno tutte le soluzioni di crittografia di primo livello facilmente riconoscibili come SSH e VPN. Quindi, ciò di cui sono generalmente interessato è l'implementazione di un secondo livello di crittografia end-to-end a livello di applicazione.

Sto lavorando a un'idea di un organizzatore di informazioni personali, una sorta di app web per archiviare i miei dati personali (inclusi, tra gli altri dati, password, immagini intime e dati come questo) sul mio server personale e accedervi ovunque io vada . Inutile dire che non voglio che nessuno sia in grado di intercettare i dati quando mi capita di viaggiare in un paese in cui è stata implementata una tale politica anti-pivot.

    
posta Ivan 26.06.2016 - 16:41
fonte

2 risposte

3

What are some reasonable/interesting ideas of ways to address this issue practically?

Crittografia GPG, con steganografia per nascondere il fatto che stai usando la crittografia in bella vista.

L'idea di base che devi evitare compromessi obbligatori per la crittografia è trovare qualsiasi canale dati che non sia bloccato e utilizzare la crittografia non compromessa su quel canale dati.

Quel canale dati potrebbe essere, ma non limitato, a nessuno di questi (ordinato approssimativamente da quanto sono pratici):

  • qualsiasi tipo di proxy, proxy web, VPN, SSH. Oltre la porta personalizzata, se necessario.
  • telefono fisso
  • modem software sul canale vocale della rete mobile
  • onda corta / radio AM
  • telefono satellitare
  • Rete mesh Wi-Fi
  • passa a un messaggio di posta elettronica spam o pastebin
  • utilizza o elabora protocolli che possono passare a un altro mid stream del protocollo nella stessa connessione TCP
  • sneaker net
  • IPoAC
  • segnale fumoso

La crittografia fatta su questo è solo una normale crittografia non compromessa. Probabilmente solo HTTPS o forse GPG. Non importa davvero troppo.

    
risposta data 26.06.2016 - 18:44
fonte
0

Puoi provare a creare un tunnel SSH per eseguire il tunneling di HTTPS attraverso di esso. Immagino questo post spiega come eseguire questo in modo efficace, altrimenti puoi trovare molte guide sul web che spiegano come creare un tunnel SSH.

    
risposta data 26.06.2016 - 16:53
fonte

Leggi altre domande sui tag