Una connessione HTTPS può essere compromessa a causa di un server DNS canaglia

Per connettersi a qualsiasi sito Web, tramite https o no, è necessario l'indirizzo IP del sito e si richiede al server DNS di utilizzare il nome di dominio del sito. Se il tuo server DNS non ha memorizzato nella cache la risposta, cercherà di risolvere la tua richiesta chiedendo un'intera serie di server DNS (il server DNS radice, il gestore dominio di primo livello ... fino al server DNS che è autorevole per il dominio) .

Un utente malintenzionato che controlla uno di questi server può rispondere a te con un falso indirizzo IP per quel sito Web, e questo è ciò che il tuo browser proverà a visitare. Questo indirizzo IP nel caso generale avrà una replica del sito web ospitato, per renderlo simile a quello originale, o semplicemente agire come un mittente di inoltro della connessione al sito corretto dopo aver catturato ciò di cui ha bisogno.

Ora passiamo a ulteriori dettagli: se il sito web è protetto da HTTPS ci saranno molte insidie. Il sito web normale avrà un certificato emesso che lega i dettagli del nome di dominio al sito web, ma questo viene fatto usando la crittografia asimmetrica.

Ciò significa che attraverso il processo dell'handshake SSL, il sito Web deve dimostrare di conoscere la chiave privata associata alla chiave pubblica nel certificato. Ora, la parte malintenzionata può benissimo servire il certificato originale del sito Web quando si tenta di accedere all'IP errato con il nome host corretto, ma non conoscerà la chiave privata, quindi l'handshake SSL non verrà mai completato.

Ma ci sono modi per l'intercettore di far funzionare tutto, posso pensare a quattro:

1) La soluzione più semplice è offrirti un certificato autofirmato invece di uno normale. Questo sarà emesso dall'attaccante stesso. Normalmente il tuo browser ti avviserà di questo, e se usi una versione recente del browser gli avvisi saranno dappertutto, ma gli utenti tendono a fare clic su quel tipo di roba.

2) Un altro approccio, utilizzato negli attacchi Stuxnet, consiste nel rubare le chiavi private utilizzate per un certificato valido dall'organizzazione che si desidera impersonare.

3) Un'altra soluzione, che è accaduta in un paio di casi (non stiamo parlando dell'attaccante medio qui) è che egli sfrutta qualche errore nella procedura di registrazione che le autorità di certificazione (o le autorità di registrazione) usano e riesce a emettere un certificato per un sito Web che non gli appartiene. Ci sono stati casi in cui gli RA semplicemente non hanno fatto abbastanza controlli e rilasciato certificati per google.com ..

4) Simile a quanto sopra: un attaccante competente "hack" un certificato o un'autorità di registrazione e riesce a rilasciare alcuni certificati con qualsiasi nome voglia. È successo nel maggio del 2011 (il famoso comodo-hack) e nel luglio del 2011 (l'hack di DigiNotar). Vedi ulteriori dettagli su Quanto è fattibile hackerare una CA? Quali certificati radice affidabili di default dovrei rimuovere? - Sicurezza IT .

5) Infine, la tecnica più spaventosa è quella che possono essere utilizzate da tre agenzie di lettere e simili: se un governo controlla un'autorità di certificazione, in teoria può costringerlo a rilasciare certificati a volontà, per qualsiasi sito. Ora pensate che le autorità di certificazione siano diffuse in tutto il mondo, alcune in paesi dove questo può sembrare molto possibile. Un esempio da osservare qui è la CA operata da Emirates Telecommunications Corporation (Etisalat), posseduta al 60% dal governo degli Emirati Arabi Uniti (UAE). Etisalat ha lanciato una volta una patch BlackBerry dall'aspetto innocuo che ha inserito spyware nei dispositivi RIM, consentendo il monitoraggio della posta elettronica.

Inoltre, se il client supporta ancora il vecchio protocollo SSL 2.0, un MITM può eseguire il downgrade della connessione SSL e utilizzare un algoritmo di crittografia simmetrica più debole o uno scambio di chiavi più debole.

Quindi, per riassumere, se l'attaccante controlla il server DNS può fare cose molto malevole, ma per intercettare il traffico crittografato SSL ha bisogno di qualcosa di più.

E per rispondere alla tua ultima domanda: il sito della CA non ha bisogno di essere risolto ogni volta che visiti un sito: il sito web di solito ti fornisce il certificato pubblico che utilizza da solo, ma è possibile che tu lo ottenga dalla CA . Questo però non cambia nessuna delle cose menzionate sopra.

È che non dovrebbe essere possibile. Se l'utente malintenzionato è in grado di controllarti il DNS, potrebbe reindirizzare l'utente verso un server compromesso. Ma il tuo browser (se configurato correttamente) ti avviserà di un certificato guasto.

