La pregunta (para la mayoría de las personas) es un oxímoron. Por definición, la gente pensará que "WiFi abierta" significa "WiFi sin cifrar. Para mí parece que estás preguntando" ¿Por qué las personas que escribieron el 802.11 de manera estándar en 1997, ¿toma las decisiones que tomaron?"

La respuesta corta: solo podemos averiguarlo preguntándoles (o viendo si hay algún documento de discusión flotando en Internet).

Sin embargo, podemos discutir la parte de Firesheep de la pregunta. Un ataque "Firesheep" es un tipo específico de ataque donde las cookies que autentican a un usuario en un sitio son copiadas por un atacante.

El único requisito es que el atacante pueda obtener las cookies y, por lo tanto, redes WiFi que usen WEP, WPA o WPA2 con una sola clave precompartida es vulnerable , si el atacante tiene la clave . Y, por supuesto, muchas pequeñas empresas proporcionan acceso a WiFi mediante una sola clave.

Tener puntos de acceso "mejores" es una manera costosa de solucionar este problema, y seguirá dejando a los usuarios vulnerables al escenario de ataque anterior (donde el atacante puede usar ARP envenenamiento más un man-in-the-middle ataque contra sitios HTTP solamente).

Por lo tanto, en cuanto a las soluciones, la mejor y la más útil sería la implementación generalizada de HTTPS ( como se recomienda por el creador de Firesheep, Eric Butler)

Firesheep no tiene nada que ver con el cifrado WiFi. Si usted y yo estuviéramos conectados a una conexión WiFi encriptada, aún así podría mantener a Firesheep sus datos.

¿Qué hace Firesheep a nivel de enrutador? No intercepta las ondas en el aire (bueno, no exactamente)

Básicamente, ejecuta un suplantación de identidad ARP . Este tipo de ataque también puede ejecutarse en una red LAN; se trata de alimentar al enrutador sobre la dirección MAC correspondiente a una IP determinada. Cuando un enrutador desea distribuir un paquete a una IP determinada, necesita saber quién es el propietario de esa IP. Si no tiene estos datos en su caché, emite un mensaje solicitando estos detalles. Cualquiera en la subred puede responder a la transmisión y decir que la IP es de ellos, incluso si no lo es. Usando esto, un atacante puede sentarse directamente entre el enrutador y la víctima en el canal de comunicación.

Para que quede claro: este es un problema con TCP / IP (el protocolo que impulsa la red). No con WiFi.

Las otras respuestas ya han explicado que los ataques al estilo Firesheep (básicamente MitM a pesar de ARP spoofing ) no tiene nada que ver con el WiFi en sí. Este es un problema de capa de enlace .

En cuanto a por qué las redes WiFi abiertas no tienen cifrado. Bueno, simplemente no lo hacen. Realmente no sé por qué decidieron no hacerlo, solo puedo especular. Una razón muy obvia son los ataques MitM, ya que cualquiera podría hacerse pasar por el punto de acceso (AP) y negociar la conexión cifrada con las víctimas. Lo que nos lleva a un problema de PKI , en caso de que los propietarios de AP adquieran certificados de confianza para sus puntos de acceso. Pero eso anula todo el propósito de una Red Wifi Abierta, porque entonces tendrías que verificar la identidad del AP.

¿Cómo sabemos que "JFK Airport AP" es realmente el punto de acceso del aeropuerto JFK? ¿Deberíamos emitir certificados para puntos de acceso llamados "JFK AP"? ¿Llevaría eso a ataques de ingeniería social? ¿Tengo que crear mis propios certificados y luego pedirles a mis amigos que confíen en ellos cuando se conecten a mi red? Ahora, por supuesto, se podría argumentar que podemos usar el modelo de confianza en el primer uso, pero eso no funciona para redes WiFi en parques, aeropuertos o en la calle.

Hay algunas propuestas para resolver el problema, como una propuesta de los estudiantes en el estado de Ohio Universidad , lo llaman autenticación ficticia

  

Nuestra solución utiliza el cifrado de clave simétrica existente   algoritmos, por ejemplo, TKIP y AES, que ya se utilizan en el WPA y   Productos 802.11i para proteger los marcos inalámbricos contra la suplantación de identidad y las escuchas ilegales. Para utilizar los algoritmos de cifrado existentes,   Las claves de cifrado son obviamente necesarias. En esta sección, primero   Proponer un nuevo algoritmo de establecimiento de clave de autenticación ficticia. Entonces   Utilizamos la clave de sesión establecida para proteger los marcos inalámbricos.

