Cifrado de correo electrónico para gmail

Depende de lo que estés protegiendo -

lea esta pregunta sobre los pasos que debe seguir google, Yahoo! Tomar para proteger el correo web .

También vea esta pregunta y ofrezca soluciones alternativas para el envío de datos. Tiendo a usar pgp / gpg para cifrar antes de enviar correos electrónicos, cuando sea posible, o usar un correo seguro alojado (similar al descrito en @Paul) para algunos clientes.

Puede asegurar la conexión bastante bien, pero a menos que cifre sus datos antes de enviarlos, residirá en los servidores de Google de forma clara. Esto puede estar bien, pero puede que no, todo vuelve a la sensibilidad de los datos en esos mensajes.

Si tanto su amigo como sus clientes usan gmail, entonces la seguridad no es tan mala ... todas las transferencias de datos entre la máquina de un usuario y gmail se realizan a través de HTTPS, y si el remitente y el receptor usan gmail, el correo electrónico nunca abandona las máquinas de Google . Entonces, mientras confíes en Google , está bien.

"Confianza" es una palabra desagradable. En el párrafo anterior, significa que Google no revela voluntariamente los contenidos del correo electrónico, y también que hacen un buen trabajo para proteger sus servidores (usted confía en que sean honestos y confía en que sean competentes). Pero, en última instancia, alguien en quien confías es alguien que tiene el poder de traicionarte.

Además, se sabe que Google analiza los correos electrónicos de los usuarios de gmail, de modo que puede elaborar anuncios dirigidos para mostrarlos a los usuarios. Esto implica, al menos de manera teórica, que los datos de sus correos electrónicos necesariamente fluyen desde los servidores de Gmail hacia los anunciantes. Un pensamiento reconfortante.

Para ser mejor que Gmail, necesita un cifrado de extremo a extremo. Los productos clásicos son S / MIME y PGP ; el primero es compatible con las aplicaciones de correo electrónico convencionales directamente, pero implica certificados X.509, lo que puede ser una molestia para la configuración. PGP generalmente requiere complementos, pero tiende a ser más fácil de usar. Tenga en cuenta que la mayoría de los correos web son incompatibles con S / MIME o PGP: aplicación web de Outlook puede hacer S / MIME con un control ActiveX específico en el sistema cliente (solo Windows / IE, por supuesto), pero la mayoría de los otros sistemas de correo web no pueden. Hasta cierto punto, los correos electrónicos de PGP pueden manejarse externamente transfiriéndolos con copy & paste (el formato normal de los correos electrónicos de PGP es "ASCII-armor", que debe ser transferible como texto simple).

Para comunicaciones de un solo disparo, considere archivos Zip con una contraseña (la contraseña se intercambia por teléfono). Las implementaciones de Zip más antiguas utilizaban un cifrado de flujo personalizado personalizado (en realidad, un buen ejemplo de por qué los diseños hechos en casa deberían evitarse). Los nuevos archivadores Zip (WinZip 9.0 y posteriores, al menos) usan AES, que es mucho más fuerte. Todo se reduce a lo que el cliente está listo para instalar cuando se lo pregunta tu amigo.

Para evitar que los clientes necesiten configurar y administrar sistemas de encriptación en sus dispositivos para comunicarse con el contador, un almacén de archivos seguro como Accellion puede ser una opción.

Esto funciona como webmail. Redacta su correo electrónico en el portal de Accellion, adjunta su archivo y lo envía al cliente. El archivo en sí no se envía, sino que se reemplaza por un enlace. El cliente recibe el correo electrónico y hace clic en el enlace para descargar a través de https el archivo.

Igualmente, pueden usar el servicio del contador para enviar archivos al contador (pero no a nadie más).

Debería echar un vistazo al proyecto Mailvelope . Es una extensión de Google Chrome que implementa algunos de OpenPGP para Webmail. La interfaz de usuario es simple y limpia.

Aunque no estoy de acuerdo con Luxsci (un proveedor de encriptación de correo electrónico), TLS es todo lo que se requiere para el nivel de encriptación para el cumplimiento con HIPAA. No sé qué leyes tiene un contador para regular su industria, pero Luxsci tiene un comprobador TLS GRATUITO en: enlace

Basaría mi decisión en los requisitos específicos de la industria. Si se requiere el cifrado, entonces es posible que desee considerar un producto comercial que sea fácil de usar como áspero, webroot, zixmail, etc. Sin embargo, puedo decir que para evitar la tendencia, micro tiene un producto horrible de la experiencia personal y desde que me cambié, los proveedores ya no tienen ese problema.

Nota adicional: hay 2 métodos principales para el cifrado comercial, push and pull.

Push envía un correo electrónico que contiene un archivo adjunto que está realmente encriptado y usted descifra el mensaje localmente. ALGUNAS empresas y hospitales definitivamente BLOQUEAN esto ya que no pueden leer el contenido. Le aconsejaría que se mantenga alejado de esto si es posible.

