Seguridad del correo electrónico [duplicado]

Eso dependerá de cómo configuren sus servidores de correo. Normalmente, la conexión entre los servidores de correo también se puede cifrar mediante TLS / SSL. Dado que MS y Google están ejecutando Gmail y Hotmail, normalmente esto debería estar habilitado. (por suerte solo Gmail hace esto, y no lo obligan si el otro extremo quiere hablar claro)

Si no está seguro, siempre puede usar GPG / PGP

EDIT

Posible otra respuesta aquí: Qué pasos realiza Gmail, Yahoo! ¿El correo y Hotmail se toman para evitar las escuchas en el correo electrónico?

Los servidores SMTP de Hotmail no utilizan la seguridad TLS en el transporte ... la actividad SMTP detrás de escena que hace que el mensaje aparezca en los diferentes ISP. Puede validar esto mirando los encabezados SMTP. En Gmail, debe hacer clic en "ver original" para ver estos encabezados.

Gmail, Yahoo y muchos otros proveedores cifran mensajes en transporte con seguridad TLS. Por alguna razón, Hotmail no.

Algunos proveedores de correo electrónico utilizan el cifrado TLS de manera oportunista (cuando parece que tanto el remitente como el receptor lo admiten; esto se describe en RFC 3207 ). Tenga en cuenta que dicha detección oportunista no puede proporcionar una seguridad absoluta: los mensajes que el remitente y el receptor intercambian, y qué estado indica si STARTTLS es compatible o no, están desprotegidos. Un atacante que haga un hombre en el ataque central puede interceptar estos mensajes y forzar al remitente y al receptor a no utilizar TLS. Para habilitar la protección contra tales ataques, los servidores SMTP no solo deben usar TLS, sino que también deben negarse a hablar con el otro servidor a menos que se pueda usar TLS.

En la práctica, el cifrado oportunista brindará cierta protección contra escuchas pasivas : personas de grandes orejas un tanto legendarias que hacen tapping en los enlaces de la red y escuchan pero nunca interfieren. Un punto importante es que mientras TLS protege los datos mientras se encuentra en tránsito, no hace nada por datos en reposo : los servidores involucrados (los servidores SMTP a través de los cuales pasa el correo electrónico y los servidores IMAPS o HTTPS-Webmail que alojar la carpeta "Bandeja de entrada" del destinatario y la carpeta "Mensajes enviados" del remitente) ver los datos sin cifrar y escribirlos en los discos duros. Los contenidos del correo electrónico son vulnerables en estos puntos.

Si fuera un espía (contratado por una agencia financiada por el Estado o, como suele ser el caso en la actualidad, contratado por sus competidores), no me ocuparía de los problemas técnicos para localizar los cables de comunicación y enchufarlos; Sobornaría a uno o dos internos que trabajan en su ISP, y los convertiría en cintas o discos de copia de seguridad antiguos (con el uso generalizado de RAID , se pueden robar discos completos sin siquiera detener el servicio, por lo que discretamente ). No la cantidad de STARTTLS lo protegerá contra eso.

Como dice @Lucas, si te tomas en serio la seguridad del correo electrónico, necesitas una protección integral: S / MIME o OpenPGP (por ejemplo, GnuPG implementación de este último).

También puede estar interesado en esta respuesta

  

Para responder a tu pregunta resumida: ¿Qué tan inseguro es el correo electrónico?   El correo electrónico prácticamente está sujeto a ataques por parte de falsificación de DNS ,   La intercepción de WIFI y los administradores de red no confiables solo para nombrar a   pocos.

     

Para mitigar esto necesita considerar los diferentes aspectos que necesitan   seguridad. Es probable que la mayoría de las empresas pierdan seguridad en   al menos una de las siguientes áreas, por lo que cualquier cosa que envíe podría estar en   Texto claro y visible por alguien que no sea su destinatario.

     

Bajo cada faceta de seguridad, enumeré los productos relevantes agrupados por cómo   Se implementan técnicamente. Hágase estas preguntas basadas   en el contenido que está enviando por correo electrónico:

     

Verificación del remitente del mensaje

     

¿Necesita el destinatario una prueba de que fue usted quien envió el mensaje?

     

• SenderID / Registros SPF (verificación débil)
  
• Claves de dominio / DKIM (la fuerza depende de la implementación)
  
• DMARC (validación sólida de la pantalla del usuario ... híbrido de SenderID y DomainKeys)
  
• PGP o s / MIME (puede causar problemas de cumplimiento si se requiere registro en diario o auditoría de mensajes)
  
• Productos basados en portal (Voltage, Proofpoint, Zixmail)
  
• Microsoft RMS + Outlook
  

Transporte de mensajes
¿Debo evitar la lectura o modificación no autorizada del MTA del remitente del correo electrónico y de mi MTA?

     

• TLS forzado, con validación de certificado. Los certificados no validados están sujetos a ataques de MITM .
  
• TLS basado en Zix es una red TLS privada que no requiere configuración manual
  
• PGP o s / MIME (puede causar problemas de cumplimiento si se requiere registro en diario o auditoría de mensajes)
  
• Productos basados en portal (Voltage, Proofpoint, Zixmail)
  
• Microsoft RMS + Outlook
  

Leyendo el mensaje

     

¿Debo asegurarme de que solo el destinatario pueda leer el contenido del mensaje?

     

• PGP o s / MIME (puede causar problemas de cumplimiento si se requiere registro en diario o auditoría de mensajes)
  
• Productos basados en portal (Voltage, Proofpoint, Zixmail)
  
• servidor RMS de Microsoft
  

¿Debe ser seguro el punto final del cliente? (se aplica si no se utilizan más de 3 productos)

     