Lo que realmente me gusta. Si lo piensa un poco, vería que solucionaría el problema de rastreo y problemas de suplantación de AP (como con la falsificación ARP) con el uso de certificados emitidos por CA.

  

Suponemos que cada AP tiene un par de claves público-privadas, denotado como pk   y sk , por ejemplo, claves RSA. La clave pública está contenida en un CA firmado   Certificado o un certificado autofirmado.

Por supuesto, eso requeriría actualizar todos los puntos de acceso WiFi existentes y parchear los sistemas operativos. No es una cosa fácil de hacer.

Tienes razón en que no son el mismo problema: la autenticación de contraseña y el cifrado simétrico son conceptos totalmente independientes que se pueden implementar sin el otro. Sin embargo, una contraseña es una de las varias formas de producir la clave necesaria para operar el cifrado.

Una conexión encriptada como la que se establece entre su computadora y su AP se implementa utilizando encriptación simétrica. Para que el cifrado simétrico funcione, ambas partes (la computadora y el AP) deben compartir una clave (una pequeña cantidad de datos confidenciales) para cifrar un flujo y descifrarlo posteriormente.

Una forma común de hacerlo es usar una clave precompartida (PSK), en la que ambas partes tienen conocimiento de la clave anterior al intento de establecer la conexión. Esto es lo que está haciendo cuando configura una frase de contraseña de Wi-Fi: cuando ingresa la frase de contraseña en el enrutador y luego nuevamente en la computadora, ahora ambos tienen esta información. El intercambio de la clave no se realiza a través de la red, donde se puede escuchar a escondidas, sino manualmente mediante el teclado, que suele ser mucho más seguro.

(La clave no es técnicamente la contraseña en sí, sino algunos datos que se derivan de ella).

El cifrado requiere una clave. Esta es la razón por la que se le pide una frase de contraseña y por qué, sin una, no obtiene el cifrado. Existen otras formas, además de una frase de contraseña, para generar claves, pero no las encontrará en su AP.

Considere esta situación: Sin una frase de contraseña, la AP podría generar la clave (como con un PRNG fuerte). La clave de alguna manera tendría que ser comunicada a la computadora. La forma más sencilla sería a través de la conexión inalámbrica en sí misma (suponiendo que el AP no tiene otros medios para enviar datos a la computadora). Una vez que se recibe esto, el tráfico restante en la conexión se puede cifrar.

El problema es que la conexión no está cifrada mientras se envía la clave (si lo fuera, la parte receptora no podría leer la clave). Un intruso puede recuperar fácilmente la clave no encriptada y monitorear el resto de la sesión como si no estuviera cifrada.

Los teóricos dirían que, dado que esto es posible, su conexión ya está bien o no encriptada y es mejor que no desperdicie los ciclos de la CPU codificados. Yo digo que si bien ese ataque no sería efectivo a menos que el atacante esté al principio de la conexión, no puedes asumir con seguridad que este no es el caso (todo el tiempo).

Hay formas de evitar este problema en particular usando el cifrado y la autenticación asimétricos (basados en claves públicas), mediante el cual, mediante cierta magia matemática, puede cifrar datos que nadie, excepto el destinatario (¡ni siquiera usted!) puede descifrar, pero la configuración puede ser complicada y, desde la última vez que compré una, no es probable que sea una función incorporada de tu AP.

Actualización: Diffie-Hellman

Incluso si se usa el intercambio de claves Diffie-Hellman, todavía hay un problema de confianza.

Aquí hay un breve resumen de por qué:

• Sin el establecimiento previo de confianza entre las partes, la autenticación no es significativa.
• Sin una autenticación significativa, DH no es significativo. (Es vulnerable a un ataque de hombre en el medio).
• Sin DH significativo, el cifrado basado en un intercambio DH no es significativo.
• La comunicación sin cifrado significativo es (aproximadamente) equivalente a la comunicación sin ningún cifrado.
• Por lo tanto, un esquema de cifrado predeterminado basado en DH no es sustancialmente más seguro que ningún cifrado a menos que se haya establecido primero la confianza.
• Sin un mecanismo de confianza por parte de terceros (como PKI o web de confianza), el establecimiento de confianza requiere un intercambio directo (en persona, por teléfono, etc., según el nivel de paranoia) de la información.
• Cualquier mecanismo útil para el intercambio directo podría, al menos tan fácilmente, usarse para compartir un PSK.

