In che modo i siti Web impediscono la falsificazione dei certificati?

Question

In che modo i siti Web impediscono la falsificazione dei certificati?

#1 da (4 voti)

1

Recentemente ho sviluppato interesse per l'hacking wireless, e ho visto in molti casi in video e cose che le persone sono (o più correttamente, erano) in grado di eseguire una sorta di attacco MitM usando il metodo del male gemello contro i grandi siti come FB , GMail.

Ci sono molti strumenti che automatizzano la creazione di AP falsi e includono inoltre strumenti come SSLStrip e SSLSplit per cercare di aggirare TLS / SSL e HSTS.

Finché so che HSTS funziona, il client deve aver visitato lo stesso sito Web almeno una volta. Ma questo non è un grosso problema ora, visto che c'è il precaricamento dell'HSTS dai browser, e tutti i famosi siti web sono già inclusi lì, quindi anche se il cliente viene inserito nel sito Web per la prima volta, eseguirà ancora l'HSTS. D'altra parte, credo che questi siti Web utilizzino anche il pinning del certificato (un concetto che non mi è molto familiare), che finché so che significa che invece di usare la catena di attendibilità del certificato, specificano direttamente per quale certificato apparire, e se il certificato è diverso, basta interrompere la connessione.

D'altra parte, credo che gli strumenti che cercano di aggirare queste tecnologie, usano l'idea che le persone non scrivano www.facebook.com, ma invece scrivano solo facebook.com, in modo che gli strumenti possano reindirizzare la richiesta per esempio wwww.facebook.com, per cui è possibile falsificare un certificato. Ma, credo che questo non sia più vero. Ma cosa impedisce che l'attacco sia in grado di falsificare il certificato per qualche sottodominio senza senso del sito ufficiale, il pinning del certificato o l'HSTS, o entrambi? Inoltre, come funzionano HSTS e pinning dei certificati?

certificates certificate-pinning man-in-the-middle hsts

posta typos 30.05.2016 - 22:16

fonte

1 risposta

Leggi altre domande sui tag certificates certificate-pinning man-in-the-middle hsts

Accedere accidentalmente al computer di un'azienda tramite wifi pubblico [chiuso] Utilizzo di htmlentities () in un'area di testo che supporta il BBCode per arrestare XSS

score 4 · Accepted Answer

Il comportamento di HSTS è variabile a seconda che venga applicata la direttiva includeSubdomains . Nel caso di HSTS senza includeSubDomains , un utente che visita www.facebook.com non li proteggerà se per errore sono andati a ww.facebook.com senza un prefisso HTTPS esplicito. Tuttavia, quando viene applicata la direttiva includeSubDomains è , la visita di qualsiasi sottodominio (o del dominio principale) provoca l'applicazione della regola HSTS su tutti i sottodomini. Questo può anche essere applicato come parte del preloading.

Il blocco è una misura separata e può essere raggiunto in diversi modi. I due principali sono i pin precaricati nel browser (ad esempio il pinning di Chrome) e HTTP Public Key Pinning (HPK) . Un altro modo meno comune per ottenere il pinning è con uno strumento come Microsoft EMET che aggiunge ulteriori regole di blocco al sistema. L'obiettivo di bloccare è memorizzare un identificatore per il certificato (o il certificato di firma associato) in modo che un certificato falso da un'autorità di certificazione compromessa (o altrimenti scarsa) non possa essere utilizzato per compromettere le comunicazioni.

Nel caso delle regole di blocco precaricate, la chiave pubblica del certificato di firma radice della CA o del certificato di firma intermedio viene memorizzata nel browser e la catena viene verificata quando viene presentato un certificato per un dominio corrispondente. È estremamente raro vedere i certificati foglia (cioè il certificato specifico effettivo per il dominio, piuttosto che un certificato intermedio o root) nelle regole di blocco a causa della difficoltà nel mantenere questo elenco quando il bilanciamento del carico dinamico è attivo.

Nel caso di HPKP, questa funzione funziona in modo abbastanza simile a quella di HSTS. Quando un utente visita il sito, viene restituita un'intestazione che contiene un elenco di hash delle chiavi pubbliche per i certificati validi (firmatari o certificati stessi). Quando l'utente rivisita il sito in una data successiva, il browser ha memorizzato nella cache questa regola HPKP e può utilizzarlo per verificare che il certificato appena presentato sia ancora valido e non sia stato alterato tramite autofirma o tramite una diversa (potenzialmente compromesso) CA. Questa funzione ha anche la direttiva includeSubdomains , che può essere applicata all'intestazione HPKP per indicare che tutti i sottodomini devono essere considerati parte di tale regola. Una caratteristica aggiuntiva di HPKP rispetto al pinning nel browser è che una chiave di firma "backup" deve essere inclusa come parte della regola HPKP, in modo che possa essere utilizzata per aggiornare la regola HPKP se i certificati originali scadere.

Con entrambe queste funzionalità in atto e la direttiva includeSubdomains applicata a entrambi, i seguenti metodi di attacco sono mitigati:

Gli hacker che spoofano i record DNS per puntare al loro IP non possono fornire un certificato autofirmato o un certificato con errori; i browser non consentono il click-through quando la regola HSTS è attiva e la regola HPKP impone al certificato di adeguarsi alle regole di firma specificate.
Un utente malintenzionato che compromette una CA o che gestisce la propria CA generalmente attendibile (ad esempio stati nazione) non può soppiantare il certificato originale con il proprio, poiché HPKP impone l'utilizzo di un elenco di CA attendibili.
Gli utenti che tentano di visitare direttamente http:// vengono reindirizzati automaticamente dal loro client a https:// ; il browser non comunicherà su HTTP semplice con il server.
Gli hacker che spoofano i record DNS su un falso nome canonico all'interno dello stesso dominio principale non possono spoofingare il certificato per questo sottodominio alternativo; la direttiva includeSubdomains su ogni intestazione fa sì che tutti i sottodomini siano protetti.