La mayoría de los sitios web de comercio electrónico utilizan SSL / TLS cuando desea iniciar sesión. Pero la mayoría tiene página de inicio usando solo http. ¿Es suficiente tener SSL / TLS en la página de inicio de sesión y en la página registrada para evitar sslstrip?
La verificación del uso correcto de HTTPS es, en última instancia, responsabilidad exclusiva del usuario. Los usuarios deben ver al menos 3 puntos cuando visitan una página web:
Se requiere responder sí a estas 3 preguntas para que HTTPS se use correctamente.
No habilitar HTTPS en la página inicial no es necesariamente el fin del mundo. Esta página puede ser vulnerable a los ataques SSLStrip, pero es posible que no sea necesario transferir de forma segura lo que se encuentra en esa página.
La mayoría de los sitios web pueden tener una página de bienvenida HTTP simple, aunque solo sea para realizar una redirección a HTTPS o enviar la primera encabezado HSTS . De hecho, esto puede ser vulnerable a SSLStrip en esta etapa, pero debe haber un punto de partida si el usuario no sabe qué esperar (y la mayoría utilizará primero las URL http:// ). Las redirecciones automáticas pueden (solo) mitigar el riesgo . La única forma de evitar esto es que el usuario sepa que solo funcionará https:// URI o que el sitio sea parte de la lista HSTS precargada .
(Ningún sitio web es seguro contra SSLStrip si el usuario o el navegador no esperan que se use HTTPS. Esta expectativa se puede activar automáticamente en el navegador a través de HSTS, ya sea a través de una primera visita desde una red donde el ataque no se ha producido. T ha tenido lugar, o a través de la lista precargada.)
No. La falta de HTTPS en la página de inicio no evitará SSLStrip. Si alguna de las conexiones se transmite en texto sin formato (es decir, HTTP), se puede detectar y la sesión podría ser secuestrada. HTTPS debe usarse para todas las páginas que necesitan ser protegidas, y deben utilizarse Encabezados HSTS .
Cada vez que los usuarios ingresan por primera vez a una página http: en la Web (a diferencia de un archivo local o una página en un servidor local), existe el riesgo de que un proxy HTTP malvado altere https: enlaces a:
http: links https: enlaza con otro sitio web, con un nombre similar (example-login.com en lugar de example.com) Cualquier banco con una página principal de http: que se enlaza a una página de inicio de sesión https: no comprende la seguridad , punto final.
El banco debe entender que proporcionar un servidor "seguro" (servidor HTTPS) no es suficiente, un usuario razonable y responsable debe estar conectado a este servidor en todos los casos. (Un usuario que sigue los enlaces en los correos electrónicos es, por definición, irrazonable).
Se puede esperar que un usuario recuerde (o escriba) el nombre de dominio principal de su banco ( uno nombre de dominio), para no saber cada otro dominio que su banco pueda usar para cualquier propósito . Agregue el hecho de que muchos usuarios no entienden la naturaleza jerárquica del DNS, por lo que no pueden reconocer que secure-login.mybank.com es un subdominio de mybank.com pero mybank.secure-login.com, mybank-secure-login. com y secure-login-mybank.com no lo son. No son estúpidos, solo ignoran los principios básicos del DNS y no están dispuestos a aprender estos tecnicismos. No se puede esperar que los usuarios reconozcan que un nombre de dominio es legítimo a menos que conozcan este nombre de dominio completo y completo.
Se debe garantizar al usuario que llegue al lugar correcto con solo reglas simples y sencillas. Las reglas "negativas", como "compruebe que se detienen si detecta un problema" son difíciles de aplicar de manera coherente:
Otro problema es que en el mundo físico, los objetos falsos pueden ser reconocidos porque tienden a ser una imitación pobre de los reales, y muchas características son objetos físicos sensibles a la seguridad (billetes, tarjetas de crédito) que están diseñados para ser muy difíciles para imitar, y nuestra intuición está entrenada para observar las propiedades del objeto para detectar imitaciones. Cuando se trata de un sitio web, esta intuición es totalmente errónea: la imitación de una página web se ve tan bien como la original, de hecho, es la original , poco a poco ( e incluso la ley conlleva la confusión de que hacer copias ilegales es lo mismo que hacer una imitación).
Cuando se trata de un sitio web de banco falso (comercio electrónico, ISP, social ...), solo la URL (la dirección) será diferente. La página de inicio de sesión tendrá el mismo aspecto (a menos que el ladrón sea incompetente, lo que también ocurre).
Además, hemos recibido capacitación sobre la idea de que podrían existir billetes de banco falsos, no bancos falsos.
OTOH, una regla "positiva" como "ingrese esta URL" es imposible de olvidar, porque si la olvida, su navegador (por lo general) no va a ninguna parte. Entonces, si un día su navegador accede a un sitio web que se parece a su banco (comercio electrónico, ISP, redes sociales ...) y no ha ingresado la URL correcta, sabe que algo está mal (al menos extremadamente sospechoso) .
En la práctica, dado que el usuario no es un robot , el procedimiento seguro recomendado debería consistir, de manera ideal, en solo reglas positivas. El navegador es un robot, por lo que debe implementar todas las reglas negativas (SSL / TLS tiene muchas reglas negativas).
Lea otras preguntas en las etiquetas tls http sslstrip http-proxy