Entiendo que ejecutar un sitio web con HSTS puede ayudar a evitar que un atacante que usa KRACK para degradar el sitio web para atender solicitudes HTTP.
¿Qué pasa si nuestro servidor web no es compatible con HSTS?
IIS tiene una configuración para un sitio web en el que solo puede requerir solicitudes SSL.
¿Será eso suficiente para evitar que el atacante utilice SSLstrip para bajar de HTTPS a HTTP? Supongo que el servidor web no servirá el tráfico que no sea HTTPS, ¿correcto?
¿Será eso suficiente para evitar que el atacante utilice SSLstrip para bajar de HTTPS a HTTP?
No.
Supongo que el servidor web no podrá atender el tráfico que no sea HTTPS, ¿correcto?
No.
El MitM hablará https con su servidor y http con el cliente.
La única defensa real contra sslstrip es HSTS.
Según enlace puede configurar HSTS con IIS con el Cuadro de diálogo "Agregar encabezado de respuesta HTTP personalizado".
Nota: HSTS solo está activo después de una primera visita https exitosa. Para proteger la primera visita, puede utilizar el mecanismo de precarga: enlace pero tenga cuidado, ¡no se puede deshabilitar después!
Ir solo a HTTPS no ayuda a protegerte en este caso. Esta otra pregunta debería ayudar a ilustrar por qué. En resumen, si un atacante puede obligar a un cliente a comunicarse a través de HTTP, entonces el atacante puede interponerse entre usted y el cliente y actuar como un relevo: hablar con el cliente en HTTP y con el servidor en HTTPS.
Sería bueno si hubiera una forma de forzar al cliente a que nunca intente realizar una llamada HTTP a su servidor. Afortunadamente, puede hacerlo con HSTS. Pero la configuración típica de HSTS protege a sus usuarios si, y solo si, puede establecer una conexión segura antes de un intento de ataque. Esto se debe a que HSTS se basa en un modelo de Trust On First Use o TOFU. Si puede obtener un encabezado HSTS en la máquina del cliente antes de cualquier ataque, el cliente estará seguro. Si un atacante ya está en su lugar, puede quitar el encabezado de HSTS y continuar su ataque al cliente.
Esto se puede evitar si carga previamente el encabezado HSTS. La HSTS previa a la codificación significa que usted registra su dominio con los proveedores de navegadores y ellos codificarán sus navegadores para nunca permitir una conexión no segura a su servidor. Esto hace que un ataque SSL sea muy difícil porque el cliente nunca enviará una solicitud HTTP a su servidor. Pero tenga cuidado, HSTS Preload viene con su propio conjunto de riesgos. Esto otra pregunta tiene algunas referencias geniales a HSTS y HSTS Preloading, lea las preguntas y las 3 respuestas principales para todos los detalles.
Como Tom mencionó en su respuesta, puede configurar HSTS con un encabezado de respuesta HTTP personalizado. También puedes hacerlo en tu archivo Web.Config:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
Nota: Esto no incluye el atributo de precarga. También excluye el atributo includeSubDomains que también puede desear. De nuevo, ten mucho cuidado con estos dos atributos. No los apliques ingenuamente.