Sé que hasta hace unos años, alguien podría configurar un AP inalámbrico falso y usar algo como SSLStrip para atraer a las víctimas a conectarse a versiones inseguras de los principales sitios web, como Gmail, Facebook, etc. Aunque, tenían HSTS esto todavía era posible. Pero ahora, como veo, esto ya no es posible para los principales sitios web. Lo que ha cambiado desde hace unos años. ¿Cómo HSTS ahora previene este tipo de ataques MitM?
El encabezado HSTS detiene los ataques MitM indicando al navegador que siempre envíe una solicitud HTTPS (a diferencia de HTTP) al dominio hasta que la política caduque. Por lo tanto, un navegador que respete el encabezado enviaría una solicitud a https://example.com incluso si el usuario hiciera clic en un enlace a http://example.com .
La lógica detrás de HSTS no ha cambiado desde que se definió en un RFC en 2012. Lo que ha cambiado es que hoy Casi todos los navegadores lo implementan. ¡Recuerda que es el navegador el que hace cumplir esta política! ¿Puedo usar los navegadores de informes compatibles con las siguientes versiones:
(Para mí, cómo es que Firefox y Chrome lograron soportar HSTS antes de que se publicara el RFC)
Por lo tanto, las personas que usan navegadores más antiguos no estarán protegidos incluso si el encabezado está configurado. Eso podría explicar por qué tiene la impresión de que la configuración del encabezado HSTS no se usó para ayudar con SSLStrip anteriormente.
Otra razón para que el HSTS no ayude puede ser que el usuario nunca haya visitado la página antes del ataque. Si el navegador nunca ha visto el encabezado, no puede imponerlo. Esto se puede resolver con precarga .
SSLStrip trabajó reescribiendo https solicitudes a llanura http , eliminando la protección y permitiendo tanto la escucha como la modificación.
Un servidor con protección HSTS establecerá un encabezado en una solicitud HTTPS pidiéndole al navegador que se comunique solo con ese servidor utilizando HTTPS:
Strict-Transport-Security: max-age=31536000
En este caso, durante un año, el navegador solo se conectará al servidor en HTTPS y reescribirá todos los enlaces para que sean HTTPS (un SSLStrip invertido).
Pero hay una advertencia: el cliente debe haber accedido al servidor usando HTTPS al menos una vez. Si el cliente solo se conecta a través de HTTP, MiTM aún puede ocurrir, todas las solicitudes pueden modificarse y cualquier enlace o redirección de HTTPS se puede cambiar de nuevo a HTTP. Pero tan pronto como el cliente accede al servidor mediante HTTPS, se establece la cookie HSTS y ya no son posibles los ataques SSLStrip MiTM.
Lea otras preguntas en las etiquetas network man-in-the-middle hsts