HSTS en sitios disponibles a través de HTTP y HTTPS

Los navegadores HSTS enviados a través de HTTP son ignorados por los navegadores que cumplen con las especificaciones: esto es para evitar que una persona en el medio haga que los visitantes no puedan acceder a un sitio web que no sea HTTPS al establecer una regla HSTS en el navegador. (consulte RFC 6797 )

Por lo tanto, si bien es técnicamente incorrecto, puede proporcionar encabezados HSTS a todos sus usuarios, y proporcionar las mismas páginas a través de HTTP y HTTPS, y no redirigir deliberadamente de páginas inseguras a seguras.

Esto tendrá el efecto de que los visitantes que visiten su versión HTTPS se verán obligados a regresar a ella en futuras visitas (al menos durante la duración del encabezado), y los visitantes que visiten deliberadamente su versión HTTP permanecerán en eso. Si siguen un enlace a la versión de HTTPS en cualquier momento, se verán obligados a HTTPS en el futuro.

En cuanto a si tiene sentido, depende de sus objetivos y de sus visitantes. ¿Tiene muchos visitantes de proxies rotos? ¿Proporciona información que podría ser incriminatoria en algunas páginas?

Personalmente, solo serviría la versión segura y tendría un redireccionamiento forzado de la insegura, especialmente porque los motores de búsqueda parecen estar moviéndose hacia la preferencia de sitios seguros.

El encabezado HSTS no tiene efecto mientras se accede al sitio a través de HTTP.

El objetivo de HSTS es forzar al navegador a cargar el sitio a través de HTTPS, ya que la opción de verlo a través de HTTP es contraintuitivo.

  

Me pregunto si tiene sentido habilitar HSTS en un sitio que se sirve a través de HTTPS, así como a través de HTTP.

No estoy completamente seguro de HSTS pero creo que sí.

(La idea en sí misma es sólida. Es similar a lo que " Encriptación oportunista " tiene en mente: hacer que el atacante trabaje más al usar al menos cierta cantidad de criptografía para al menos algunas conexiones.)

El resumen del RFC dice esto:

  

Esta especificación define un mecanismo que permite a los sitios web declarar      solo accesibles a través de conexiones seguras y / o para que los usuarios      Ser capaz de dirigir a sus agentes de usuario para que interactúen con los sitios dados      solo sobre conexiones seguras.

Y el bit "y / o" de la oración parece importante aquí.

Entonces, lo que puede hacer a través de HSTS es declarar algo como: Este sitio es HTTPS en todo momento. Este sitio funcionará para usted incluso si su servidor de seguridad bloquea todas las conexiones al puerto 80. Y, como idea de último momento: En caso de que quede un enlace HTTP simple en cualquier lugar por aquí, entonces es un error, por favor actualícelo. a HTTPS.

Y este bit silent-upgrade-xor-failure lo salvaría de un escenario que ofrecen aquí: (sección 2.3.1.3)

  

Incluso si los desarrolladores del sitio examinan cuidadosamente su página de inicio de sesión      para "contenido mixto", una sola inserción insegura en cualquier parte del      El sitio general compromete la seguridad de su página de inicio de sesión porque una      el atacante puede escribir (es decir, controlar) la página de inicio de sesión mediante la inyección de código      (por ejemplo, un script) en otra página del sitio, cargada de manera insegura.

Y mientras se espera que el servidor redirija al cliente a HTTPS ( sección 7.2 ):

  

Si un Host HSTS recibe un mensaje de solicitud HTTP a través de un no seguro      transporte, DEBERÍA enviar un mensaje de respuesta HTTP que contenga un      código de estado que indica una redirección permanente,

... esto es un deber y no un deber.

Entonces, en resumen: sí, lo que está preguntando debe ser un uso posible y legítimo de HSTS.

Otra cosa: si desea apoyar a los usuarios de computadoras portátiles que pueden usar tanto la versión HTTPS de su sitio (por ejemplo, desde su casa) como la versión HTTP simple de su sitio (por ejemplo, desde su oficina WIFI), entonces deberá configurar el tiempo de espera HSTS lo suficientemente bajo. (Algunos minutos tal vez.)