Pull envía un correo electrónico en el que haces clic en un enlace que te lleva a un portal web para recuperar tu mensaje y tus archivos adjuntos. Esta técnica no debe activar reglas de firewall o bloquearse debido a la forma en que se entrega.

Bueno, gmail usa https en todas partes, por lo que el envío / recepción debe ser seguro. Creo que tienen una buena política de privacidad, ¿está diciendo que necesita seguridad adicional en caso de que un empleado de Google se convierta en un espía o alguien rompa la contraseña de la cuenta de correo electrónico de alguien? Lo primero no creo que quieras, pero lo último podría resolverse con la verificación en dos pasos.

¿Realmente necesitas más? Si lo hace y cree que un empleado se convertirá en un espía o Google será pirateado y sus correos electrónicos / archivos se copiarán, por supuesto, cifre con pgp

Los únicos estándares de cifrado de correo electrónico principales son PGP y S / MIME. Ambos trabajan, ambos son efectivos. Pero tampoco funcionará con una interfaz de correo web, ya que son del lado del cliente. De hecho, si se encuentra con un mecanismo que SÍ funciona con la interfaz de correo web, debe sospechar de su seguridad.

La mayoría de los proveedores de correo electrónico (incluido GMail) admiten IMAP o POP3 junto con SMTP. Puede usar esto para conectar su buzón de correo con un lector de correo de escritorio, como Thunderbird. Luego, puede usar un motor de cifrado del lado del cliente (como enigmail o las utilidades S / MIME incorporadas) para acceder a las funciones de criptografía.

Obviamente, ambos lados de la conversación deben estar utilizando el mismo sistema de cifrado, pero ese es siempre el caso. Además, esto es intrínsecamente inconveniente, y probablemente siempre lo será.

Finalmente, probablemente la forma más sencilla de intercambiar contenido cifrado es como un archivo adjunto. Use una herramienta como 7-zip para crear un paquete encriptado con el contenido que desea proteger, y use una contraseña que fue preestablecida fuera de banda (por ejemplo, por voz o en persona).

El problema, incluso con el cifrado de Office (que ha mejorado significativamente cuando se trasladaron al formato XML) es: si está utilizando una contraseña segura, ¿cómo se compartirá?

Parece que una opción simple sería utilizar un sistema comercial de intercambio de archivos seguro, alojado en las instalaciones. Luego, la transferencia podría cifrarse utilizando SSL, y sus clientes no tendrían que lidiar con el cifrado. Dado que se encuentra en las instalaciones o en un servidor dedicado, no hay un tercero que pueda acceder a los archivos almacenados.

Pero tenga en cuenta que al hacer eso, él tiene que poder administrar ese sistema y mantenerlo seguro. Eso también es un riesgo.

Podría valer la pena considerar cosas como Spideroak y Wuala, que son servicios similares a Dropbox con cifrado basado en el cliente.

Sin embargo, como contador, nunca querría tener que pedir a mis clientes que instalen software. Básicamente, lo que sería mejor sería un sitio como Mega pero más centrado en la seguridad de lo que es ahora. Realiza el cifrado del lado del cliente a través de Javascript en el navegador, por lo que, si bien tiene que confiar en ellos para que entreguen el código adecuado a su navegador, en teoría no pueden descifrar lo que está almacenado en su sistema.

He estado en una situación similar. La única opción que encontré universalmente aceptable para usuarios finales de todos los niveles de habilidad fue enviar archivos en un archivo .zip cifrado como archivos adjuntos. En Linux, estos archivos son fáciles de crear con el indicador -e para 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

Los usuarios en Windows o mediante una interfaz gráfica en Linux (KDE, Unity, Gnome) pueden crear archivos .zip cifrados haciendo clic con el botón derecho en un archivo y seleccionando la opción "Cifrar" de zip , y puede descifrar simplemente haciendo doble clic.

En mi opinión:

Tanto usted como el cliente instalan una cryptool en su máquina desde

Descarga cryptool

ambos deben aprender cómo usarlo

Aprende cryptool con la ayuda del video de youtube.com

luego puedes compartir algunas claves o varios pasos para cifrar y descifrar el mensaje.

Escriba su correo en cryptool y luego cifre el correo según el procedimiento compartido entre dos de ustedes. y luego copie el código cifrado en el campo de texto de gmail del correo electrónico de redacción de gmail. Luego, envíelo al cliente.

El cliente recibe el mensaje cifrado que tienen para copiar el mensaje cifrado y luego lo coloca en la herramienta de cifrado y sigue los pasos para descifrar el mensaje para recuperar el mensaje original.

Sé que este procedimiento es un poco largo, pero si lo sigues estarás 100% seguro.