Crittografia email per gmail

Dipende da cosa si sta proteggendo -

leggere la domanda su quali passi google, Yahoo! ecc. per proteggere la webmail .

Dai anche un'occhiata alla domanda che fornisce soluzioni alternative sull'invio dei dati. Tendo a utilizzare pgp / gpg per crittografare prima di inviare email, ove possibile, o utilizzare una posta sicura ospitata (simile a quella descritta da @Paul) per alcuni client.

Puoi proteggere la connessione abbastanza bene, ma se non cripti i tuoi dati prima di inviarli, questi risiederanno nei server di google in chiaro. Potrebbe andar bene, ma potrebbe non essere così - tutto torna a quanto sensibili siano i dati in quei messaggi.

Se sia il tuo amico che i suoi clienti utilizzano gmail, la sicurezza non è poi così male ... tutti i trasferimenti di dati tra la macchina dell'utente e Gmail sono su HTTPS e, se il mittente e il destinatario utilizzano Gmail, l'email non lascia mai le macchine di Google . Quindi, finché ti fidi di Google , va bene.

"Fiducia" è una parola cattiva. Nel paragrafo precedente, ciò significa che Google non divulga volontariamente i contenuti dell'email, e anche che fanno un buon lavoro di protezione dei loro server (ti fidi che siano onesti e ti fidi che siano competenti). Ma, alla fine, qualcuno di cui ti fidi è qualcuno che ha il potere di tradirti.

Inoltre, Google è noto per la scansione delle e-mail degli utenti di Gmail, in modo che possa elaborare annunci mirati da mostrare agli utenti. Ciò implica, almeno in modo teorico, che i dati delle tue email necessariamente escano dai server Gmail verso gli inserzionisti. Un pensiero confortante.

Per essere migliore di gmail, hai bisogno di una crittografia end-to-end. I prodotti classici sono S / MIME e PGP ; il primo è supportato direttamente dalle applicazioni di posta elettronica tradizionali, ma include i certificati X.509, che possono essere una seccatura da configurare. PGP di solito richiede add-on, ma tende ad essere più semplice da usare. Si noti che la maggior parte dei webmail non è compatibile con S / MIME o PGP: Outlook Web App può eseguire S / MIME con un controllo ActiveX specifico sul sistema client - solo Windows / IE, ovviamente - ma la maggior parte degli altri sistemi di posta non può. In una certa misura, le e-mail PGP possono essere gestite esternamente trasferendole con copia e incolla (il formato normale per le e-mail PGP è "ASCII-armatura" che è destinato ad essere trasferibile come testo normale).

Per comunicazioni one-shot, considera gli archivi Zip con una password (la password viene scambiata per telefono). Le implementazioni Zip precedenti utilizzavano una cifratura debole del flusso personalizzato (in realtà un buon esempio del perché i disegni fatti in casa dovrebbero essere evitato). Gli archiviatori Zip più recenti (WinZip 9.0 e versioni successive, almeno) utilizzano AES, che è molto più potente. Tutto si riduce a ciò che il client è pronto per l'installazione quando viene richiesto dal tuo amico.

Per evitare che i client debbano configurare e gestire i sistemi di crittografia sui loro dispositivi per comunicare con il contabile, un archivio di file sicuro come Accellion potrebbe essere un'opzione.

Funziona come una webmail. Componi la tua email nel portale Accellion e alleghi il tuo file e invialo al cliente. Il file stesso non viene inviato, ma sostituito da un collegamento. Il cliente riceve l'e-mail e fa clic sul link per scaricare tramite https il file.

Allo stesso modo, possono utilizzare il servizio del contabile per inviare file al contabile (ma non a nessun altro).

Dovresti dare un'occhiata al progetto Mailvelope . Si tratta di un'estensione Google Chrome che implementa alcuni di OpenPGP per Webmail. L'interfaccia utente è semplice e pulita.

Sebbene non sia d'accordo con Luxsci (un provider di crittografia email) TLS è tutto ciò che è richiesto per il livello di crittografia per la conformità HIPAA. Non so quali leggi un contabile debba regolamentare il proprio settore, ma Luxsci ha un correttore TLS GRATUITO all'indirizzo: link

Vorrei basare la mia decisione sui requisiti specifici del settore. Se è richiesta la crittografia, si consiglia di prendere in considerazione un prodotto commerciale facile da usare come smarsh, webroot, zixmail, ecc. Posso comunque dire che per evitare che trend micro abbia un prodotto orribile derivante dall'esperienza personale e poiché non ho più cambiato fornitore quel problema.

Nota aggiuntiva: ci sono 2 metodi principali per la crittografia commerciale, push e pull.

Push invia un messaggio di posta elettronica contenente un allegato effettivamente crittografato e decodifica il messaggio localmente. ALCUNE aziende e sicuramente ospedali BLOCCO questo poiché non possono leggere il contenuto. Consiglierei di stare lontano da questo, se possibile.

Pull invia un'email che fai clic su un link che ti porta a un portale web per recuperare il tuo messaggio e gli allegati. Questa tecnica non dovrebbe attivare alcuna regola del firewall o essere bloccata a causa di come viene consegnata.

