¿Es HTTPS a través de wifi todavía seguro si un hacker puede configurar un servidor DHCP no autorizado?

  

Dado que el pirata informático ahora controla cualquier comunicación entre la víctima y el mundo exterior, ahora podría reutilizar el certificado real emitido por GeoTrust Global CA para el dominio mail.google.com cuando accedo al servidor HTTP en 192.168.1.50.

No, él no puede. Para identificarse con un certificado (que debe hacerse para falsificar el servidor), debe tener acceso a la clave privada del certificado, que no está disponible por el atacante. Por lo tanto, HTTPS es seguro contra la falsificación de DNS.

Para obtener más detalles sobre por qué este es el caso, consulte ¿Cómo funciona SSL / TLS? .

Steffen tiene razón al decir que el pirata informático no puede falsificar el certificado del servidor remoto a través de HTTPS y, por lo tanto, no puede interceptar el intercambio de datos cifrados sin que el usuario reciba avisos de alertas de certificados no válidos. Sin embargo:

1. Esto no evita los ataques de eliminación de SSL.

2. Esto no evita los ataques de fijación de sesiones a través de HTTP (lo difícil es predecir el sitio al que el usuario accederá a través de HTTPS).

Ambos se pueden prevenir con HSTS (pero este último es el resultado de un error en la implementación del sitio también).

Surge otro signo de interrogación sobre la confianza depositada en las Autoridades de Certificación y, en particular, las que podrían estar presentes en el almacén de sistemas de certificados de raíz (como las que se encuentran recientemente en Dell y Lenovo ). Si bien esto no es específico del escenario de AP no autorizado, hay ubicaciones donde se conectarán altas concentraciones de usuarios a un sitio web conocido.

Sin embargo, tenga en cuenta que todos ellos aprovechan una falla de seguridad en otro lugar.

El certificado puede ser falsificado, sin embargo, el navegador arrojará un error.

Sin embargo, supongamos que un enrutador / DNS malicioso o un atacante escuchan en http / DNS a google.com y lo redirigen a un sitio con un ligero error tipográfico.

Está hablando con un amigo o está chateando con el servidor, y solo se da cuenta demasiado tarde después de escribir la contraseña, que se trata de un sitio de phishing.

O la redirección de http simplemente instala malware o intenta explorar las vulnerabilidades del navegador.

Al navegar, también no solo usa sitios HTTP, sino que también está usando un servicio de DNS potencialmente hostil. El hecho, por ejemplo, de que haya codificado 8.8.8.8 (Google) u otros servidores DNS no lo ayudará mucho. De hecho, en nuestras VPN corporativas, intercepto solicitudes de DNS a través de iptables, y se realizan con mis DNS sin importar lo que el cliente haya configurado a mano. Un enrutador malicioso puede hacer eso y algunos ISPes más dudosos ya lo están haciendo.

También puede haber un actor potencialmente malo conectado al mismo AP que está realizando un ataque de suplantación ARP. Tener un AP comprometido es la menor de tus preocupaciones. O puedes conectarte a un AP falso. De hecho, un par de malware de Windows tenía el rasgo interesante de crear un AP falso con el SSID de "Wifi público gratuito" o algo similar.

Suceden cosas malas.

Como tal, se considera una práctica de seguridad estándar usar wifi pública con un firewall fuerte, un sistema operativo actualizado y una conexión VPN, que proporcionará una conexión virtual confiable al exterior y con servicios DNS .

Además, en OS / X y iPhone, también puede instalar un perfil VPN a pedido, que garantizará que nunca se establezca una conexión con el exterior sin que primero se active la VPN.

También te enlazaré con un tema relacionado:

Es HTTPS capaz de prevenir el veneno ARP atacar en LAN?