Del borrador de IETF [ enlace ]:
10.1 consideraciones sobre el tiempo de caducidad de la política HSTS
Las implementaciones de servidores y la implementación de sitios web deben considerar si están configurando un tiempo de caducidad que es un valor constante en el futuro, por ejemplo, enviando constantemente el mismo valor de edad máxima a los UA.
Por ejemplo, un valor de edad máxima de 778000 es de 90 días:
Strict-Transport-Security: max-age=778000
Tenga en cuenta que cada recibo de este encabezado por un UA requerirá que el UA actualice su noción de cuándo debe eliminar su conocimiento de este Host HSTS conocido. Los detalles de cómo se logra esto están fuera del alcance de esta especificación.
O si están configurando un tiempo de caducidad que es un punto fijo en el tiempo, por ejemplo, enviando valores de edad máxima que representan el tiempo restante hasta la hora de caducidad.
Una consideración aquí es si un implementador desea que la hora de caducidad de la Política HSTS señalada coincida con la del certificado de dominio del sitio web.
Además, los implementadores de servidores deben considerar el uso de un valor predeterminado de edad máxima de cero en sus sistemas de configuración de implementación. Esto requerirá que los implementadores establezcan intencionalmente la edad máxima para que los UA apliquen la Política de HSTS para su host, y los protege de la activación involuntaria de HSTS con una duración arbitraria distinta de cero.
Por lo tanto, dado que el navegador actualizará su HSTS max-age almacenado en cada encabezado de max-age recibido [a través de https], el tiempo más largo no causará ninguna de estas malas historias de horror de las que hablan los chismes. . El único problema es si el certificado cambia. Sin embargo, los propietarios del sitio deben ser conscientes de esto y deben tener la edad máxima establecida (5 a 8 minutos) justo antes (un día completo) el cambio de certificado se realiza debido al vencimiento. Sin embargo, esto es solo para hacer frente a la caducidad de un certificado entrante (que se evita principalmente al reemplazar el certificado por uno nuevo antes del último minuto), como puede verse por:
14.6 Phish Root CA Certificate Phish más DNS Cache Poisoning Attack
Si un atacante puede convencer a los usuarios de, digamos, enlace (que está protegido por la Política de HSTS), para instalar su propia versión de un Certificado de CA raíz que pretende ser CA de bank.example.com, por ejemplo, a través de un mensaje de correo electrónico de phishing con un enlace a dicho certificado. Luego, si pueden realizar un ataque al DNS de los usuarios (por ejemplo, a través del envenenamiento de caché) y activar la Política HSTS para su sitio falso bank.example.com, entonces ellos mismos tienen algunos usuarios nuevos.
Lo que muestra que un cambio de certificado en medio de la "sesión" de HSTS de un navegador no causaría problemas a menos que hubiera problemas con el certificado (advertencias de validación o errores). Esto haría que todo el punto de su pregunta fuera discutible, ya que se supone que los navegadores almacenan parte de la información relacionada con el certificado enviado con la respuesta del encabezado HSTS para validar contra el host HSTS. Como el borrador no hace mención de tal concepto, diría que es una suposición no válida.
Sin embargo, el almacenamiento de la información del certificado que se usará contra los hosts de HSTS se puede hacer con la fijación de claves públicas. Pero esto se haría a nivel de "fábrica" o el usuario lo haría manualmente, y como tal tampoco tendría forma de actualizar a través de un host HSTS. [vea enlace para obtener más información]
Para responder a su última pregunta, existe un problema de privacidad en el uso de HSTS para rastrear a los usuarios. Funciona utilizando javascript para verificar si un recurso en una lista de sitios web que se enumera se carga a través de https, aunque se especifique como http. El punto de tener una edad máxima moderadamente baja en este caso sería tener las entradas despejadas para que el seguimiento del usuario se vea obstaculizado. [vea enlace para obtener más información]
@Jesper Mortensen: HSTS hace que el navegador reescriba todas las solicitudes http a https antes de enviarlas. Por lo tanto, no debe tener accesos http y https a un dominio determinado. Y cualquiera que implemente HSTS DEBERÍA (RFC2119) no tener un sitio http real (es decir, redirigir las solicitudes http a https a través de 301 o hacer otra cosa [consulte la sección 6.2]). Y las cosas de contexto mixtas (http a otros recursos de dominio no ssl no-hsts son un problema que se supone que se debe resolver en una base de implementador (tanto para el servidor como para el navegador)). También trate de no burlarse de su estado borrador, ya que se implementa tanto en Firefox como en Google Chrome (ium) [es decir, ~ 55% de todos los navegadores].