Hispanopedia Wiki
Articulo de referencia

Seguridad de transporte estricta HTTP

HTTP Strict Transport Security ( HSTS ) es un mecanismo de política que ayuda a proteger los sitios web contra ataques de intermediario, como ataques de degradación de protocolo...

Hispanopedia WikiContenido en espanolLectura gratuita

HTTP Strict Transport Security ( HSTS ) es un mecanismo de política que ayuda a proteger los sitios web contra ataques de intermediario, como ataques de degradación de protocolo [ 1 ] y secuestro de cookies . Permite a los servidores web declarar que los navegadores web (u otros agentes de usuario compatibles ) deben interactuar automáticamente con ellos utilizando solo conexiones HTTPS , que proporcionan seguridad de la capa de transporte (TLS/SSL), a diferencia del HTTP inseguro utilizado solo. HSTS es un protocolo estándar de la IETF y está especificado en la RFC 6797 . 

La política HSTS es comunicada por el servidor al agente de usuario a través de un campo de encabezado de respuesta HTTP llamado Strict-Transport-Security. La política HSTS especifica un período de tiempo durante el cual el agente de usuario solo debe acceder al servidor de forma segura. [ 2 ] : §5.2 Los sitios web que utilizan HSTS a menudo no aceptan HTTP en texto plano, ya sea rechazando las conexiones a través de HTTP o redirigiendo sistemáticamente a los usuarios a HTTPS (aunque esto no es requerido por la especificación). La consecuencia de esto es que un agente de usuario que no sea capaz de hacer TLS no podrá conectarse al sitio.

La protección normalmente solo se aplica después de que un usuario haya visitado el sitio al menos una vez, basándose en el principio de " confianza en el primer uso ". El funcionamiento de esta protección es el siguiente: cuando un usuario introduce o selecciona una URL HTTP (no HTTPS) para acceder al sitio, el cliente, como un navegador web, actualiza automáticamente a HTTPS sin realizar una solicitud HTTP, evitando así cualquier ataque de intermediario HTTP. Para contrarrestar este problema, Google Chrome mantiene una lista de precarga HSTS , utilizada también por otros navegadores web importantes . Si un dominio se encuentra en esta lista, el navegador omite la solicitud inicial y cifra toda la comunicación de inmediato. [ 3 ] Se pueden registrar dominios adicionales sin coste alguno. [ 4 ]

Historial de especificaciones

La especificación HSTS se publicó como RFC 6797 el 19 de noviembre de 2012 después de ser aprobada el 2 de octubre de 2012 por el IESG para su publicación como RFC de estándar propuesto . [ 5 ] Los autores la presentaron originalmente como un borrador de Internet el 17 de junio de 2010. Con la conversión a un borrador de Internet, el nombre de la especificación se modificó de "Strict Transport Security" (STS) a "HTTP Strict Transport Security", porque la especificación se aplica solo a HTTP . [ 6 ] Sin embargo, el campo de encabezado de respuesta HTTP definido en la especificación HSTS sigue llamándose "Strict-Transport-Security".

La última versión denominada "comunitaria" de la especificación entonces llamada "STS" se publicó el 18 de diciembre de 2009, con revisiones basadas en los comentarios de la comunidad. [ 7 ]

El borrador original de la especificación, elaborado por Jeff Hodges de PayPal , Collin Jackson y Adam Barth, se publicó el 18 de septiembre de 2009. [ 8 ]

La especificación HSTS se basa en el trabajo original de Jackson y Barth, tal como se describe en su artículo "ForceHTTPS: Protección de sitios web de alta seguridad contra ataques de red". [ 9 ]

Además, HSTS es la realización de una faceta de una visión general para mejorar la seguridad web, presentada por Jeff Hodges y Andy Steingruebl en su artículo de 2010 titulado The Need for Coherent Web Security Policy Framework(s) . [ 10 ]

Descripción general del mecanismo HSTS

