La disattivazione firefox di una parte di fallback TLS non sicura della specifica HSTS?

1

Ho esaminato HSTS e vedo che Firefox lo supporta dalla versione 4, ma posso anche vedere che è possibile fare clic su avvisi di browser cert non attendibili fino a Firefox 37.

La disabilitazione di questa parte di fallback TLS non sicura della specifica HSTS a cui tutti i browser dovrebbero attenersi, o è una qualche aggiunta di valore aggiunta da Mozilla?

    
posta gtmcclinton 22.01.2016 - 12:28
fonte

1 risposta

7

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" :

  1. 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.

    
risposta data 22.01.2016 - 16:39
fonte

Leggi altre domande sui tag