¿Opciones al defenderse contra SSLstrip?

Estas son mis recomendaciones sobre lo que los usuarios pueden defenderse contra SSLstrip, Firesheep y ataques similares:

• Instale HTTPS Everywhere o ForceTLS. (HTTPS Everywhere es más fácil de usar). Esto le dice a su navegador que use las versiones SSL de los sitios web, donde sea posible.

• Si el navegador le da una advertencia de certificado, no omita la advertencia y no continúe navegando en ese sitio web.

• Para los sitios críticos, como la banca en línea, vaya a la versión HTTPS (SSL) del sitio desde su máquina mientras usa una red segura y luego marque esa página. Luego, siempre abra el sitio abriendo el marcador cuando quiera ir a esa página. Nunca escriba su dirección en la barra de direcciones o en la barra de búsqueda.

• Si solo va a navegar por un solo sitio, considere configurar un navegador específico para el sitio. Probablemente esto no sea necesario para la mayoría de los propósitos, pero proporcionará seguridad adicional contra algunos ataques; podría ser apropiado, por ejemplo, para empresas que utilizan la banca en línea.

• De forma alternativa, en lugar de HTTPS Everywhere, puede realizar su navegación web a través de un servicio VPN.

• Configure su cliente de correo electrónico para usar SSL (también conocido como TLS) y para verificar la validez de los certificados. Esto asegurará que la conexión al servidor de correo electrónico esté encriptada.

Estas son mis recomendaciones sobre lo que pueden hacer los sitios web para proteger a sus usuarios contra Firesheep, SSLstrip y ataques similares:

• Habilitar SSL en todo el sitio (es decir, HTTPS).

• Habilitar HSTS (Seguridad de transporte estricta de HTTP).

• Asegúrese de que su certificado sea válido. Considere comprar un certificado de Validación ampliada (EV), para sitios más críticos para la seguridad.

• Habilite las cookies seguras, es decir, asegúrese de que todas las cookies se sirvan con el atributo seguro, de modo que los navegadores de sus usuarios solo las reenvíen a través de conexiones protegidas con SSL y nunca las divulguen a través de ningún protocolo no SSL (HTTP ) enlace.

• Deshabilite el acceso HTTP (no SSL), o redirija a los usuarios a la versión SSL del sitio web.

• Evite o minimice el uso de bibliotecas de JavaScript de terceros, widgets, como botones, etc. O, si debe usarlos, asegúrese de que se sirvan desde una URL https: y que el sitio que los aloja sea uno usted confía.

En un tema diferente, los administradores de servidores de correo pueden proteger a sus usuarios habilitando la protección SSL / TLS para IMAP (o, mejor aún, requieren el uso de SSL / TLS en todas las conexiones) y habilitando STARTTLS en sus servidores SMTP.

Usando la regla de Privoxy:

echo '{ +redirect{s@http://@https://@} }
.foo.org' >> /etc/privoxy/user.action

lo redireccionará a HTTPS si un sitio está en la lista blanca. En el ejemplo, www.foo.org y foo.org y subdomain.foo.org solo pueden usar HTTPS porque el proxy lo redirige. Si hay un mitm SSLStrip, entonces la página simplemente se cargará y cargará y cargará ... no será accesible. Creo que esta sería una muy buena solución (fixme).

Cuando visita el sitio web seguro SSL o ssh para hospedar, acepta el certificado. Si el certificado no se valida con los servidores públicos de la Autoridad de certificados, o cualquier CA local, su navegador le advierte sobre el certificado incorrecto. Por lo tanto, si desea proteger su tráfico de los ataques ARP, debe usar un certificado SSL válido y no navegar por los sitios web que advierten sobre un certificado no válido. Con SSH, si se cambió el certificado, SSH le informará sobre el cambio de clave pública.

SSLStrip simplemente redirige a las versiones http de la página. Desde el lado del servidor, puede introducir cosas como mensajes o imágenes que indiquen que "su navegador ha sido secuestrado" o algo similar. Si se encuentra en un entorno controlado, esto se puede manejar con un proxy web transparente en línea que reemplaza todo el contenido http de esta manera. Similar a la respuesta de forcetls, etc., pero manejando el problema en el lado del servidor. De esta manera, no tiene que preocuparse por pebkac y dispositivos no autorizados. Sólo un par de pensamientos.