Bene gmail usa https ovunque, quindi l'invio / ricezione dovrebbe essere sicuro. Credo che abbiano una buona politica sulla privacy, quindi stai dicendo che hai bisogno di maggiore sicurezza nel caso in cui un dipendente di google diventa una spia o qualcuno incrina la password per l'account di posta elettronica di qualcuno? Il primo non credo che vorrai, ma il secondo potrebbe essere risolto con la verifica in due passaggi.

Hai davvero bisogno di più? Se lo fai e credi che un dipendente diventerà una spia o Google verrà violato e le tue e-mail / i tuoi file saranno copiati, quindi cifrare con pgp

Gli unici standard di crittografia e-mail mainstream sono PGP e S / MIME. Entrambi funzionano, entrambi sono efficaci. Ma nessuno dei due funzionerà con un'interfaccia webmail, dal momento che sono client-side. Infatti, se trovi un meccanismo che funziona con l'interfaccia webmail, dovresti essere molto sospettoso della sua sicurezza.

La maggior parte dei provider di posta elettronica (incluso GMail) supporta IMAP o POP3 insieme a SMTP. È possibile utilizzare questo per collegare la tua casella di posta con un lettore di posta desktop, come Thunderbird. Quindi, puoi utilizzare un motore di crittografia sul lato client (come enigmail o le utility S / MIME integrate) per accedere alle funzioni di crittografia.

Ovviamente entrambi i lati della conversazione devono utilizzare lo stesso sistema crittografico, ma è sempre così. Inoltre, questo è intrinsecamente scomodo e probabilmente lo sarà sempre.

Infine, probabilmente il modo più semplice per scambiare contenuti crittografati è come un allegato. Utilizzare uno strumento come 7-zip per creare un pacchetto crittografato con il contenuto che si desidera proteggere e utilizzare una password pre-arrangiata fuori banda (come voce o di persona).

Il problema anche con la crittografia di Office (che è diventata significativamente migliore quando sono passati al formato XML) è - se usi una password complessa, come sarà condivisa?

Sembra che una semplice opzione sarebbe quella di utilizzare un sistema di scambio di file sicuro commerciale, ospitato on premise. Quindi, il trasferimento potrebbe essere crittografato tramite SSL e i suoi clienti non avrebbero a che fare con la crittografia. Dal momento che è on premise o su un server dedicato, non c'è una terza parte che possa accedere ai file memorizzati.

Ma tieni presente che, facendo ciò, deve essere in grado di gestire quel sistema e mantenerlo al sicuro. Anche questo è un rischio.

Potrebbe valere la pena considerare roba come Spideroak e Wuala, che sono servizi simili a Dropbox con crittografia basata su client.

Tuttavia, come contabile, non vorrei mai chiedere ai miei clienti di installare software. Quindi, in sostanza, quale sarebbe il migliore sarebbe un sito come Mega ma più focalizzato sulla sicurezza di quanto non sia ora. Crittografa sul lato client tramite Javascript nel browser, quindi mentre devi fidarti di loro per fornire il codice corretto al tuo browser, in teoria non possono decifrare ciò che è memorizzato sul loro sistema.

Sono stato in una situazione simile. L'unica opzione che ho trovato universalmente accettabile per gli utenti finali di tutti i livelli di abilità era quella di inviare file in un file .zip crittografato come allegati. Su Linux questi file sono facili da creare con il flag -e per zip :

$ touch foo.txt

$ zip -e foo.zip foo.txt 
Enter password: 
Verify password: 
  adding: foo.txt (stored 0%)

$ ls | grep foo
foo.txt
foo.zip

$ file foo.zip 
foo.zip: Zip archive data, at least v1.0 to extract

$ unzip foo.zip 
Archive:  foo.zip
[foo.zip] foo.txt password: 
password incorrect--reenter: 
replace foo.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: y
 extracting: foo.txt

Gli utenti su Windows o l'uso di un'interfaccia grafica su Linux (KDE, Unity, Gnome) possono creare file .zip crittografati facendo clic con il tasto destro su un file e selezionando l'opzione "Encrypt" da zip e può decodificare semplicemente facendo doppio clic.

Secondo me:

Sia tu che il cliente installate un cryptool sulla loro macchina da

Scarica cryptool

entrambi dovreste imparare a usarlo

Scopri cryptool con l'aiuto del video di youtube.com

quindi puoi condividere alcune chiavi o il numero di passaggi per crittografare e decrittografare il messaggio.

Scrivi la tua posta su cryptool e quindi cripta la posta secondo la procedura condivisa tra due di voi. quindi copia il codice crittografato nel campo di testo gmail della posta di comporre di gmail. quindi invia al client.

Il client riceve il messaggio crittografato di cui ha bisogno per copiare il messaggio crittografato e poi lo mette sullo strumento di crittografia e segue i passaggi per decodificare il messaggio per recuperare il messaggio originale.

So che questa procedura è un po 'lunga, ma seguendola sarai sicuro al 100%.