HTTP Strict Transport Security ( HSTS ) es un mecanismo de política que ayuda a proteger los sitios web contra ataques man-in-the-middle , como ataques de degradación de protocolos [1] y secuestro de cookies . Permite que los servidores web declaren que los navegadores web (u otros agentes de usuario que cumplan con los requisitos ) deben interactuar automáticamente con él utilizando solo conexiones HTTPS , que proporcionan seguridad de la capa de transporte (TLS / SSL), a diferencia del HTTP inseguro que se usa solo. HSTS es un protocolo de seguimiento de estándares IETF y se especifica en RFC 6797.
El servidor comunica la política HSTS al agente de usuario a través de un campo de encabezado de respuesta HTTPS llamado " Strict-Transport-Security ". [1] 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] Los sitios web que utilizan HSTS a menudo no aceptan HTTP de texto sin cifrar, ya sea rechazando conexiones a través de HTTP o redirigiendo sistemáticamente a los usuarios a HTTPS (aunque la especificación no lo exige). La consecuencia de esto es que un usuario-agente que no sea capaz de hacer TLS no podrá conectarse al sitio.
La protección solo se aplica después de que un usuario ha visitado el sitio al menos una vez, basándose en el principio de confianza en el primer uso. La forma en que funciona esta protección es que un usuario que ingrese o seleccione una URL al sitio que especifica HTTP, se actualizará automáticamente a HTTPS, sin realizar una solicitud HTTP, lo que evita que se produzca el ataque de intermediario HTTP.
Historial de especificaciones
La especificación HSTS se publicó como RFC 6797 el 19 de noviembre de 2012 después de haber sido aprobada el 2 de octubre de 2012 por IESG para su publicación como RFC estándar propuesto . [3] Los autores lo enviaron 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 "Seguridad de transporte estricta" (STS) a "Seguridad de transporte estricta de HTTP", porque la especificación se aplica solo a HTTP . [4] Sin embargo, el campo de encabezado de respuesta HTTP definido en la especificación HSTS permanece llamado "Strict-Transport-Security".
La última denominada "versión comunitaria" de la especificación entonces denominada "STS" se publicó el 18 de diciembre de 2009, con revisiones basadas en los comentarios de la comunidad. [5]
El borrador original de la especificación de Jeff Hodges de PayPal , Collin Jackson y Adam Barth se publicó el 18 de septiembre de 2009. [6]
La especificación HSTS se basa en el trabajo original de Jackson y Barth como se describe en su documento "ForceHTTPS: Protección de sitios web de alta seguridad contra ataques de red". [7]
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 documento de 2010 The Need for Coherent Web Security Policy Framework (s) . [8]
Descripción general del mecanismo HSTS
Un servidor implementa una política HSTS proporcionando un encabezado a través de una conexión HTTPS (los encabezados HSTS a través de HTTP se ignoran). [1] Por ejemplo, un servidor puede enviar una cabecera de tal manera que las futuras solicitudes al dominio para el próximo año (max-edad se especifica en segundos; 31536000 es igual a uno no bisiesto año) uso solamente 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 que cumplen los requisitos se comportan de la siguiente manera (RFC 6797): [9]
- Convierta automáticamente cualquier enlace inseguro 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). - Si no se puede garantizar la seguridad de la conexión (por ejemplo, el certificado TLS del servidor no es confiable), el agente de usuario debe terminar la conexión (RFC 6797 sección 8.4, Errores en el establecimiento de transporte seguro) y no debe permitir que el usuario acceda a la aplicación web. (sección 12.1, Sin recurso de usuario).
La política HSTS ayuda a proteger a los usuarios de aplicaciones web contra algunos ataques de red pasivos ( escuchas clandestinas ) y activos . [10] Un atacante man-in-the-middle 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 una política HSTS en vigor para esa aplicación web.
Aplicabilidad
La vulnerabilidad de seguridad más importante que puede solucionar HSTS son los ataques man-in-the-middle de eliminación de SSL , presentados públicamente por primera vez por Moxie Marlinspike en su charla de BlackHat Federal de 2009 "Nuevos trucos para derrotar 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 es insegura, pero lo más importante es que no hay forma de saber si la conexión debe ser segura. En el momento de la charla de Marlinspike, muchos sitios web no usaban TLS / SSL, por lo tanto, no había forma de saber (sin conocimiento previo) si el uso de HTTP simple se debió a un ataque o simplemente porque 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 menos para los más vigilantes. La herramienta sslstrip de Marlinspike automatiza completamente el ataque. [ cita requerida ]
HSTS aborda este problema [10] informando al navegador que las conexiones al sitio siempre deben usar TLS / SSL. El atacante puede quitar el encabezado HSTS si esta es la primera visita del usuario. Google Chrome , Mozilla Firefox , Internet Explorer y Microsoft Edge intentan limitar este problema al incluir una lista "precargada" de sitios HSTS. [13] [14] [15] Desafortunadamente, esta solución no se puede escalar para incluir todos los sitios web en Internet. Consulte las limitaciones a continuación.
HSTS también puede ayudar a evitar que las credenciales de inicio de sesión del sitio web basadas en cookies sean robadas por herramientas ampliamente disponibles como Firesheep . [dieciséis]
Debido a que HSTS tiene un tiempo limitado, es sensible a los ataques que implican cambiar la hora de la computadora de la víctima, por ejemplo, usando paquetes NTP falsos . [17]
Limitaciones
La solicitud inicial permanece desprotegida de ataques activos si utiliza un protocolo inseguro como HTTP simple o si el URI de la solicitud inicial se obtuvo a través de un canal inseguro . [18] Lo mismo se aplica a la primera solicitud después del período de actividad especificado en la Política HSTS de edad máxima anunciada (los sitios deben establecer un período de varios días o meses según la actividad y el comportamiento del usuario). Google Chrome , Mozilla Firefox e Internet Explorer / Microsoft Edge abordan esta limitación implementando una "lista precargada de HSTS", que es una lista que contiene sitios conocidos que admiten HSTS. [19] [13] [14] [15] Esta lista se distribuye con el navegador para que también utilice HTTPS para la solicitud inicial a los sitios enumerados. Como se mencionó anteriormente, estas listas precargadas no se pueden escalar para cubrir toda la Web. Se podría lograr una solución potencial mediante el uso de registros DNS para declarar la política HSTS y acceder 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 solucionador 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 el uso de ataques basados en DNS, es posible que un interceptor de intermediario sirva el tráfico de un dominio artificial que no está en la lista de precarga de HSTS, [21] esto puede ser posible mediante ataques de suplantación de identidad de DNS, [ 22] o simplemente un nombre de dominio que se parece engañosamente al nombre de dominio real, como www.example.org en lugar de www.example.com .
Incluso con una "lista precargada de HSTS", HSTS no puede evitar ataques avanzados contra TLS en sí, como los ataques BEAST o CRIME introducidos por Juliano Rizzo y Thai Duong. Los ataques contra TLS en sí son ortogonales a la aplicación de la política HSTS. Tampoco puede proteger contra ataques al servidor; si alguien lo compromete, felizmente servirá cualquier contenido a través de TLS. [ cita requerida ]
Consulte RFC 6797 para obtener un análisis de las consideraciones generales de seguridad de HSTS.
Problemas de privacidad
HSTS se puede utilizar para etiquetar de forma casi indeleble los navegadores visitantes con datos de identificación recuperables ( supercookies ) que pueden persistir dentro y fuera de los modos de privacidad " incógnito " del navegador . Al crear una página web que realiza múltiples solicitudes HTTP a dominios seleccionados, por ejemplo, si se utilizan veinte solicitudes de navegador a veinte dominios diferentes, teóricamente se pueden distinguir más de un millón de visitantes (2 20 ) debido a las solicitudes resultantes que llegan a través de HTTP vs. HTTPS; siendo estos últimos los "bits" binarios previamente grabados establecidos anteriormente a través de encabezados HSTS. [23]
Soporte del navegador
- Chromium y Google Chrome desde la versión 4.0.211.0 [24] [25]
- Firefox desde la versión 4; [1] con Firefox 17, Mozilla integra una lista de sitios web que admiten HSTS. [14]
- Opera desde la versión 12 [26]
- Safari desde OS X Mavericks (versión 10.9, finales de 2013) [27]
- Internet Explorer 11 en Windows 8.1 y Windows 7 cuando se instala KB 3058515 (lanzado en Windows Update en junio de 2015) [28]
- Microsoft Edge e Internet Explorer 11 en Windows 10 [29] [30]
- BlackBerry 10 Browser y WebView desde BlackBerry OS 10.3.3.
Mejores prácticas de implementación
Dependiendo de la implementación real, 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
includeSubDomains
directiva. [31] - Además de la implementación de HSTS, un host para https://www.example.com debe incluir una solicitud a un recurso de 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), que luego el atacante respondería. [32]
Ver también
- Política de seguridad de contenido
- Fijación de claves públicas HTTP
- HTTPsec
Referencias
- ^ a b c d "Estricta seguridad en el transporte" . Documentos web de MDN . Mozilla . Consultado el 31 de enero de 2018 .
- ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (noviembre de 2012). "Política HSTS" . Seguridad de transporte estricta HTTP (HSTS) . IETF . doi : 10.17487 / RFC6797 . RFC 6797 . Consultado el 31 de enero de 2018 .
- ^ "Acción de protocolo [websec]: 'Seguridad de transporte estricta HTTP (HSTS)' al estándar propuesto (borrador-ietf-websec-estricto-transporte-sec-14.txt)" . 2 de octubre de 2012 . Consultado el 2 de octubre de 2012 .
- ^ Jeff Hodges (30 de junio de 2010). "Re: [HASMAT]" STS "apodo (era: IETF BoF @ IETF-78 Maastricht: HASMAT ...)" . Consultado el 22 de julio de 2010 .
- ^ "Estricta seguridad en el transporte -06" . 18 de diciembre de 2009 . Consultado el 23 de diciembre de 2009 .
- ^ "Estricta seguridad en el transporte -05" . 18 de septiembre de 2009 . Consultado el 19 de noviembre de 2009 .
- ^ "ForceHTTPS: protección del sitio web de alta seguridad contra ataques de red" . Abril de 2008 . Consultado el 19 de noviembre de 2009 .
- ^ Hodges, Jeff; Steinguebl, Andy (29 de octubre de 2010). "La necesidad de marcos de políticas de seguridad web coherentes" . Consultado el 21 de noviembre de 2012 .
- ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (noviembre de 2012). "Sección 5. Descripción general del mecanismo HSTS" . RFC 6797 . IETF . Consultado el 21 de noviembre de 2012 .
- ^ a b Hodges, Jeff; Jackson, Collin; Barth, Adam (noviembre de 2012). "2.3. Modelo de amenazas" . RFC 6797 . IETF . Consultado el 21 de noviembre de 2012 .
- ^ "Nuevos trucos para derrotar a SSL en la práctica" (PDF) . Cite journal requiere
|journal=
( ayuda ) - ^ Derrotando SSL usando Sslstrip en YouTube
- ^ a b Adam Langley (8 de julio de 2010). "Estricta seguridad en el transporte" . Los proyectos de Chromium . Consultado el 22 de julio de 2010 .
- ^ a b c David Keeler (1 de noviembre de 2012). "Precarga HSTS" . Blog de seguridad de Mozilla . Consultado el 6 de febrero de 2014 .
- ^ a b Bell, Mike; Walp, David (16 de febrero de 2015). "HTTP Strict Transport Security llega a Internet Explorer" . Consultado el 16 de febrero de 2015 .
- ^ Jeff Hodges (31 de octubre de 2010). "Firesheep y HSTS (HTTP Strict Transport Security)" . Consultado el 8 de marzo de 2011 .
- ^ Jose Selvi (17 de octubre de 2014). "Eludir la seguridad de transporte estricta de HTTP" (PDF) . Consultado el 22 de octubre de 2014 .
- ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (noviembre de 2012). "Sección 14.6. Vulnerabilidad de Bootstrap MITM" . RFC 6797 . IETF . Consultado el 21 de noviembre de 2012 .
- ^ "Lista precargada de Chromium HSTS" . cs.chromium.org . Consultado el 10 de julio de 2019 .
- ^ Butcher, Simon (11 de septiembre de 2011). "Seguridad de transporte estricta HTTP" . Consultado el 27 de marzo de 2012 .
- ^ Ali, Junade (20 de octubre de 2017). "Realización y prevención de la eliminación de SSL: un manual básico en inglés" . Blog de Cloudflare .
- ^ Maksutov, AA; Cherepanov, IA; Alekseev, MS (2017). 2017 Simposio de Siberia sobre Ciencia e Ingeniería de Datos (SSDSE) . págs. 84–87. doi : 10.1109 / SSDSE.2017.8071970 . ISBN 978-1-5386-1593-5. S2CID 44866769 .
- ^ "La súper cookie HSTS que te obliga a elegir:" ¿privacidad o seguridad? "-" . sophos.com . Consultado el 1 de diciembre de 2015 .
- ^ The Chromium Developers (17 de noviembre de 2010). "Estricta seguridad en el transporte: los proyectos de Chromium" . Consultado el 17 de noviembre de 2010 .
- ^ Jeff Hodges (18 de septiembre de 2009). "Fyi: estricta especificación de seguridad de transporte" . Consultado el 19 de noviembre de 2009 .
- ^ Opera Software ASA (23 de abril de 2012). "Soporte de especificaciones web en Opera Presto 2.10" . Consultado el 8 de mayo de 2012 .
- ^ @agl__ ( Adam Langley ). "Confirmado. Consulte ~ / Library / Cookies / HSTS.plist. Incluye precargas de Chromium a partir de cierta fecha y procesa encabezados HSTS" . en Twitter . Consultado el 20 de diciembre de 2013 .
- ^ "HTTP Strict Transport Security llega a Internet Explorer 11 en Windows 8.1 y Windows 7" . windows.com . Consultado el 12 de junio de 2015 .
- ^ "Estado y hoja de ruta de la plataforma web Internet Explorer" . Consultado el 14 de abril de 2014 .
- ^ "Proyecto Spartan y la compilación de vista previa de enero de Windows 10 - IEBlog" . Consultado el 23 de enero de 2015 .
- ^ Hodges; et al. "Seguridad de transporte estricta HTTP (HSTS) 6.1.2" . ietf.org . Consultado el 11 de noviembre de 2016 .
- ^ "RFC 6797 - Seguridad de transporte estricta HTTP (HSTS)" . Herramientas IETF . Archivado desde el original el 28 de mayo de 2019 . Consultado el 28 de mayo de 2019 .
enlaces externos
- El estado de la implementación de HSTS: una encuesta y errores comunes proporciona un análisis de las estadísticas, los patrones, los errores y las mejores prácticas de implementación de HSTS.
- RFC 6797 - Seguridad de transporte estricta HTTP (HSTS)
- Grupo de trabajo IETF WebSec
- Security Now 262: estricta seguridad en el transporte
- Proyecto de seguridad de aplicaciones web abiertas (OWASP): descripción de HSTS
- Prueba de HSTS de navegador en línea y fijación de clave pública
- Prueba HSTS en línea para servidores web
- 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 MDN Web Docs