Perché rfc6797 dice "Un host HSTS NON DEVE includere il campo dell'intestazione STS nelle risposte HTTP su un trasporto non sicuro."

Question

Perché rfc6797 dice "Un host HSTS NON DEVE includere il campo dell'intestazione STS nelle risposte HTTP su un trasporto non sicuro."

#1 da (26 voti)
#2 da (6 voti)

18

Perché RFC proibisce al server di inviare HSTS al client tramite HTTP?

Posso vedere che se un client HTTP risponde a quella risposta HTTP non sicura potrebbe causare che quel sito sia inaccessibile al client, ma non vedo alcun motivo per cui il server abbia un MUST nel protocollo.

Piuttosto, il client NON DEVE rispondere all'HSTS nelle risposte HTTP non sicure è l'approccio corretto nella mia mente. Cosa mi manca?

7.2. HTTP Request Type

If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect, such as status code 301 (Section 10.3.2 of [RFC2616]), and a Location header field value containing either the HTTP request's original Effective Request URI (see Section 9 ("Constructing an Effective Request URI")) altered as necessary to have a URI scheme of "https", or a URI generated according to local policy with a URI scheme of "https".

NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to:

Risks in server-side non-secure-to-secure redirects [OWASP-TLSGuide].

Site deployment characteristics. For example, a site that incorporates third-party components may not behave correctly when doing server-side non-secure-to-secure redirects in the case of being accessed over non-secure transport but does behave correctly when accessed uniformly over secure transport. The latter is the case given an HSTS-capable UA that has already noted the site as a Known HSTS Host (by whatever means, e.g., prior interaction or UA configuration).

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

web-browser tls certificates hsts threat-mitigation

posta random65537 27.03.2015 - 13:41

fonte

2 risposte

6

Questo potrebbe essere per evitare l'uso di questa intestazione per causare un attacco denial of service.

Immagina un sito Web solo HTTP non sicuro. Ora immagina qualcuno in grado di manomettere le intestazioni HTTP inviate da questo sito per aggiungere un'intestazione HSTS. Secondo la RFC:

L'UA dovrebbe smettere di provare ad accedere al sito tramite HTTP e provare a utilizzare solo HTTPS.
Se l'UA non è in grado di stabilire una connessione HTTPS, dovrebbe considerare che si tratta di un errore lato server e che l'utente non può ricorrere a un ricorso.

In altre parole, l'utente finale non sarebbe più in grado di accedere a questo sito solo HTTP, da cui il DoS.

risposta data 27.03.2015 - 14:30

fonte

Leggi altre domande sui tag web-browser tls certificates hsts threat-mitigation

L'AES dovrebbe sempre dare lo stesso risultato? Modi per proteggersi dai bambini di Firesheep e altri sniffing

score 26 · Accepted Answer

Questo comportamento client è proibito dalla sezione 8.1 della RFC :

If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).

La specifica proibisce a severs di inviare client e non conformi alle direttive HSTS dall'elaborazione di direttive HSTS insicure. Ciò garantisce che un'implementazione difettosa in un server o client non sia sufficiente per minare l'HSTS; il fallimento deve essere presente in entrambi i casi in cui la debolezza sia presente.

Come notato nella tua domanda, l'HSTS su un semplice HTTP sembra un ottimo modo per un utente malintenzionato di implementare un diniego di servizi forzato a lungo termine su un servizio offerto via HTTP. Infatti, sezione 14.3 di RFC 6797 risolve questo problema in particolare (oltre a una preoccupazione ancora più seria):

The rationale behind this [requirement that HSTS be served over secure connections only] is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability")); for example:

Unauthorized notation of the host as a Known HSTS Host, potentially leading to a denial-of-service situation if the host does not uniformly offer its services over secure transport (see also Section 14.5 ("Denial of Service")).

Resetting the time to live for the host's designation as a Known HSTS Host by manipulating the max-age header field parameter value that is returned to the UA. If max-age is returned as zero, this will cause the host to cease being regarded as a Known HSTS Host by the UA, leading to either insecure connections to the host or possibly denial of service if the host delivers its services only over secure transport.

Poiché HTTP può essere facilmente falsificato, un utente malintenzionato potrebbe specificare una direttiva HSTS per trattare un sito solo HTTP come un sito HTTPS: il client richiederebbe HTTPS e il server non sarebbe in grado di fornirlo.

Più seriamente, questa sezione della RFC indica che un utente malintenzionato che può emettere direttive HSTS per un host potrebbe rimuovere lo stato dell'host come host HSTS noto, consentendo in tal modo al client di emettere semplici richieste HTTP all'host.