La domanda (per la maggior parte delle persone) è un ossimoro. Per definizione, la gente penserà che "WiFi aperto" significhi "WiFi non crittografato. A me sembra che tu stia chiedendo" Perché le persone che hanno scritto 802.11 standard nel lontano 1997 prendono le decisioni che hanno fatto?"

La risposta breve - possiamo solo scoprire chiedendo loro (o vedere se ci sono documenti di discussione che girano su Internet).

Tuttavia, possiamo discutere la parte Firesheep della domanda. Un attacco "Firesheep" è un tipo specifico di attacco in cui i cookie che autenticano un utente su un sito vengono copiati da un utente malintenzionato.

L'unico requisito è che i cookie possano essere ottenuti dall'hacker e quindi reti WiFi che utilizzano WEP, WPA o WPA2 con una singola chiave pre-condivisa è vulnerabile , se l'utente malintenzionato ha la chiave . E, naturalmente, molte piccole imprese forniscono l'accesso WiFi utilizzando una sola chiave.

Avere "migliori" Punti di accesso è un modo costoso per risolvere questo problema e lascerà comunque gli utenti vulnerabili allo scenario di attacco sopra (dove l'attaccante può usare Avvelenamento ARP più un man-in-the-middle attacco contro siti solo HTTP).

Pertanto, per quanto riguarda le soluzioni, la migliore e più utile sarebbe l'implementazione diffusa di HTTPS ( come raccomandato dal creatore di Firesheep, Eric Butler)

Firesheep non ha nulla a che fare con la crittografia WiFi. Se io e te fossimo entrambi su una connessione WiFi crittografata, sarei ancora in grado di Firesheep i tuoi dati.

Cosa succede a Firesheep a livello di router. Non intercetta le onde in onda (beh, non esattamente)

Fondamentalmente, esegue un attacco ARP spoofing . Questo tipo di attacco può essere eseguito anche su una rete LAN; coinvolge l'alimentazione del router si trova circa l'indirizzo MAC corrispondente a un dato IP. Quando un router desidera distribuire un pacchetto su un dato IP, deve scoprire chi possiede quell'IP. Se non ha questi dati nella sua cache, trasmette un messaggio che chiede questi dettagli. Chiunque sulla sottorete può rispondere alla trasmissione e dire che l'IP è loro, anche se non lo è. Usando questo, un attaccante può posizionarsi esattamente tra il router e la vittima nel canale di comunicazione.

Per essere chiari: questo è un problema con TCP / IP (il protocollo che guida il networking). Non con WiFi.

Le altre risposte hanno già spiegato che gli attacchi in stile Firesheep (in pratica MitM trappola spoofing ARP ) non ha nulla a che fare con il WiFi stesso. Questo è un problema del link layer .

Per quanto riguarda il motivo per cui le reti WiFi aperte non hanno crittografia. Beh, non lo fanno. Non so davvero perché hanno deciso di non farlo, posso solo speculare. Un motivo molto ovvio sono gli attacchi MitM, in quanto chiunque potrebbe impersonare il punto di accesso (AP) e negoziare la connessione crittografata con le vittime. Il che ci porta a un problema PKI , nel caso in cui i proprietari di AP acquisiscano certificati attendibili per i loro punti di accesso. Ma questo sconfigge l'intero scopo di una rete Wifi aperta, perché in tal caso dovresti verificare l'identità dell'AP.

Come facciamo a sapere che "JFK Airport AP" è davvero il punto di accesso dell'aeroporto JFK? Dovremmo rilasciare certificati per punti di accesso denominati "AP JFK"? Questo porterebbe ad attacchi di social engineering? Devo creare i miei certificati e chiedere ai miei amici di fidarsi di loro quando si collegano alla mia rete? Ora, naturalmente, si potrebbe sostenere che possiamo usare il modello basato sul trust al primo utilizzo, ma che non funziona con le reti WiFi nei parchi, negli aeroporti o per strada.

Ci sono alcune proposte per risolvere il problema, come una proposta degli studenti allo stato dell'Ohio Università , la chiamano Autenticazione fittizia

Our solution utilizes the existing symmetric key encryption algorithms, e.g., TKIP and AES, that are already used in the WPA and 802.11i products to protect wireless frames from spoofing and eavesdropping. In order to use the existing encryption algorithms, encryption keys are obviously needed. In this section, we first propose a new dummy authentication key-establishment algorithm. Then we use the established session key to protect wireless frames.

Che mi piace davvero. Se ci pensi un po ', vedresti che risolverebbe i problemi di rappresentazione di e AP di sniffing (come con lo spoofing ARP) con l'uso di certificati emessi dalla CA.

We assume that each AP has a public-private key pair, denoted as pk and sk ,e.g.,RSA keys. The public key is contained in a CA-signed certificate or a self-signed certificate.

Ovviamente ciò richiederebbe l'aggiornamento di tutti i punti di accesso WiFi esistenti e l'applicazione di patch ai sistemi operativi. Non è una cosa facile da fare.

Hai ragione che non sono lo stesso problema: l'autenticazione tramite password e la crittografia simmetrica sono concetti completamente indipendenti che possono essere implementati senza l'altro. Tuttavia, una password è uno dei vari modi per produrre la chiave necessaria per il funzionamento della crittografia.

Una connessione crittografata come quella tra il tuo computer e il tuo AP è implementata usando la crittografia simmetrica. Affinché la crittografia simmetrica funzioni, entrambe le parti (il computer e l'AP) devono condividere una chiave (una piccola quantità di dati riservati) per crittografare un flusso e decrittografarlo in seguito.

Un modo comune per farlo è usare una chiave pre-condivisa (PSK), in cui entrambe le parti sono informate della chiave precedente al tentativo di effettuare la connessione. Questo è quello che stai facendo quando imposti una passphrase Wi-Fi: quando inserisci la passphrase sul router, e poi di nuovo sul computer, ora hanno entrambe queste informazioni. La condivisione della chiave avviene non attraverso la rete, dove potrebbe essere orecchiata, ma manualmente tramite tastiera, che in genere è molto più sicura.

(La chiave non è tecnicamente la passphrase stessa ma alcuni dati che ne derivano.)

La crittografia richiede una chiave. Questo è il motivo per cui ti viene chiesta una passphrase, e perché senza uno non ottieni la crittografia. Esistono altri modi oltre alla passphrase per produrre le chiavi, ma non le troverai sul tuo AP.

Considera questa situazione: senza una passphrase, la chiave potrebbe essere generata (come con un PRNG strong) dall'AP. La chiave dovrebbe in qualche modo essere comunicata al computer. Il modo diretto sarebbe la connessione wireless stessa (presumendo che l'AP non abbia altri mezzi per inviare dati al computer). Una volta ricevuto, il traffico rimanente sulla connessione può essere crittografato.

Il problema è che la connessione non viene crittografata mentre la chiave viene inviata (se lo fosse, la parte ricevente non sarebbe in grado di leggere la chiave). Un intercettatore può facilmente recuperare la chiave non crittografata e monitorare il resto della sessione come se non fosse crittografato.

I teorici direbbero che, poiché ciò è possibile, la tua connessione è già buona come non criptata e potresti anche non sprecare i cicli della CPU a rimescolarla. Dico che mentre quell'attacco non sarebbe efficace a meno che l'attaccante non sia in giro per l'inizio della connessione, non puoi tranquillamente supporre che non sia il caso (tutto il tempo).

Ci sono modi per aggirare questo particolare problema usando la crittografia e l'autenticazione asimmetrica (a chiave pubblica), in cui tramite qualche magia matematica sei in grado di crittografare i dati che nessuno, tranne il destinatario (nemmeno tu!) può decifrare, ma può essere complicato da configurare e, dall'ultima volta che ne ho acquistato uno, non è probabile che sia una funzionalità integrata del tuo AP.

Aggiornamento: Diffie-Hellman

Anche se viene utilizzato lo scambio di chiavi Diffie-Hellman, c'è ancora un problema di fiducia.

Ecco una breve spiegazione del perché:

• Senza un precedente accordo di fiducia tra le parti, l'autenticazione non è significativa.
• Senza un'autenticazione significativa, la DH non è significativa. (È vulnerabile a un attacco man-in-the-middle.)
• Senza DH significativo, la crittografia basata su uno scambio DH non è significativa.
• La comunicazione senza crittografia significativa è (approssimativamente) equivalente alla comunicazione senza alcuna crittografia.
• Pertanto, uno schema di crittografia predefinito basato su DH non è sostanzialmente più sicuro di nessuna crittografia a meno che non sia stato stabilito il trust per primo.
• Senza un meccanismo di fiducia da parte di terzi (come PKI o rete di fiducia), l'instaurazione della fiducia richiede uno scambio diretto (di persona, per telefono, ecc. a seconda del livello di paranoia) di informazioni.
• Qualsiasi meccanismo utile per lo scambio diretto potrebbe, almeno altrettanto facilmente, essere utilizzato per condividere un PSK.

Stabilire la fiducia è un problema difficile da risolvere tra estranei senza uno scambio diretto, e tale scambio diretto è già sufficiente per condividere un PSK.

Un modo per evitare lo scambio diretto, in teoria, sarebbe quello di acquistare un certificato SSL per il tuo AP da una CA pubblica. Questo potrebbe essere un po 'costoso, e penso che i proprietari di AP non siano così propensi a pagare di più per fornire un Wi-Fi sicuro agli estranei. Potrebbe invece essere usato un certificato autofirmato, ma ciò richiederebbe all'ospite di fidarsi ciecamente di un'auto-firma, che lo lascia aperto al MITM, o di ottenere e installare il certificato dopo averne verificato la firma rispetto all'originale, e questo una volta di nuovo bisogno di uno scambio diretto.

Quando si parla di "nessuna password" e "stessa password", immagino che si stia riferendo alla chiave pre-condivisa. Questa non è in realtà una password, ma viene utilizzata come valore noto dalla workstation e dall'AP per generare e in modo sicuro (almeno da fonti esterne senza il valore noto) il materiale di keying dello scambio per il traffico crittografato. WPA / WPA2-Personal in realtà non si autentica, solo crittografa.

WPA / WPA2-Enterprise utilizza 802.1X per l'autenticazione e se l'autenticazione ha esito positivo, per generare e scambiare il materiale di codifica.

In pratica, per impostare qualsiasi comunicazione crittografata, entrambe le parti hanno bisogno di un punto in comune su cui costruire la crittografia. Sul Web (SSL / TLS), questo viene spesso fatto attraverso l'uso di certificati, ma un dispositivo 802.11 funziona a livello 2, il che preclude molti di questi metodi.

802.11 utilizza le due opzioni per fornire questo punto comune, il PSK o le informazioni dall'autenticazione 802.1X.

Perché il WiFi non è aperto crittografato?

È lo stesso motivo per cui WPA-PSK non utilizza lo scambio di chiavi Diffie-Hellman / RSA .

Il primo punto di Adnan è la risposta più accurata.

As for why open WiFi networks don't have encryption. Well, they just don't.

Non c'è una ragione tecnica. è probabilmente una ragione finanziaria e / o burocratica. E cambiare l'infrastruttura esistente non è facile.

Come sappiamo che "JFK Airport AP" è davvero il punto di accesso dell'aeroporto JFK?

Si noti che esiste una differenza tra autenticazione e crittografia. Il problema descritto è un problema di autenticazione che esiste indipendentemente dal fatto che stiamo crittografando o meno una connessione Wi-Fi. In altre parole: il fatto che RSA non fornisca l'autenticazione non è in alcun modo correlato alla domanda sul perché RSA non viene implementato su reti Wi-Fi aperte. Inoltre, il problema di autenticazione può essere risolto utilizzando un metodo estremamente semplice descritto nel seguente esempio:

Il nostro futuro router Wi-Fi con crittografia utilizza Diffie-Hellman / RSA. Il router ha un piccolo display a LED che mostra la sua chiave pubblica, o forse un semplice hash della chiave pubblica. Il punto di accesso è chiamato "MyHouse".

Vorrei collegare il mio telefono a "MyHouse", ma c'è un altro AP con lo stesso nome, tutto quello che devo fare è guardare il monitor del mio router e confrontare la stringa con la stringa visualizzata sul mio telefono, che modo, l'autenticazione facile è realizzata. Gli aeroporti e i luoghi pubblici possono impiegare tecniche simili visualizzando la chiave pubblica / hash su schermi di grandi dimensioni o su alcuni adesivi a basso costo.

Nota a margine: il LED è solo un esempio, sono disponibili molti altri metodi.

Alcuni router possono essere configurati per consentire l'accesso pubblico senza password, tuttavia > crittografare le connessioni degli utenti per prevenire gli attacchi in stile Firesheep?

Sì, è possibile configurarlo, ma non sul livello del router. E quello che collega dovrebbe fare alcuni passi extra.

Soluzione 1. Proxy Web HTTPS

Una tecnica estremamente semplice che è possibile utilizzare immediatamente è la navigazione sul Web utilizzando un proxy Web crittografato HTTPS, come HideMyAss . In questo modo si utilizza la crittografia a chiave pubblica, ma viene eseguita sopra il livello TCP.

Soluzione 2. un server LAN VPN o server del tunnel SSH

Un approccio simile può essere utilizzato sulla rete locale senza dipendere da siti esterni: utilizzare un server VPN locale / server di tunnel SSH. I dati verrebbero così:

Network device(Say, my phone) > AP > Network device (VPN/SSH Tunnel server) > AP > Internet.(# flow1)

Il tunnel VPN / SSH funge da estensione per l'AP, se incapsuliamo mentalmente quelli, otterremmo:

Network device (My phone) > Encrypted AP > Destination. (# flow2)

Soluzione 2. Note importanti!

• DEVI utilizzare una connessione cablata tra il tunnel VPN / SSH e l'AP se si utilizza la soluzione LAN, vedere la fine della mia risposta.

• Se vuoi implementarlo praticamente, puoi usare un valore basso potenza minuscola sempre su computer come a RaspberryPi come server di tunnel SSH, I l'ho provato e non vedo alcuna latenza visibile.

Soluzione 3. Server tunnel VPN / SSH normale

Si potrebbe usare una VPN che non è sulla LAN, quindi si otterrebbe:

Network device (My Phone) > AP > VPN > Destination. (# flow3)

In tutti e 3 i casi, i dati sono completamente crittografati utilizzando TLS / SSL / Qualunque sia il tuo VPN / SSH con cui viene crittografato.

Se si utilizza la soluzione LAN VPN / SSH, il server deve essere cablato , altrimenti il traffico che viene inoltrato dal server VPN / SSH dal client alla destinazione verrà inviato non crittografato all'AP.

Ulteriori informazioni sulla soluzione LAN

Se si utilizza una connessione wireless su un WiFi aperto con una soluzione di tunnel server LAN VPN / SSH, ecco come il traffico scorre. Questa è un'espansione di "flusso1", in cui il fatto che i dati siano crittografati o meno viene aggiunto al flusso:

Network Device > encrypted data > AP > encrypted data > VPN/SSH server > un-encrypted data > AP > Internet

Per questo motivo, dobbiamo utilizzare un cavo cablato tra il server VPN / SSH e l'AP, in questo modo, i dati non crittografati non vengono mai inviati attraverso l'aria.

Sospetto che la risposta abbia a che fare con l'"apolidia" del router WIFI. I pacchetti in entrata e in uscita sono trattati in modo uniforme. Se una sorta di crittografia è stata negoziata su base per connessione, il router dovrebbe mantenere lo stato per ogni partner che comunica. Questo spezzerebbe il modello "strato"; i pacchetti vengono trattati in modo uniforme e gli strati superiori si occupano di cose come crittografia e continuità.

Non sono un esperto di sicurezza e ho solo una conoscenza di base della crittografia, ma penso che tu abbia assolutamente ragione e la connessione al wifi dovrebbe essere crittografata con DH per proteggere almeno da intercettazioni. Questo non può proteggere da MitM ma quell'attacco è più difficile da fare. Soprattutto questo può essere prevenuto in modo significativo dalla fiducia del primo utilizzo.

E in realtà possiamo andare oltre e implementare PKI come per HTTPS. Ad esempio il mio router serve anche la mia homepage e ha il proprio dominio e il certificato HTTPS firmato dalla CA. Sarebbe bello se nella lista delle reti wireless fosse mostrato un lucchetto verde come nel browser. Per i grandi punti di accesso pubblici come negli aeroporti, anche questa potrebbe essere una soluzione economica.

Inoltre non ho idea del perché non usare un solito TLS / SSH invece di usare alcuni algoritmi CRACKed.

È una grande irresponsabilità che questo non sia stato implementato per così tanto tempo e miliardi di utenti sono ora vulnerabili anche senza saperlo.

Recentemente è stato rilasciato WPA3 e Perfect Forward Secrecy e OpenWrt lo supporta nelle recenti build di istantanee. Ecco un articolo interessante con le prime impressioni a riguardo link

Spero che questo risolva il problema, ma chissà, forse ha anche alcune vulnerabilità.