L'HSTS, il meccanismo di sicurezza del trasporto di HTTP Strict, è definito da RFC 6797 .
La sezione pertinente è sezione 12.1, Nessun ricorso dell'utente , che afferma (in parte) che ( la mia enfasi):
Failing secure connection establishment on any warnings or errors
(per Section 8.4 ("Errors in Secure Transport Establishment")) should
be done with "no user recourse". This means that the user should not
be presented with a dialog giving her the option to proceed. Rather,
it should be treated similarly to a server error where there is
nothing further the user can do with respect to interacting with the
target web application, other than wait and retry.
Essentially, "any warnings or errors" means anything that would cause
the UA implementation to announce to the user that something is not
entirely correct with the connection establishment.
Quanto sopra è consiglio di implementazione non normativa . Tuttavia, la sezione 8.4, Errori nel Secure Transport Establishment è normativo di riferimento, e afferma (per intero) che (il mio accento):
When connecting to a Known HSTS Host, the UA MUST terminate the
connection (see also Section 12 ("User Agent Implementation Advice"))
if there are any errors, whether "warning" or "fatal" or any other
error level, with the underlying secure transport. For example, this
includes any errors found in certificate validity checking that UAs
employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
as via TLS server identity checking [RFC6125].
Qui, "UA" significa "user agent", che è il termine tecnico per, tra le altre cose, un browser web. In RFC, "must" significa davvero "must" :
- MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
Quindi, se un client si connette a un sito Web tramite HTTPS, che annuncia HSTS nella sua risposta HTTP, se il browser Web consente all'utente di procedere con la connessione alla luce di un certificato non attendibile, sta agendo in violazione di certo l'intenzione e molto probabilmente la lettera dello standard HSTS.
Si noti il termine host HSTS noto perché un'intestazione HSTS viene consegnata solo dopo che è stata inviata la prima richiesta e deve essere stabilita una connessione TLS prima che la prima richiesta possa essere inviata, il browser non può sapere prima che sia stato fatto o meno che l'host remoto usi l'HSTS. Questa vulnerabilità può essere evitata dal proprietario del sito Web utilizzando Precarico HSTS . Una volta che un UA ha stabilito un host come host HSTS, sia attraverso il preloading che attraverso un'intestazione HSTS in una risposta, tale informazione dovrebbe essere memorizzato nella cache, idealmente persistentemente , dall'UA per la quantità di tempo indicata .
TL; DR:
Per i motivi illustrati sopra, in presenza di problemi SSL / TLS con un host che annuncia HSTS, assenza del preload HSTS, la prima richiesta potrebbe riuscire (perché il comportamento non HSTS di consentire il clic tramite un avviso SSL / TLS è l'impostazione predefinita e l'host non ha ancora avuto la possibilità di annunciare altro). Tuttavia, qualsiasi connessione avviata dopo il completamento della prima richiesta (supponendo che ciò avvenga entro il periodo di massima età HSTS) o in presenza di preloading HSTS è richiesta in errore perché a quel punto l'host è un HSTS noto host.
Sembra ragionevole affermare che il mancato rispetto da parte della UA dei requisiti MUST di una specifica pertinente e implementata è un bug. Per questo motivo, il comportamento che descrivi di Firefox 4 a 36 sembra essere stato un bug.