L'HTTPS su wifi è ancora sicuro se un hacker può configurare un server DHCP canaglia?

Since the hacker now controls any communication between the victim and the outside world, he could now reuse the real certificate issued by GeoTrust Global CA for mail.google.com domain when I access the HTTP server at 192.168.1.50.

No, non può. Per identificarti con un certificato (che deve essere fatto per falsificare il server) è necessario avere accesso alla chiave privata del certificato, che non è disponibile dall'attaccante. Quindi HTTPS è sicuro contro lo spoofing del DNS.

Per ulteriori dettagli sul perché questo è il caso, vedi Come funziona SSL / TLS? .

Steffen ha ragione nel dire che l'hacker non può falsificare il certificato del server remoto su HTTPS e quindi non può intercettare lo scambio di dati crittografato senza che l'utente riceva avvisi di avviso di certificati non validi. Tuttavia:

1. Questo non impedisce attacchi di stripping SSL.

2. Ciò non impedisce attacchi di fissazione delle sessioni su HTTP (il bit difficile è la previsione del sito a cui l'utente accederà tramite HTTPS.)

Entrambi sono prevenibili con HSTS (ma quest'ultimo è il risultato di un errore nell'implementazione del sito).

Un ulteriore punto di domanda sorge sulla fiducia riposta nelle Autorità di certificazione e in particolare su quelli che potrebbero essere presenti nell'archivio dei sistemi di certificati di root (come quelli trovati recentemente in Dell e Lenovo PC forniti). Anche se questo non è specifico per lo scenario AP rogue, ci sono luoghi in cui elevate concentrazioni di utenti si collegheranno a un sito web conosciuto.

Tuttavia tieni presente che questi tutti sfruttano un errore di sicurezza altrove.

Il certificato può infatti essere falso, tuttavia il browser genera un errore.

Tuttavia, supponiamo che un router / DNS malintenzionato o un utente malintenzionato stiano ascoltando in http / DNS per google.com e reindirizzino a un sito con un leggero errore di battitura.

Stai parlando con un amico o chattando sul server, e dopo aver digitato la password ti accorgi che è un sito di phishing.

Oppure il reindirizzamento http installa semplicemente malware o tenta di esplorare le vulnerabilità del browser.

Durante la navigazione, non usi solo i siti HTTP, ma stai anche utilizzando un servizio DNS potenzialmente ostile. Il fatto, ad esempio, che hai codificato 8.8.8.8 (Google) o altri server DNS non ti aiuterà molto. Di fatto, nelle nostre VPN aziendali intercetto le richieste DNS tramite iptables, e sono fatte con i miei DNS, indipendentemente dal setup del client a mano. Un router canaglia può farlo, e alcuni ISP più dubbi lo stanno già facendo.

Può anche esserci un attore potenzialmente cattivo collegato allo stesso AP che sta conducendo un attacco di spoofing ARP. Avere un AP compromesso è l'ultima delle tue preoccupazioni. Oppure puoi connetterti a un AP falso. In effetti, un paio di malware di Windows avevano il tratto interessante di creare un AP falso con il SSID di "Free Public Wifi" o qualcosa di simile.

Succedono cose cattive.

Come tale è considerata una pratica di sicurezza standard utilizzare il Wi-Fi pubblico con un firewall strong, un sistema operativo aggiornato e una connessione VPN, che fornirà una connessione virtuale affidabile all'esterno e con i servizi DNS .

Inoltre, in OS / X e iPhone, puoi anche installare un profilo VPN on-demand, che garantirà che nessuna connessione venga mai stabilita all'esterno senza prima che la VPN salga.

Ti collegherò anche a un thread correlato:

HTTPS è in grado di prevenire il veleno ARP attacco in LAN?