Codifica file in Javascript prima di inviarli a Google Storage

Quindi stai crittografando un file per caricarlo su un servizio di terze parti, quindi invia la chiave al tuo server. Diamo un'occhiata alle opzioni proposte per l'invio della chiave:

1. Invia su TLS
2. Criptalo con la chiave pubblica del tuo server, quindi invialo su TLS

Quindi quello che vuoi sapere è se l'opzione 2 è migliore dell'opzione 1.

È possibile ignorare TLS?

Se un utente malintenzionato non riesce a superare TLS, entrambe le opzioni vanno bene, quindi supponiamo che possano (ad esempio, sslstrip, utilizzare l'ingegneria sociale per farti affidare il certificato TLS, ecc.). Se l'attaccante può superare TLS, quel succhia . Quanto questo fa schifo dipende dal tipo di aggressore.

Attentatore passivo

Se un utente malintenzionato passivo può leggere il traffico TLS, ha minato la riservatezza, ma non è in grado di alterare il traffico in alcun modo. In questo caso, l'utilizzo della crittografia asimmetrica per crittografare la chiave del file prima di inviarlo al server lo proteggerà.

Attentatore attivo

Un utente malintenzionato attivo può leggere il tuo traffico, ma può anche modificarlo . In questo caso, tu sei protetto. Possono semplicemente modificare il codice JavaScript per fare in modo che il client carichi il file sul proprio server prima di crittarlo, e forse lo crittografano e lo caricano sul servizio di terze parti in modo che nessuno si accorga di qualcosa di sbagliato.

Quale è più probabile?

Se qualcuno è in grado di leggere il tuo traffico TLS, deve avere la chiave privata del certificato (che è molto non valida) oppure ha intercettato il scambio di chiavi, il che significa che probabilmente sono un attaccante attivo.

Esiste un'opzione migliore?

Se sei preoccupato per la sicurezza della tua connessione TLS, le soluzioni sono HPKP e HSTS ( anche se fai attenzione di avvertimenti ).

Conclusione

In un contesto Web, provare a utilizzare JavaScript per migliorare la sicurezza della connessione è generalmente destinato a fallire. Fai tutto il possibile per assicurarti che la tua connessione TLS sia sicura e usala.

Innanzitutto vorrei proporre una modifica alla tua domanda.

"The client WILL not have access to the file once it is done uploading it."

a

"The client SHOULD not have access to the file once it is done uploading it."

Devi sempre considerare che un attore malintenzionato potrebbe recuperare i tuoi dati dallo spazio di archiviazione e considerare se le tue risorse sono adeguatamente protette in tal caso.

Considerazioni qui sono che non devi mai esporre una chiave di crittografia a nessuno a cui non vuoi avere accesso ai dati.

Dovresti considerare quanto è sicuro e casuale il tuo generatore di chiavi casuali, che chiunque abbia accesso al javascript può vedere come funziona e potrebbe potenzialmente prevedere le chiavi e anche che tu stia inviando questa chiave al server che potrebbe essere visibile a determinati attacchi MITM.

In questo caso stai molto meglio usando la crittografia asimmetrica, crittografando il client con la chiave pubblica e consentendo la decodifica solo con la tua chiave privata scret

No: se stai crittografando un file e invialo tramite TLS non stai ottenendo nulla qui.

Crittando con una chiave simmetrica che invii con il file, stai essenzialmente inviando una cassetta di sicurezza con la chiave registrata.

Anche affidarsi al cliente sta spostando la responsabilità della sicurezza da te stesso ai tuoi utenti. I loro browser sono patchati? Hanno installato estensioni del browser che potrebbero essere compromesse? Esiste una vulnerabilità XSS nel tuo sito che consente al browser di rimanere agganciato?

Se è necessario crittografare questi file, lo si gestisce sul server e non nel browser. Se non hai i requisiti per la crittografia dei file nel cloud con una chiave, non applicare la crittografia, ma assicurati che le connessioni siano TLS 1.2