¿Por qué rfc6797 dice "Un host HSTS NO DEBE incluir el campo de encabezado STS en las respuestas HTTP sobre el transporte no seguro".

Question

¿Por qué rfc6797 dice "Un host HSTS NO DEBE incluir el campo de encabezado STS en las respuestas HTTP sobre el transporte no seguro".

#1 de apsillers (26 votos)
#2 de WhiteWinterWolf (6 votos)

18

¿Por qué el RFC prohíbe que el servidor envíe HSTS al cliente a través de HTTP?

Puedo ver que si un cliente HTTP responde a esa respuesta HTTP no segura, podría hacer que el sitio sea inaccesible para el cliente, pero no veo ninguna razón para que el servidor tenga una DEBE en el protocolo.

Más bien, el cliente NO DEBE responder a HSTS en respuestas HTTP no seguras, es el enfoque correcto en mi mente. ¿Qué me estoy perdiendo?

7.2. Tipo de solicitud HTTP

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, como el código de estado 301   ( Sección 10.3.2 de [RFC2616] ), y un valor de campo de encabezado de ubicación   que contiene el URI de solicitud efectivo original de la solicitud HTTP   (consulte Sección 9 ("Creación de un URI de solicitud efectiva")) modificado como   es necesario tener un esquema de URI de "https", o un URI generado   de acuerdo con la política local con un esquema URI de "https".

NOTA: El comportamiento anterior es un "DEBE" en lugar de un "DEBE" debido   a:


Riesgos en redirecciones no seguras a seguras del lado del servidor        [ OWASP-TLSGuide ].



Características de implementación del sitio. Por ejemplo, un sitio que        Incorpora componentes de terceros que pueden no comportarse correctamente.        al hacer redirecciones no seguras a seguras del lado del servidor en el        caso de ser accedido a través de transporte no seguro, pero hace        comportarse correctamente cuando se accede de manera uniforme a través de transporte seguro.        Este último es el caso dado un UA capaz de HSTS que tiene        ya mencioné el sitio como un Host HSTS conocido (por cualquier medio,        por ejemplo, interacción previa o configuración de UA).



Un host HSTS NO DEBE incluir el campo de encabezado STS en HTTP   Respuestas transmitidas a través de transporte no seguro.

web-browser tls certificates hsts threat-mitigation

pregunta random65537 27.03.2015 - 13:41

fuente

2 respuestas

6

Esto puede ser para evitar el uso de este encabezado para provocar un ataque de denegación de servicio.

Imagina un sitio web HTTP inseguro. Ahora imagine a alguien capaz de manipular los encabezados HTTP enviados por este sitio para agregar un encabezado HSTS. Según el RFC:

La UA debe dejar de intentar acceder al sitio a través de HTTP e intentar usar solo HTTPS en su lugar.
Si el UA no puede establecer una conexión HTTPS, debe considerar que se trata de un error del lado del servidor y no debe dar ningún recurso al usuario final.

En otras palabras, el usuario final ya no podrá acceder a este sitio solo para HTTP, por lo tanto, el DoS.

respondido por el WhiteWinterWolf 27.03.2015 - 14:30

fuente

Lea otras preguntas en las etiquetas web-browser tls certificates hsts threat-mitigation

Formas de protegerse de los niños de Firesheep y otros sniffs ¿Se puede confiar en una CA intermedia como una CA raíz autofirmada?

score 26 · Accepted Answer

Este comportamiento del cliente está prohibido por sección 8.1 de la RFC :

Si se recibe una respuesta HTTP a través de un transporte inseguro, el UA DEBE ignorar los campos de encabezado STS actuales.

La especificación prohíbe a los usuarios enviar directivas HSTS inseguras y a los clientes a procesar directivas HSTS inseguras. Esto garantiza que una implementación defectuosa en un servidor o cliente no sea suficiente para socavar el HSTS; el fallo debe estar presente en ambos para que la debilidad esté presente.

Como se señaló en su pregunta, HSTS a través de HTTP simple suena como una excelente manera para que un atacante implemente la denegación de servicio aplicada por el cliente a largo plazo en un servicio ofrecido a través de HTTP. De hecho, sección 14.3 de RFC 6797 aborda esto específicamente (así como una preocupación aún más seria):

La razón detrás de este [ requisito de que HSTS se cumpla solo a través de conexiones seguras ] es que si hay un "hombre en el medio" (MITM), ya sea un proxy implementado legítimamente o un ilegítimo entidad: podría causar varias travesuras (ver también el Apéndice A ("Notas de decisión de diseño"), punto 3, así como la Sección 14.6 ("Vulnerabilidad MITM de Bootstrap")); por ejemplo:


Notación no autorizada del host como Host HSTS conocido, lo que podría generar una situación de denegación de servicio si el host no ofrece sus servicios de manera uniforme a través de transporte seguro (consulte también < a href="https://tools.ietf.org/html/rfc6797#section-14.5"> Sección 14.5 ("Denegación de servicio") ).



Restablecimiento del tiempo de vida para la designación del host como un Host HSTS conocido mediante la manipulación del valor del parámetro del campo del encabezado de edad máxima que se devuelve a la UA. Si max-age se devuelve como cero, esto hará que el host deje de ser considerado como un Host HSTS conocido por el UA, lo que lleva a conexiones inseguras al host o posiblemente a una denegación de servicio si el host entrega sus servicios solo a través de transporte seguro.

Dado que HTTP puede ser fácilmente falsificado, un atacante podría especificar una directiva HSTS para tratar un sitio solo HTTP como un sitio HTTPS: el cliente exigirá HTTPS y el servidor no podrá suministrarlo.

Más en serio, esta sección de la RFC indica que un atacante que puede emitir directivas HSTS para un host puede eliminar el estado del host como un Host HSTS conocido, lo que permite peligrosamente que el cliente emita solicitudes HTTP simples al host.