Le e-mail inviate formano un'app Web Java su una connessione HTTPS crittografata?

3

Sto lavorando a un'applicazione web Java che gira su una connessione HTTPS. Questa applicazione invia e-mail ai propri utenti. Voglio proteggere queste e-mail dagli attacchi man-in-the-middle e da altre potenziali minacce. Le mie domande sono:

  1. Devo crittografare il mio contenuto email? Perché e come? Perché no?
  2. HTTPS non crittografa i dati trasmessi automaticamente?
  3. Se devo crittografarli manualmente, come decrittografano i ricevitori?
  4. Qualunque sia la soluzione che suggerisci, qual è la probabilità e la gravità delle potenziali minacce?
posta Gurkirat Singh 15.03.2016 - 10:48
fonte

3 risposte

6

Supponendo che tutto sia fatto bene ( tutto , che non è un dato, specialmente se lo fai da solo), HTTPS non proteggerebbe la tua email in quanto le email non stanno usando quel protocollo per essere trasmesso Perché in realtà devi inviare l'email effettiva ad altri server utilizzando il "protocollo email": SMTP . Ma anche allora, questa è una cattiva idea.

Ad esempio, quali sono esattamente questi "altri server"? Ad esempio, se il destinatario è a Gmail, devi inviare l'email ai server di Gmail, giusto? Tuttavia, questo non è esattamente il modo in cui SMTP funziona: l'email salterà dai server di posta ai server di posta fino a quando non raggiunge la destinazione finale. Questa connessione può essere diretta, ma non ci sono garanzie che sarà effettivamente, tutt'altro. Questo semplice fatto rende la crittografia end-to-end entro SMTP impossibile di design : ogni singolo / MTA è un MitM! Sì, ci sono stati tentativi di rendere SMTP sicuro, ma il design è ancora male da un punto di vista della sicurezza. Vedi questo articolo Wiki per esempio, in particolare:

Mandatory certificate verification is not viable for Internet mail delivery. As a result, most email that is delivered over TLS uses only opportunistic encryption.

Opportunistico qui significa che il valore predefinito è deselezionare ogni volta che qualcuno vuole leggere illegittimamente, se qualcosa nel mezzo è rotto, se qualcosa non è configurato correttamente, ecc. E il peggio è che non è perché la tua connessione al primo relay (chiamato MTA, nell'altra risposta) è effettivamente sicura (perché hai fatto un buon lavoro sprecando 8 ore di tempo nella configurazione e controlli approfonditi) che la connessione tra il primo relè con il secondo sarà sicuro. Non hai garanzia di ciò (e ancora, i relè stessi possono essere malvagi).

Soluzioni?

  • Non inviare email in chiaro. Usa PGP / GPG, S / MIME o equivalente per criptare le tue e-mail se vuoi la segretezza. Questi forniscono la crittografia end-to-end ma richiedono un bel po 'di configurazione da parte tua e dal tuo lato utente. Per essere eseguito correttamente (e in realtà fornire privacy), è necessario autenticare manualmente ciascun utente. Questo potrebbe non essere possibile.

  • Un'altra soluzione sarebbe quella di utilizzare un protocollo già progettato per essere sicuro che fornisce la crittografia end-to-end (alcuni protocolli IM sono in realtà abbastanza buoni per questo).

  • Come proposto nell'altra risposta, fornisci un'email con un link a una pagina HTTPS protetta accessibile solo agli utenti autenticati (un token nell'URL non funzionerà).

Tuttavia, non utilizzare mai SMTP (con o senza TLS / StartTLS) se hai bisogno di una garanzia di una minima quantità di privacy . SMTP non è sicuro.

    
risposta data 15.03.2016 - 12:44
fonte
3

Un modo per verificare il percorso e la configurazione della comunicazione, almeno dal punto di vista dell'utente (il client) che comunica con il server di posta diretta (Microsoft / Apple / Google) è eseguire Wireshark (sniffing tool e packet analyzer) e inviare un'email da un account all'altro. in base alla configurazione del client di posta elettronica, è possibile visualizzare il percorso di comunicazione che viene creato e se la crittografia (almeno per il percorso iniziale) è crittografata, vale a dire utilizzando un tipo di percorso di crittografia TLS / SSL. Una volta sul server di posta aziendale, è davvero difficile valutare se l'intero percorso da hop a hop di diversi server DNS e Mail è crittografato. SMTP, POP3 IMAP, MIME non utilizzano la crittografia dei dati o la crittografia delle intestazioni per impostazione predefinita.

    
risposta data 15.11.2016 - 15:06
fonte
1

Semplicemente perché la tua applicazione web accetta solo connessioni HTTPS in arrivo, non significa che tutte le e-mail che invia siano crittografate ... Questa è la responsabilità del server SMTP sottostante. È necessario configurare il server SMTP per inviare solo e-mail crittografate. Quindi:

  • A1: Sì, ma non a livello di applicazione. Configurare il server SMTP per utilizzare SSL / TLS tra il client e se stesso e per la comunicazione inter MTA.
  • A2: Sì, lo fa; tra client (il browser dell'utente finale) e server (l'applicazione Web). Non tra il server e il server SMTP (poiché ciò non avviene tramite https).
  • A3: Esattamente, non possono. Questo è il motivo per cui è necessario configurare il server SMTP per fare affidamento sui meccanismi di crittografia SSL / TLS e non crittografare i dati a livello di applicazione.
  • A4: se il server POP / IMAP della destinazione non è configurato correttamente, potrebbe scaricare il testo in chiaro delle e-mail, il che rivela un'opportunità per man-in-the-middle ...

Se il contenuto dell'e-mail è davvero così sensibile, opterei per non lasciarlo affatto uscire dall'applicazione. È possibile inviare e-mail agli utenti per notificare che è disponibile un nuovo messaggio sul portale e che devono accedere per vederlo. Ovviamente, questo è meno user-friendly di una email diretta ... Questa è la parte in cui devi valutare la riservatezza dei dati rispetto alla facilità d'uso e decidere in merito.

    
risposta data 15.03.2016 - 11:49
fonte

Leggi altre domande sui tag