Establecer confianza es un problema que es difícil de resolver entre extraños sin un intercambio directo, y ese intercambio directo ya es suficiente para compartir un PSK.

Una forma de evitar el intercambio directo, teóricamente, sería comprar un certificado SSL para su AP de una CA pública. Esto podría ser un poco caro, y creo que los propietarios de AP no son tan propensos a pagar extra para proporcionar Wi-Fi seguro a extraños. Se podría usar un certificado autofirmado en su lugar, pero esto requeriría que el invitado confíe ciegamente en una autofirma, lo que lo deja abierto a MITM, o que obtenga e instale el certificado después de verificar su firma con el original; de nuevo requiere un intercambio directo.

Cuando se habla de "sin contraseña" y "misma contraseña", me imagino que se refiere a la clave precompartida. Esto no es en realidad una contraseña, pero la estación y el AP lo utilizan como un valor conocido para generar y de forma segura (al menos de fuentes externas sin el valor conocido) intercambiar material de claves para el tráfico cifrado. WPA / WPA2-Personal en realidad no se autentica, solo encripta.

WPA / WPA2-Enterprise utiliza 802.1X para autenticarse y, si la autenticación es exitosa, genera e intercambia material de claves.

Básicamente, para configurar cualquier comunicación cifrada, ambas partes necesitan algún punto común sobre el cual construir el cifrado. En la web (SSL / TLS), a menudo esto se hace mediante el uso de certificados, pero un dispositivo 802.11 funciona en la capa 2, lo que excluye muchos de estos métodos.

802.11 usa las dos opciones para proporcionar este punto común, ya sea el PSK o la información de la autenticación 802.1X.

¿Por qué el WiFi abierto no está encriptado?

Es la misma razón por la que WPA-PSK no utiliza el intercambio de claves Diffie-Hellman / RSA .

El primer punto de Adnan es la respuesta más precisa.

  

En cuanto a por qué las redes WiFi abiertas no tienen cifrado. Bueno, simplemente no lo hacen.

No hay razón técnica. Probablemente sea una razón financiera y / o burocrática. Y cambiar la infraestructura existente no es fácil.

¿Cómo sabemos que "JFK Airport AP" es realmente el punto de acceso del aeropuerto JFK?

Tenga en cuenta que existe una diferencia entre la autenticación y el cifrado. El problema descrito es un problema de autenticación que existe independientemente de si estamos cifrando o no una conexión Wi-Fi. En otras palabras: el hecho de que RSA no proporcione autenticación no tiene nada que ver con la cuestión de por qué RSA no se está implementando en redes Wi-Fi abiertas. Además, el problema de autenticación se puede resolver utilizando un método extremadamente simple que se describe en el siguiente ejemplo:

Nuestro futuro, enrutador Wi-Fi habilitado para cifrado utiliza Diffie-Hellman / RSA. El enrutador tiene una pequeña pantalla LED que muestra su clave pública, o tal vez un simple hash de la clave pública. El punto de acceso se llama "MyHouse".

Me gustaría conectar mi teléfono a "MyHouse", pero hay otro AP con el mismo nombre, todo lo que tengo que hacer es mirar el monitor de mi enrutador y comparar la cadena con la cadena que se muestra en mi teléfono. De esta manera, se logra una fácil autenticación. Los aeropuertos y lugares públicos pueden emplear técnicas similares al mostrar la clave pública / hash en pantallas grandes o en algunas calcomanías de bajo costo.

Nota al margen: El LED es solo un ejemplo, hay muchos otros métodos disponibles.

¿Se pueden configurar algunos enrutadores para permitir el acceso público sin contraseña, y aún así > cifrar las conexiones de los usuarios para evitar ataques al estilo Firesheep?

Sí, eso se puede configurar, pero no estaría en el nivel del enrutador. Y el que se conecte debería tomar algunos pasos adicionales.

