La necessità di includere i domini in HST RFC

Question

La necessità di includere i domini in HST RFC

#1 da (2 voti)
#2 da (0 voti)

2

Sto cercando di capire la direttiva includeSubDomains nello standard HTTP Strict Transport Security. In particolare sezione 14.4 di RFC 6797 mi confondono.

Il punto 2. dice

The HTTP request sent to uxdhbpahpdsf.example.com will include the Secure-flagged domain cookie.

Ciò sembra implicare che se un cookie di dominio è stato impostato come sicuro, può infatti essere trasmesso a un server prima che il certificato di quel server sia stato convalidato. Ciò vanificherebbe completamente lo scopo di impostare il cookie come sicuro in primo luogo. Se questo non è il caso, allora che cosa sto fraintendendo in quel paragrafo?

Il punto 3. dice

and the user "clicks through" any warning that might be presented

Ciò sembra implicare che lo scenario delle minacce si applicherebbe solo nel caso in cui l'utente ignori gli avvisi di sicurezza o una CA abbia firmato un certificato contraffatto. Ma se uno di questi fosse il caso, l'attacco avrebbe potuto essere indirizzato al dominio example.com.

Qual è la connessione tra includeSubDomains e quel paragrafo? Il punto 3. tratta solo uno scenario, in cui la comunicazione viene passata comunque su HTTPS, il che significa che l'HSTS non farebbe alcuna differenza.

cookies hsts

posta kasperd 21.01.2015 - 13:04

fonte

2 risposte

Leggi altre domande sui tag cookies hsts

Utilizzo di "Security Compliance Manager" per controllare un sistema Windows Sicurezza dell'API REST

score 2 · Answer 1

Penso che il modo di leggere questi tre punti sia come tre parti di una vulnerabilità e sia meglio leggerlo in un ordine diverso. HSTS fa fa la differenza sulle connessioni HTTPS, e in effetti molto significativo: HSTS non consente agli utenti di fare clic attraverso un avviso dal browser. Tutti gli errori di convalida dei certificati con HSTS sono fatali; il browser non consentirà all'utente di aggiungere un'eccezione, che è il problema più grande affidandosi solo alle avvertenze sui certificati per impedire MitMs. Quindi, se l'utente malintenzionato registra quel sottodominio, il problema è (in ordine diverso da RFC):

Il sito dell'aggressore fornisce un certificato TLS. Se è considerato un certificato valido dal browser, HSTS non aiuta (perché l'HSTS non include il blocco), ma probabilmente sarà un certificato non valido.
Il browser Web avvisa di un problema con il certificato. Poiché il sottodominio non dispone di set HSTS, l'utente può aggiungere un'eccezione o altrimenti ignorare l'avviso del certificato per accedere al sito.
Il cookie di dominio viene inviato al server dell'utente malintenzionato tramite la connessione TLS.

Con includeSubDomains , si verifica quanto segue:

Il sito dell'aggressore fornisce un certificato TLS; di nuovo, se è valido, l'utente viene hosed.
Il browser avverte di un problema con il certificato. Poiché HSTS è impostato, si tratta di un errore irreversibile. La connessione viene interrotta prima che venga inviata una richiesta HTTP.
Non c'è 3. La connessione è stata interrotta nel passaggio 2.

(Come nota a margine: la convalida dei certificati avviene sempre durante lo stabilimento della connessione TLS, nessuna richiesta HTTP viene inviata finché non viene stabilito dopo TLS. Quindi nessun cookie viene mai inviato su HTTPS prima che i certificati vengano controllati.)

score 0 · Answer 2

Potrei sbagliarmi qui, ma credo che abbia a che fare con il blocco dei certificati nell'UA. "Precaricano un set specifico di hash delle chiavi pubbliche nella configurazione HSTS, che limita i certificati validi solo a quelli che indicano la chiave pubblica specificata."

Quindi suppongo che in questo scenario di attacco il sottodominio venga bloccato da HSTS perché non presenta un certificato valido per example.com. Laddove, come senza la direttiva includeSubDomains, il cert di esempio.com non viene mai considerato, il certificato TLS viene accettato e il cookie di dominio viene rubato.