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.