Solución 1. Proxy web HTTPS

Una técnica extremadamente simple que se podría usar de inmediato es navegar por la web usando un proxy web cifrado HTTPS, como HideMyAss . De esa manera, uno está utilizando la criptografía de clave pública, pero se está haciendo en la parte superior de la capa TCP.

Solución 2. un servidor VPN LAN o un servidor de túnel SSH

Se puede utilizar un enfoque similar en la red local sin depender de sitios externos: use un servidor VPN local / servidor de túnel SSH. Los datos fluirían de esta manera:

  

Dispositivo de red (por ejemplo, mi teléfono) > AP > Dispositivo de red (servidor de túnel VPN / SSH) > AP > Internet. (# flow1)

El túnel VPN / SSH actúa como una extensión del AP, si los resumimos mentalmente, obtendríamos:

  

Dispositivo de red (Mi teléfono) > Cifrado AP > Destino. (# flow2)

Solución 2. ¡Notas importantes!

• DEBE usar una conexión por cable entre el túnel VPN / SSH y el AP Si utilizo la solución LAN, vea el final de mi respuesta.

• Si desea implementar esto de manera práctica, puede usar una poder pequeño siempre en la computadora como una RaspberryPi como servidor de SSH Tunnel, Lo probé y no veo una latencia notable.

Solución 3. Servidor de túnel VPN / SSH regular

Uno podría usar una VPN que no está en la LAN, entonces obtendríamos:

  

Dispositivo de red (Mi teléfono) > AP > VPN > Destino. (# flow3)

En los 3 casos, los datos están totalmente encriptados usando TLS / SSL / Lo que sea que su VPN / SSH esté encriptada.

Si utiliza la solución LAN VPN / SSH, el servidor debe estar conectado , de lo contrario, el tráfico que el servidor VPN / SSH reenvía desde el cliente al destino se enviará sin cifrar a la AP.

Más acerca de la solución LAN

Si utiliza una conexión inalámbrica en un WiFi abierto con una solución de servidor de túnel LAN VPN / SSH, así es como fluye el tráfico. Esta es una expansión de "flow1", en la que si los datos están encriptados o no se agregan al flujo:

  

Dispositivo de red > datos encriptados > AP > datos encriptados > Servidor VPN / SSH > datos sin cifrar > AP > Internet

Por esta razón, debemos usar un cable cableado entre el servidor VPN / SSH y el AP, de esa manera, los datos no cifrados nunca se envían por aire.

Sospecho que la respuesta tiene que ver con la "falta de estado" del enrutador WIFI. Los paquetes entrantes y salientes se tratan de manera uniforme. Si se negociara algún tipo de cifrado por conexión, el enrutador tendría que mantener el estado para cada socio comunicante. Esto rompería el modelo de "capa"; los paquetes se tratan de manera uniforme y las capas superiores tratan con cosas como el cifrado y la continuidad.

No soy un experto en seguridad y solo tengo conocimientos básicos de criptografía, pero creo que tiene toda la razón y la conexión a wifi debería estar cifrada con DH para proteger al menos de las escuchas ilegales. Esto no puede proteger de MitM pero ese ataque es más difícil de hacer. Especialmente esto se puede evitar de manera significativa si confía en el primer uso.

Y en realidad podemos ir más lejos e implementar PKI como para HTTPS. Por ejemplo, mi enrutador también sirve mi página de inicio y tiene su propio dominio y certificado HTTPS firmado por CA. Por lo tanto, sería estupendo que en la lista de redes inalámbricas se muestre un candado verde igual que en el navegador. Para los grandes puntos de acceso público como en los aeropuertos, esto también podría ser una solución asequible.

Tampoco tengo idea de por qué no usar un TLS / SSH habitual en lugar de usar algunos algoritmos CRACKed.

Es una gran irresponsabilidad que esto no se haya implementado durante tanto tiempo y que miles de millones de usuarios sean vulnerables incluso sin saberlo.

Pero recientemente se lanzó un WPA3 y cuenta con Perfect Forward Secrecy y OpenWrt lo admite en las compilaciones de instantáneas recientes. Aquí hay un artículo interesante con las primeras impresiones al respecto enlace

Espero que esto resuelva el problema pero quién sabe, quizás también tenga algunas vulnerabilidades.