Correo web realmente seguro

Question

Correo web realmente seguro

#1 de D.W. (1 votos)
#2 de Justin Andrusk (0 votos)

1

Si me siento paranoico con respecto al CCDP (Reino Unido) - ISP para interceptar comunicaciones a través de Internet, ¿cuál sería el enfoque más seguro para un sistema de correo web?

Obviamente, hay algunas cosas legales / políticas (puedo confiar en las personas que lo manejan, puedo confiar en la jurisdicción legal en la que se encuentra, etc.) pero a nivel técnico, ¿cuál sería un enfoque sólido para dirigir un ¿Un servicio de correo web que no puede ser resuelto por un ataque MITM ejecutado por los ISP de mis usuarios?

Me parece que hay varias cosas que marcarán la diferencia en comparación con un servicio comercial típico como Gmail:

HTTPS, utilizando TLS v.1.2 con opciones de cyphersuite bien seleccionadas (no estoy seguro de qué cyphersuites sería correcto). Ahora que OpenSSL 1.0.1 está fuera, es posible que se requiera TLS 1.2, aunque se bloquearían los navegadores dependientes de NSS (Firefox y Chrome, lo que significa que Opera solo en sistemas operativos que no sean Windows; Safari / Win es compatible con TLS 1.2, pero no Safari / Mac).
No JavaScript (y, por lo tanto, no AJAX), con posiblemente una pequeña pieza de JavaScript que impide el acceso al sitio si JS está activado en el cliente.
Ofrezca todo contenido desde un único nombre de dominio / dirección IP (sin dominio "estático", sin anuncios, sin Google Analytics, etc.).

No tengo la intención de implementar un servicio de este tipo (para empezar, no estoy en una jurisdicción legal adecuada), pero estoy seguro de que hay otras cosas que se podrían hacer.

¿Alguna sugerencia, pensamiento?

web-application tls

pregunta Richard Gadsden 07.04.2012 - 23:14

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application tls

¿Cómo puede una parte confiada de SAML redirigir a uno de dos IDPs? ¿Captura SNMP por programa legítimo?

score 1 · Answer 1

Las cosas principales que puedes hacer son:

Use SSL en todo el sitio . Desactive el acceso HTTP (no SSL) o redirija a los usuarios a la versión SSL del sitio web.
Use HSTS para declarar a los clientes que solo deben conectarse mediante SSL.
Asegúrese de que todas las cookies tengan el indicador de seguridad establecido. Esto asegurará que los navegadores de sus usuarios solo reenvíen esas cookies a través de conexiones protegidas con SSL y nunca las divulgarán a través de ningún enlace que no sea SSL (HTTP).
Agregue su sitio a la lista codificada de Chrome de sitios HSTS (la lista precargada de HSTS ).
Agregue la clave pública de su sitio a Lista de identificación de claves públicas de Chrome , si te dejarán.
Verifique que su servidor SSL esté configurado correctamente, usando verificadores de configuración SSL estándar: por ejemplo, SSL Labs .
Asegúrese de que su certificado sea válido.
Considere comprar un certificado de Validación ampliada (EV). También puede mencionar en algún lugar de la sección de soporte de su sitio que anima a los usuarios a verificar el brillo verde en la barra de direcciones cada vez que visitan su sitio. (Probablemente esto no será muy efectivo, pero podría ayudar un poco).
Considere proporcionar un enlace a Chrome y HTTPS Everywhere en su sitio web en alguna parte.
Configure su servidor web para defenderse contra el ataque BEAST . Habilitar TLS 1.2 es una buena idea, pero también puede elegir cuidadosamente el orden de preferencia de los algoritmos, para ayudar a proteger a los usuarios cuyos navegadores aún no son compatibles con TLS 1.2 (que serán prácticamente todos ellos en este momento).
Si proporciona acceso a través de IMAP, asegúrese de que solo admita IMAPS (la versión habilitada para SSL), no el IMAP de texto simple.
Habilite STARTTLS en su servidor SMTP.
Evite el uso de widgets de JavaScript de terceros (por ejemplo, bibliotecas, widgets, como botones, etc.). No cargues contenido externo sobre http.

No intentaría evitar el uso de Javascript. Especialmente no intentaría bloquear el acceso a los usuarios que tienen Javascript habilitado. Eso es un desastre de usabilidad, por poco o ningún beneficio de seguridad.

Consulte también Guía para implementadores de sitios que solo utilizan HTTPS (lado del servidor) .

score 0 · Answer 2

Ya que sé que todos los proveedores de DLP (Prevención de pérdida de datos) realizan MITM en las conexiones SSL junto con los proveedores de Proxy, realmente no hay nada que puedas hacer. La debilidad está en el protocolo y no en la aplicación. Recomendaría usar una solución de dos factores usando algo como Yubikeys, pero no estoy seguro si eso evitaría el secuestro de las sesiones. Si los certificados pudieran construirse sobre la marcha, se usaría la OTP que proporciona Yubkikey que podría hacer el truco. SSL / TLS se debe reescribir para tener en cuenta MITM.

enlace