Un servidor implementa una política HSTS proporcionando un encabezado sobre una conexión HTTPS (los encabezados HSTS sobre HTTP se ignoran). [ 1 ] Por ejemplo, un servidor podría enviar un encabezado de tal manera que las solicitudes futuras al dominio durante el próximo año (max-age se especifica en segundos; 31.536.000 es igual a un año no bisiesto) utilicen solo HTTPS: Strict-Transport-Security: max-age=31536000.

Cuando una aplicación web emite una política HSTS a los agentes de usuario, los agentes de usuario conformes se comportan de la siguiente manera: [ 2 ] : §5

  1. Convertir automáticamente cualquier enlace no seguro que haga referencia a la aplicación web en enlaces seguros (por ejemplo, http://example.com/some/page/se modificará https://example.com/some/page/antes de acceder al servidor).
  2. Si no se puede garantizar la seguridad de la conexión (por ejemplo , si no se confía en el certificado TLS del servidor ), el agente de usuario debe finalizar la conexión [ 2 ] : §8.4 y no debe permitir que el usuario acceda a la aplicación web. [ 2 ] : §12.1

Esto ayuda a proteger a los usuarios de aplicaciones web contra algunos ataques de red pasivos ( escucha ilegal ) y activos . [ 2 ] : §2.4 Un atacante de intermediario tiene una capacidad muy reducida para interceptar solicitudes y respuestas entre un usuario y un servidor de aplicaciones web mientras el navegador del usuario tiene la Política HSTS en efecto para esa aplicación web.

Aplicabilidad

La vulnerabilidad de seguridad más importante que HSTS puede solucionar son los ataques de intermediario (man-in-the-middle) de eliminación de SSL , presentados públicamente por primera vez por Moxie Marlinspike en su charla de 2009 en BlackHat Federal titulada "Nuevos trucos para derrotar a SSL en la práctica". [ 11 ] [ 12 ] El ataque de eliminación de SSL (y TLS ) funciona convirtiendo de forma transparente una conexión HTTPS segura en una conexión HTTP simple. El usuario puede ver que la conexión no es segura, pero, fundamentalmente, no hay forma de saber si debería ser segura. En el momento de la charla de Marlinspike, muchos sitios web no utilizaban TLS/SSL, por lo que no había forma de saber (sin conocimiento previo) si el uso de HTTP simple se debía a un ataque o simplemente a que el sitio web no había implementado TLS/SSL. Además, no se presentan advertencias al usuario durante el proceso de degradación, lo que hace que el ataque sea bastante sutil para todos excepto para los más vigilantes. La herramienta sslstrip de Marlinspike, presentada en Black Hat DC 2009, automatiza completamente el ataque. [ 13 ]

HSTS aborda este problema [ 2 ] : §2.4 al informar al navegador que las conexiones al sitio siempre deben usar TLS/SSL. El atacante puede eliminar el encabezado HSTS si es la primera visita del usuario. Google Chrome , Mozilla Firefox , Internet Explorer y Microsoft Edge intentan limitar este problema incluyendo una lista "precargada" de sitios HSTS. [ 14 ] [ 15 ] [ 16 ] Desafortunadamente, esta solución no puede abarcar todos los sitios web en internet. Véanse las limitaciones a continuación.

HSTS también puede ayudar a evitar que las credenciales de inicio de sesión en sitios web basadas en cookies sean robadas por herramientas ampliamente disponibles como Firesheep . [ 17 ]

Debido a que HSTS tiene un límite de tiempo, es vulnerable a ataques que implican el cambio de la hora del ordenador de la víctima, por ejemplo, mediante el uso de paquetes NTP falsos . [ 18 ]

Limitaciones

La solicitud inicial permanece desprotegida frente a ataques activos si utiliza un protocolo inseguro como HTTP simple o si la URI para la solicitud inicial se obtuvo a través de un canal inseguro . [ 2 ] : §14.6 Lo mismo se aplica a la primera solicitud después del período de actividad especificado en la Política HSTS anunciada max-age(los sitios deben establecer un período de varios días o meses dependiendo de la actividad y el comportamiento del usuario).

Soluciones con lista de precarga

Google Chrome , Mozilla Firefox e Internet Explorer / Microsoft Edge abordan esta limitación implementando una "lista precargada de HSTS", que contiene sitios conocidos que admiten HSTS. [ 19 ] [ 14 ] [ 15 ] [ 16 ] Esta lista se distribuye con el navegador para que también utilice HTTPS para la solicitud inicial a los sitios listados. Como se mencionó anteriormente, estas listas precargadas no pueden escalar para cubrir toda la Web. Una posible solución podría lograrse utilizando registros DNS para declarar la Política HSTS y accediendo a ellos de forma segura a través de DNSSEC , opcionalmente con huellas digitales de certificados para garantizar la validez (lo que requiere ejecutar un resolvedor de validación para evitar problemas de última milla ). [ 20 ]

Junade Ali ha señalado que HSTS es ineficaz contra el uso de dominios falsos; mediante ataques basados ​​en DNS, es posible que un interceptor de intermediario sirva tráfico desde un dominio artificial que no está en la lista de precarga de HSTS, [ 21 ] esto puede hacerse posible mediante ataques de suplantación de DNS, [ 22 ] o simplemente un nombre de dominio que se asemeja engañosamente al nombre de dominio real, como www.example.org en lugar de www.example.com .

Incluso con una lista HSTS precargada, HSTS no puede prevenir ataques avanzados contra TLS, como los ataques BEAST o CRIME introducidos por Juliano Rizzo y Thai Duong. Los ataques contra TLS son independientes de la aplicación de la política HSTS. Tampoco puede proteger contra ataques al servidor: si alguien lo compromete, servirá sin problemas cualquier contenido a través de TLS.

Cuestiones de privacidad

HSTS se puede utilizar para etiquetar los navegadores visitantes con datos de identificación recuperables que pueden persistir incluso después de borrar las cookies. La dificultad de eliminar la política HSTS de los dominios visitados es una decisión deliberada definida en RFC 6797 [ 2 ] : §12.5 . Debido a que los navegadores web deben almacenar en caché de forma persistente la política HSTS de los dominios visitados previamente, una página web que realiza múltiples solicitudes HTTP a dominios seleccionados cuyos estados HSTS se coordinan en el momento de la visita a la página puede identificar a los visitantes observando qué solicitudes se actualizan a HTTPS en visitas repetidas. Si el propietario de la página web controla veinte dominios diferentes, por ejemplo, y se genera una configuración única de estados HSTS para esos dominios para cada nuevo visitante, teóricamente se puede distinguir a más de un millón de visitantes (2 20 ). [ 23 ]

Compatibilidad con navegadores

Página de configuración de seguridad en Chromium 45, que muestra el estado de la política de seguridad para el dominio "en.wikipedia.org".
Página de configuración de HTTPS Strict Transport Security en Chromium 45, que muestra el estado de la política de seguridad para el dominio "en.wikipedia.org".

Mejores prácticas de implementación

Dependiendo del despliegue específico, existen ciertas amenazas (por ejemplo, ataques de inyección de cookies) que pueden evitarse siguiendo las mejores prácticas.

  • Los hosts HSTS deben declarar la política HSTS en su nombre de dominio de nivel superior. Por ejemplo, un host HSTS en https://sub.example.com también debe responder con el encabezado HSTS en https://example.com . El encabezado debe especificar la includeSubDomainsdirectiva. [ 2 ] : §6.1.2
  • Además del despliegue de HSTS, un host para https://www.example.com debe incluir una solicitud a un recurso desde https://example.com para asegurarse de que HSTS para el dominio principal esté configurado y proteja al usuario de posibles ataques de inyección de cookies realizados por un MITM que inyectaría una referencia al dominio principal (o incluso http://nonexistentpeer.example.com ), a la que el atacante luego respondería. [ 2 ] : §11.4

Véase también

Referencias

  1. 1 2 3 "Strict-Transport-Security" . MDN Web Docs . Mozilla . Archivado del original el 20 de marzo de 2020. Recuperado el 31 de enero de 2018 .
  2. 1 2 3 4 5 6 7 8 9 10 J. Hodges; C. Jackson; A. Barth (noviembre de 2012). Seguridad de transporte estricta HTTP (HSTS) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6797 . ISSN 2070-1721 . RFC 6797 . Norma propuesta.
  3. ↑ Keeler, Dana (1 de noviembre de 2012). "Precarga de HSTS" . Blog de seguridad de Mozilla . Consultado el 16 de enero de 2026 .
  4. ↑ "Envío a la lista de precarga HSTS" . hstspreload.org . Consultado el 16 de enero de 2026 .
  5. ↑ " [ websec ] Acción de protocolo: 'HTTP Strict Transport Security (HSTS)' al estándar propuesto (draft-ietf-websec-strict-transport-sec-14.txt)" . 2 de octubre de 2012. Archivado del original el 29 de enero de 2017. Recuperado el 2 de octubre de 2012 .
  6. ↑ Hodges, Jeff (30 de junio de 2010). "Re: [ HASMAT ] Apodo "STS" (antes: IETF BoF @IETF-78 Maastricht: HASMAT...)" . Archivado del original el 2 de febrero de 2017. Recuperado el 22 de julio de 2010 .
  7. ↑ "Seguridad de transporte estricta -06" . 18 de diciembre de 2009. Archivado del original el 21 de febrero de 2017. Consultado el 23 de diciembre de 2009 .
  8. ↑ "Seguridad de transporte estricta -05" . 18 de septiembre de 2009. Archivado del original el 24 de febrero de 2020. Consultado el 19 de noviembre de 2009 .
  9. ↑ "ForceHTTPS: Protección de sitios web de alta seguridad contra ataques de red" . Abril de 2008. Archivado del original el 28 de febrero de 2020. Consultado el 19 de noviembre de 2009 .
  10. ↑ Hodges, Jeff; Steinguebl, Andy (29 de octubre de 2010). "La necesidad de un marco coherente de políticas de seguridad web" . Archivado del original el 14 de agosto de 2017. Recuperado el 21 de noviembre de 2012 .
  11. ↑ Marlinspike, Moxie (2009). Nuevos trucos para derrotar SSL en la práctica (PDF) . Black Hat Briefings . Washington, DC. Archivado (PDF) del original el 30 de diciembre de 2014. Recuperado el 15 de marzo de 2012 .
  12. ↑ Cómo burlar SSL usando Sslstrip en YouTube
  13. ↑ Marlinspike, Moxie (febrero de 2009). Nuevos trucos para derrotar a SSL en la práctica (PDF) . Black Hat DC 2009.
  14. 1 2 Langley, Adam (8 de julio de 2010). "Seguridad estricta en el transporte" . The Chromium Projects . Archivado del original el 1 de septiembre de 2019. Recuperado el 22 de julio de 2010 .
  15. 1 2 3 Keeler, David (1 de noviembre de 2012). "Precarga de HSTS" . Blog de seguridad de Mozilla . Archivado del original el 24 de febrero de 2020. Recuperado el 6 de febrero de 2014 .
  16. 1 2 Bell, Mike; Walp, David (16 de febrero de 2015). "HTTP Strict Transport Security llega a Internet Explorer" . Archivado del original el 15 de noviembre de 2015. Recuperado el 16 de febrero de 2015 .
  17. ↑ Hodges, Jeff (31 de octubre de 2010). "Firesheep y HSTS (HTTP Strict Transport Security)" . Archivado del original el 23 de junio de 2016. Recuperado el 8 de marzo de 2011 .
  18. ↑ Selvi, Jose (17 de octubre de 2014). Eludiendo la seguridad de transporte estricta HTTP (PDF) . Black Hat Briefings . Ámsterdam. Archivado (PDF) del original el 22 de octubre de 2014. Recuperado el 22 de octubre de 2014 .
  19. ↑ "Lista precargada de HSTS de Chromium" . cs.chromium.org . Archivado del original el 18 de febrero de 2020. Consultado el 10 de julio de 2019 .
  20. ↑ Butcher, Simon (11 de septiembre de 2011). "HTTP Strict Transport Security" . Archivado del original el 26 de abril de 2019. Recuperado el 27 de marzo de 2012 .
  21. ↑ Ali, Junade (20 de octubre de 2017). "Realización y prevención de la eliminación de SSL: una introducción en lenguaje sencillo" . Blog de Cloudflare . Archivado del original el 14 de diciembre de 2019. Recuperado el 7 de diciembre de 2017 .
  22. ↑ Maksutov, AA; Cherepanov, IA; Alekseev, MS (2017). Detección y prevención de ataques de suplantación de DNS . Simposio Siberiano de Ciencia e Ingeniería de Datos (SSDSE) de 2017. págs. 84–87 . doi : 10.1109/SSDSE.2017.8071970 . ISBN  978-1-5386-1593-5. S2CID 44866769 . 
  23. ↑ "La supercookie HSTS te obliga a elegir: ¿privacidad o seguridad?" -" . sophos.com . 2 de febrero de 2015. Archivado del original el 11 de febrero de 2020. Consultado el 1 de diciembre de 2015 .
  24. ↑ Los desarrolladores de Chromium (17 de noviembre de 2010). "Seguridad de transporte estricta: los proyectos Chromium" . Archivado del original el 20 de marzo de 2020. Recuperado el 17 de noviembre de 2010 .
  25. ↑ Hodges, Jeff (18 de septiembre de 2009). "fyi: Especificación de seguridad de transporte estricta" . Archivado del original el 29 de febrero de 2020. Recuperado el 19 de noviembre de 2009 .
  26. ↑ Opera Software ASA (23 de abril de 2012). "Soporte para especificaciones web en Opera Presto 2.10" . Archivado del original el 20 de junio de 2018. Recuperado el 8 de mayo de 2012 .
  27. ↑ Langley, Adam [@agl__] (20 de diciembre de 2013). "Confirmado. Ver ~/Library/Cookies/HSTS.plist. Incluye precargas de Chromium a partir de cierta fecha y procesa encabezados HSTS" ( Tweet ). Archivado del original el 9 de mayo de 2019. Recuperado el 20 de diciembre de 2013 – vía Twitter .
  28. ↑ "HTTP Strict Transport Security llega a Internet Explorer 11 en Windows 8.1 y Windows 7" . windows.com . Archivado del original el 27 de noviembre de 2019. Consultado el 12 de junio de 2015 .
  29. ↑ "Estado y hoja de ruta de la plataforma web de Internet Explorer" . Archivado del original el 29 de junio de 2015. Consultado el 14 de abril de 2014 .
  30. ↑ "Proyecto Spartan y la compilación de vista previa de enero de Windows 10 - IEBlog" . 22 de enero de 2015. Archivado del original el 29 de noviembre de 2019. Consultado el 23 de enero de 2015 .
  • Grupo de trabajo sobre seguridad web de la IETF
  • Seguridad ahora 262: Estricta seguridad en el transporte
  • Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP): Descripción de HSTS
  • Prueba de HSTS y fijación de clave pública en navegadores en línea
  • Envío de precarga HSTS para Google Chrome, Mozilla Firefox, Safari, IE 11 y Edge.
  • Lista precargada de Chromium HSTS
  • Seguridad de transporte estricta en la documentación web de MDN