Dal progetto di bozza IETF [ link ]:
10.1 HSTS Policy expiration time considerations
Server implementations and deploying web sites need to consider whether they are setting an expiry time that is a constant value into the future, e.g., by constantly sending the same max-age value to UAs.
For example, a max-age value of 778000 is 90 days:
Strict-Transport-Security: max-age=778000
Note that each receipt of this header by a UA will require the UA to update its notion of when it must delete its knowledge of this Known HSTS Host. The specifics of how this is accomplished is out of the scope of this specification.
Or, whether they are setting an expiry time that is a fixed point in time, e.g., by sending max-age values that represent the remaining time until the expiry time.
A consideration here is whether a deployer wishes to have the signaled HSTS Policy expiry time match that for the web site's domain certificate.
Additionally, server implementers should consider employing a default max-age value of zero in their deployment configuration systems. This will require deployers to wilfully set max-age in order to have UAs enforce the HSTS Policy for their host, and protects them from inadvertently enabling HSTS with some arbitrary non-zero duration.
Quindi, dal momento che il browser aggiornerà il suo HSTS max-age memorizzato su ogni intestazione max-age ricevuta [oltre https], andare con il tempo più lungo non causerà alcuna brutta storia cache horror che il gossip parla di . L'unico problema è se il certificato cambia. Tuttavia, i proprietari dei siti dovrebbero essere consapevoli di questo e dovrebbero avere il limite massimo di età (5-8 minuti) subito prima (un giorno intero o giù di lì) la modifica del cert viene effettuata a causa della scadenza. Tuttavia, questo è solo per gestire una scadenza di cert in entrata (che è in gran parte evitata sostituendo il certificato con uno nuovo prima dell'ultimo minuto), come può essere visto da:
14.6 Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack
If an attacker can convince users of, say, https://bank.example.com (which is protected by HSTS Policy), to install their own version of a root CA certificate purporting to be bank.example.com's CA, e.g., via a phishing email message with a link to such a certificate. Then, if they can perform an attack on the users' DNS, (e.g., via cache poisoning) and turn on HSTS Policy for their fake bank.example.com site, then they have themselves some new users.
Che mostra che la modifica del certificato nel mezzo della "sessione" HSTS di un broswer non causerebbe problemi a meno che non ci fossero problemi con il certificato (avvertimenti o errori di convalida). Ciò renderebbe discutibile l'intero punto della tua domanda perché presuppone che i browser memorizzino alcune informazioni relative al certificato inviato con la risposta dell'intestazione HSTS per la convalida con l'host HSTS. Poiché la bozza non fa menzione di un simile concetto, direi che è un'ipotesi non valida.
Tuttavia, la memorizzazione delle informazioni di cert da utilizzare contro gli host HSTS può essere eseguita con il blocco della chiave pubblica. Ma questo sarebbe fatto a livello di "fabbrica" o manualmente dall'utente, e come tale non avrebbe alcun modo di aggiornare tramite un host HSTS. [vedi link per ulteriori informazioni]
Per rispondere alla tua ultima domanda, c'è un problema di privacy nell'uso di HSTS per tracciare gli utenti. Funziona usando javascript per verificare se una risorsa in un elenco di siti web che viene enumerato viene caricata tramite https anche se è specificata come http. Il punto di avere un limite massimo di età medio in questo caso sarebbe quello di eliminare le voci in modo tale da ostacolare il tracciamento degli utenti. [vedi link per ulteriori informazioni]
@Jesper Mortensen: HSTS fa sì che il browser possa riscrivere tutte le richieste http su https prima di inviarle. Pertanto, non è necessario avere accessi http e https a un determinato dominio. E chiunque implementa HSTS DOVREBBE (RFC2119) non abbia un vero sito http (cioè reindirizzamento su richieste http a https via 301 o fare qualcos'altro [vedere la sezione 6.2]). E il contesto misto (http ad altre risorse di dominio non-ssl non-hsts sono un problema che dovrebbe essere affrontato in base a un implementatore (sia dal server che dal browser)). Prova anche a non deridere il suo stato di bozza dato che è implementato sia in Firefox che in Google Chrome (ium) [es. ~ 55% di tutti i browser].