Ma in effetti è possibile ! Nel caso in cui il server non abbia un certificato valido, il tuo browser ti avviserà quando ti connetti al server reale e quando ti connetti alla macchina degli attaccanti. Non sei in grado di decidere se questo avviso è critico.
In un altro scenario l'attaccante è riuscito ad afferrare il certificato valido del server (si veda ad esempio qui ). Quindi è in grado di reindirizzarti verso un server compromesso e il tuo browser non dirà nulla ..

Oltre all'eccellente risposta di @ John, un server DNS canaglia può causare altri danni, oltre a qualsiasi effetto sulla connessione HTTPS corrente (anche se questo è strettamente al di fuori della portata della tua domanda, penso che sia ancora rilevante). Ci sono tipi di danni che può fare, oltre a cercare di intercettare la tua connessione corrente.

Se chiedi a un server DNS malintenzionato di risolvere gli indirizzi per te, può darti le risposte che non hai richiesto, influenzando così le altre connessioni che hai creato - anche dopo aver smesso di usare il DNS canaglia .
Per esempio. utilizzando tecniche di avvelenamento DNS . (Vedi anche la mia risposta a questa domanda .)

Inoltre, il DNS dannoso può reindirizzare intenzionalmente l'utente a un altro server, ad es. un server vittima che verrà ora inondato da richieste false.

Oltre a tutto questo, chi ti garantisce in realtà fa la connessione SSL? La maggior parte degli utenti non si preoccupa di digitare "aich tee tee pee ESS(!) colon whack whack... " ... Si limiterà a digitare il nome del dominio (ad esempio "mybank") e premere ctrl + invio, oppure far apparire il motore di ricerca, oppure ... e in In tutti questi casi, è probabile che la richiesta iniziale dell'utente non sia nemmeno HTTPS. (Naturalmente, se fai lo digiti specificatamente, è diverso, quindi YMMV su quel punto).

Suggerisco anche di dare un'occhiata ad alcune risposte a "Cosa è implicato nel rilevare il nome di dominio di qualcun altro?"

Alcuni proxy aziendali (che operano tramite reindirizzamento DNS o una varietà di altri mezzi) possono ispezionare il contenuto di una connessione SSL. Inoltre, gli utenti di un desktop gestito non riceveranno un avviso del browser se il certificato MITM è stato installato nell'archivio locale.

A seconda di chi gestisce il proxy e di come vengono utilizzati i suoi registri, ciò può essere accettabile o negativo dalla tua prospettiva.

Per ulteriori informazioni su come l'intercettazione SSL è stata eseguita, consulta questo link :

When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store.

The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...

Ulteriori informazioni ...

Un altro punto: un utente malintenzionato che possiede il tuo resolver DNS può indirizzare erroneamente le richieste OCSP o CRL a un buco nero e praticamente tutti i browser la considereranno come una prova che il certificato non è stato revocato. Quindi, se un cattivo viene a rubare un certificato valido ma il bravo lo revoca, il cattivo può impedire ai client di vedere quella revoca oscurando la richiesta OCSP / CRL.

Perché è difficile differenziare i siti di phishing. Ecco l'osservatorio SSL di EFFs.

link

L'idea generale è valida, le imitazioni sono dovute a un'erronea emissione di certificati. Se si potesse essere sicuri che tutti gli altri là fuori, di fronte a un certificato, avessero lo stesso identico certificato, allora la probabilità che si tratti di un sito di phishing sarebbe vicino a zero. La parte più sorprendente della ricerca è il numero di nodi foglia e CA che sono attendibili dal browser.

Nel tuo caso, la domanda è NO, la connessione HTTPS NON PU be essere compromessa.

Ora, scopriamo perché.

1. Il tuo browser ha le chiavi pubbliche della CA. Chiavi pubbliche attendibili.

2. Supponendo che l'attaccante non solo sia in grado di controllare il DNS, ma anche i server stessi, in questo caso, sia la CA che i server HTTP di destinazione.

3. L'autore dell'attacco NON può falsificare la CA perché non ha le chiavi private corrispondenti come browser.

4. L'utente malintenzionato NON può falsificare neanche il server HTTP, perché il suo certificato non avrà il marchio di una CA attendibile.

Nel caso estremo in cui l'attaccante può ottenere un certificato per il dominio che non controlla / possiede, il punto precedente non è valido. E l'attaccante può fare tutto ciò che la sua immaginazione può evocare. Il fatto è che questo viola la nostra stessa supposizione che la CA sia affidabile! È colpa della CA che concede all'attaccante un tale certificato. E quando CA non è più affidabile, SSL è solo una tigre di carta.

C'è un attacco blended che ingannerebbe la maggior parte della gente link

L'attaccante agisce come un uomo nel mezzo e crea un collegamento non criptato con il victum che mostra http: // ... nel browser ma il lucchetto è impostato e verde, quindi alla gente manca la mancanza di https: // ...