HSTS, el mecanismo de seguridad de transporte estricto de HTTP, se define mediante RFC 6797 .

La sección relevante es sección 12.1, Sin recurso del usuario , que establece (en parte) que ( mi énfasis):

  

Fallo en el establecimiento de la conexión segura en cualquier advertencia o error   (según la Sección 8.4 ("Errores en un establecimiento de transporte seguro")) debe   hacerse con "ningún recurso del usuario". Esto significa que el usuario no debería   se le presentará un cuadro de diálogo que le da la opción de continuar. Más bien,   debe tratarse de manera similar a un error del servidor donde hay   nada más que el usuario pueda hacer con respecto a la interacción con el   aplicación web de destino, que no sea esperar y reintentar.

     

Esencialmente, "cualquier advertencia o error" significa cualquier cosa que pueda causar   La implementación de UA para anunciar al usuario que algo no está   enteramente correcto con el establecimiento de la conexión.

Lo anterior es consejos de implementación no normativos . Sin embargo, la sección referenciada 8.4, Errores en el establecimiento de transporte seguro es normativa, y declara (en su totalidad) que (mi énfasis):

  

Al conectarse a un host HSTS conocido, el UA DEBE terminar el   conexión (consulte también la Sección 12 ("Consejo de implementación del agente de usuario"))   Si hay algún error, ya sea "advertencia" o "fatal" o cualquier otro   nivel de error, con el transporte seguro subyacente. Por ejemplo, esto   incluye cualquier error encontrado en la verificación de validez de certificado que los UAs   emplear, como a través de las listas de revocación de certificados (CRL) [RFC5280], o   a través del Protocolo de estado de certificado en línea (OCSP) [RFC2560], así como   como a través de la verificación de identidad del servidor TLS [RFC6125].

Aquí, "UA" significa "agente de usuario", que es el término técnico para, entre otras cosas, un navegador web. En las RFC, "debe" realmente significa "debe" :

  

1. DEBE Esta palabra, o los términos "REQUERIDO" o "DEBE", significan que   La definición es un requisito absoluto de la especificación.
  

Entonces, si un cliente se conecta a un sitio web a través de HTTPS, que anuncia HSTS en su respuesta HTTP, entonces si el navegador web le permite al usuario continuar con la conexión a la luz de un certificado no confiable, está actuando en violación sin duda la intención y muy probablemente la letra del estándar HSTS.

Tenga en cuenta el término servidor HSTS conocido; porque un encabezado HSTS se entrega solo después de que se haya enviado la primera solicitud, y se debe establecer una conexión TLS antes de poder enviar la primera solicitud, el navegador no puede saber antes que se ha hecho si el host remoto usa o no HSTS. El propietario del sitio web puede evitar esta vulnerabilidad utilizando HSTS Preloading . Una vez que un UA ha establecido un host como HSTS, ya sea mediante la precarga o mediante un encabezado HSTS en una respuesta, se supone que esa información es en caché, idealmente persistente , por la UA para la cantidad de tiempo indicada .

TL; DR:

Por los motivos descritos anteriormente, en presencia de cualquier problema de SSL / TLS con un host que anuncia HSTS, la precarga de HSTS ausente, la primera solicitud podría tener éxito (porque el comportamiento no HSTS de permitir el clic a través de una advertencia SSL / TLS es la opción predeterminada, y el host aún no ha tenido la oportunidad de anunciar nada más). Sin embargo, cualquier conexión que se inicie después de que se complete la primera solicitud (suponiendo que esto ocurra dentro del período de antigüedad máxima de HSTS) o en presencia de la precarga de HSTS, se requiere para que falle porque en ese momento el host es un HSTS conocido host.

Parece razonable afirmar que si un UA no cumple con los requisitos MUST de una especificación relevante implementada es un error. Por esa razón, el comportamiento que describe de Firefox 4 a 36 parece haber sido un error.