• El administrador de la red de destino está entregando correo electrónico usando un transporte seguro (MAPI cifrado, POP3 sobre TLS, etc.)
  
• El dispositivo de destino es seguro. Esto se aplica a las estaciones de trabajo y a los dispositivos mobile .
  
• Microsoft UAG agrega funciones a OWA donde se audita el punto final y se eliminará archivos adjuntos sobrantes en %temp% y restringir   o denegar el acceso a las funciones según lo exija la política
  
• Una alternativa a UAG es bloquear adjuntos para que no lleguen al cliente (como mencionó Henri por primera vez)
  

gmail.smtp.com usa dos paquetes SASL y TLS. Cuando presione gmail.smtp.com en el puerto 587, le pedirá al usuario / pase que le proporcionará el paquete SASL y el paquete TCP TLS obtendrá el cifrado del usuario / pase. Puede usar el script tcl con este paquete para enviar un correo. .

Si le preocupa la seguridad de su correo electrónico, la única forma de tener una confianza razonable es administrar el cifrado usted mismo, utilizando algo como PGP / GPG. Algunos puntos a tener en cuenta

• Cuando usa un cliente web, https solo encripta su comunicación al servicio de correo que está usando. No proporciona ninguna garantía con respecto al nivel de cifrado que se produce durante el proceso de transporte de mensajes que se produce entre los servidores

• Algunos servidores SMTP son compatibles con TLS, etc., si se les pide que lo utilicen. Sin embargo, no hay nada en la especificación del protocolo SMTP que requiera que lo hagan. Muchos servidores SMTP no lo proporcionan.

• No tiene ninguna garantía con respecto a los servidores de correo por los que se pasará un mensaje. Muchas personas piensan que cuando envía un mensaje del servidor a al servidor b, el mensaje siempre se pasa como una conexión directa entre esos dos servidores. Esto no necesariamente es cierto. El protocolo SMTP se diseñó en un momento en que las redes y los sistemas de transferencia eran mucho menos confiables de lo que son ahora y cuando muchos lugares no tenían conexiones directas a la red central. Para habilitar la entrega confiable de correo, el protocolo admite la retransmisión de correo. En términos simplistas, el servidor de correo de envío puede decir "Hola, tengo un mensaje para gmail, pero parece que no puedo criarlo y tengo que ir y actualizar mi kernel. ¿Puede alguien pasarme este mensaje por mí cuando?" ¿Él regresa? Lo haría, pero tengo que actualizar mi kernel y no estará disponible por un tiempo ". Otro servidor, posiblemente desconocido hasta ahora, puede responder diciendo: "Oye, soy un host MX para tu dominio de destinatario, puedo transmitirte el mensaje".

Si bien todo esto significa que el correo electrónico suele ser bastante sólido, en el sentido de que el correo enviado a una dirección legítima generalmente se entrega con éxito o se recupera y rara vez desaparece, crea algunas debilidades en el protocolo que expone el sistema a una serie de explotaciones, como la falsificación de DNS. Incluso si ignora el aspecto de transporte del correo electrónico, también existe el problema de que los mensajes se guardan de forma rutinaria en servidores sin cifrar, como en las direcciones de correo electrónico, lo que hace que sean fácilmente accesibles para cualquier persona con suficientes derechos de acceso en el servidor. Incluso olvidando eso, ¿cuántas de las personas a las que ha enviado correo para almacenar o archivar ese correo de manera segura y encriptada? Si le envié un mensaje con datos confidenciales, ¿lo cifra antes de almacenarlo en su archivo de correo? ¿No? Entonces, ¿qué sucede con mi mensaje de correo confidencial cuando su computadora está infectada con un virus o malware? ¿Qué control tengo sobre esta información confidencial una vez que te la envíe?

La infraestructura de correo electrónico se diseñó en un momento en que la seguridad no era una prioridad alta. El enorme crecimiento y el deseo de mantener todo funcionando y la necesidad de mantener la compatibilidad con versiones anteriores significa que muchas de las mejoras que se han introducido, como el cifrado de la comunicación entre servidores, etc. son opcionales y, por lo tanto, no se pueden garantizar y, aunque ha habido muchas mejoras Al final del día, debe considerar el correo electrónico como un canal de comunicación intrínsecamente inseguro. A menos que el remitente y el destinatario tomen medidas adicionales para aumentar la seguridad de las comunicaciones por correo electrónico, debe considerar el mensaje como inseguro, incluso si cree que las compañías que mantienen los servidores involucrados son de buena reputación y aplican buenas prácticas.

También debemos mantener las cosas en perspectiva. ¿Qué parte del correo que envías contiene información que es realmente confidencial? ¿De qué valor real es esta información para otra persona? ¿Con qué facilidad podría alguien obtener esta información y el costo de hacerlo es menor que el valor obtenido? La seguridad rara vez debe considerarse en términos de si es segura o insegura. La pregunta debería ser si es lo suficientemente seguro para el propósito para el que lo uso. ¿El correo electrónico es lo suficientemente seguro para mi saludo de Navidad que le envío a mi abuela? Casi con seguridad. ¿Es lo suficientemente seguro para que mi banco envíe el código de acceso o PIN de mi cuenta? Definitivamente no. ¿Hay formas de aumentar la seguridad de los mensajes? Sí, pero todos vienen con un costo de conveniencia. Por ejemplo, PGP / GPG y el cifrado de su mensaje. Proporcionan una buena seguridad adicional, pero disminuyen la comodidad de la comunicación por correo electrónico. Ahora tiene que crear y administrar claves de cifrado y su destinatario debe configurar su cliente para que use su clave pública para desencriptar su mensaje antes de que puedan leerlo. Si el contenido es lo suficientemente sensible y valioso, este mayor inconveniente puede valer la pena. Muchas veces no lo es.