¿La confidencialidad de WiFi proporcionada por las puertas de enlace de puntos de acceso públicos es igual o peor que la WPA2?

2

Como entiendo cómo funcionan la mayoría de los hotspots WiFi, requieren que el usuario se autentique en una página web a la que presta servicio un proxy en la puerta de enlace predeterminada de WiFi. Después del proceso de autenticación (si corresponde) que el usuario realizó en la página web, se le permite conectarse a Internet a través del filtrado de direcciones MAC. Pero la conexión WiFi aún está clara y sujeta a escuchas informales, ¿no?

¿O hay algunos protocolos WiFi que no conozco que permitirían al terminal de usuario establecer un nuevo canal encriptado (a la WPA2) con el AP basado en la interacción que tuvo el usuario con el proceso de autenticación web?

Editar: para aclarar el motivo de mi consulta es que me di cuenta de que la mayoría de los clientes de WiFi en la actualidad notifican al usuario que se une a dicha red que "se requiere una autenticación". En un teléfono móvil, al seleccionar esta notificación, el navegador abrirá directamente la página web de autenticación. Así que supongo que hay un intercambio de nivel de protocolo WiFi entre el cliente WiFi y el AP relacionado con este paso de autenticación, ¿por qué no también obtener un PSK generado aleatoriamente a través de una clave pública del AP?

    
pregunta Samuel 27.10.2017 - 17:05
fuente

2 respuestas

3

La seguridad es peor y va más allá de un simple problema de confidencialidad.

Como usted indicó, de hecho está "sujeto a escuchas casuales" , pero como también notó que el usuario legítimo tiene "permiso para conectarse a Internet a través del filtrado de direcciones MAC" .

Un atacante puede cambiar su propia dirección MAC para compartir la misma que el usuario legítimo. Esto crea un conflicto de direcciones MAC, pero en la práctica esto solo produce algunos mensajes de advertencia adjuntos a algún archivo de registro del sistema que los usuarios finales nunca verifican de todos modos. La conexión se mantiene y funciona para ambas partes simultáneamente (ya que comparten el mismo dominio de colisión).

De ahora en adelante, no solo el atacante puede espiar los datos legítimos del usuario, sino que ahora el atacante puede hacerse pasar por él a los ojos del punto de acceso (y la infraestructura y el proveedor detrás de él). El atacante generalmente también puede mantener el acceso abierto en cualquier momento arbitrario después de que el usuario legítimo se fue (esto requiere que el atacante simule una actividad regular todo el tiempo, ya sea cualquier actividad al azar o simule una cierta actualización de la página web de "autenticación", pero esto es fácilmente automatizable).

La mayoría, si no todos los accesos WiFi abiertos sin cifrar que confían en un portal sufren de tales problemas: albergue, acceso WiFi pagado, servicios de punto de acceso público que algunos ISP presionan para que sus usuarios finales compartan su WiFi con otros suscriptores, etc.

A partir de ahí, tienes dos formas principales de proteger esto:

  • O permanezca en las capas superiores de la red: proporcione una aplicación cliente VPN al usuario (no necesariamente llame a esto VPN, desde un punto de vista comercial cualquier cosa hará: "WiFi- Acceda a ", etc.). En lugar de usar una página web, el usuario usará su software cliente para autenticarse y "abrir" el acceso WiFi (en la práctica, el WiFi no encriptado proporciona acceso a un servidor VPN, y brinda acceso a Internet a clientes autenticados).

  • O soluciona el problema en las capas inferiores: proporcione al usuario final una "contraseña de WiFi" de PSK (por ejemplo, en los albergues), o en lugar de proporcionarles una aplicación cliente VPN, proporcione los certificados que se utilizarán para conectarse a sus puntos de acceso (por ejemplo, los ISP). Desde allí se establecerá un canal más seguro entre el usuario final y el punto de acceso, lo que permitirá al usuario autenticarse de forma segura en la página cautiva del hotspot.

No hay forma aquí de, como sugirió, crear un token de seguridad en una capa superior (la capa de aplicación, aquí el navegador) para usarla para asegurar una capa inferior (la capa de enlace de datos, aquí la conexión WiFi) . Implementas la seguridad en una u otra capa.

    
respondido por el WhiteWinterWolf 27.10.2017 - 19:03
fuente
0

Para mi descripción, asumiré que esta es una implementación de portal cautivo que es probable que veas en un hotel, por ejemplo.

El wifi aún está a salvo si no se realiza ninguna autenticación (como WPA2) antes de la conexión. Parece que la mayoría de las implementaciones optan por la opción no segura que permite un acceso más fácil a los invitados. He visto que algunos hoteles requieren un PSK para acceder al Wifi y luego a un portal cautivo forzado. (Esto proporcionaría el tráfico cifrado y autenticado como se esperaba).

    
respondido por el ISMSDEV 27.10.2017 - 17:47
fuente

Lea otras preguntas en las etiquetas