it-swarm-eu.dev

Perché il WiFi aperto non è crittografato?

Per quanto ho capito, le reti WiFi che non richiedono password inviano il traffico attraverso l'aria senza crittografia. Quelli che richiedono una password crittografano ciascuna connessione in modo univoco, anche se utilizzano tutti la stessa password.

Se questo è vero, non capisco perché. La richiesta di una password per l'accesso e la crittografia delle connessioni sembrano problemi totalmente separati.

Sono davvero collegati in questo modo? Se è così, c'è qualche motivo che non vedo? Alcuni router possono essere configurati per consentire l'accesso pubblico senza password, ma crittografare le connessioni degli utenti per prevenire attacchi in stile Firesheep?

Aggiornare

Alcune risposte hanno affermato o sottinteso che la password è un "segreto condiviso" necessario che abilita la crittografia. Ma non è necessario Questo problema è stato risolto pubblicamente nel 1976.

Il metodo di scambio di chiavi Diffie-Hellman consente a due parti che non hanno alcuna conoscenza reciproca di stabilire congiuntamente una chiave segreta condivisa su un canale di comunicazione non sicuro. ( http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange )

63
Nathan Long

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

La risposta breve: possiamo scoprirlo solo chiedendo loro (o vedendo se ci sono documenti di discussione che fluttuano su Internet).

Tuttavia, possiamo discutere la parte relativa alla domanda di Firesheep. 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'autore dell'attacco - e quindi le reti WiFi che utilizzano WEP, WPA o WPA2 con una singola chiave precondivisa sono vulnerabili , se l'attaccante ha la chiave . E, naturalmente, molte piccole aziende forniscono l'accesso WiFi utilizzando una sola chiave.

Avere "migliori" Access Point è un modo costoso per risolvere questo problema e lascerà comunque gli utenti vulnerabili allo scenario di attacco sopra (dove l'attaccante può usare avvelenamento da 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)

19
scuzzy-delta

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

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

Fondamentalmente, esegue un attacco spoofing ARP . Questo tipo di attacco può essere eseguito anche su una rete LAN; implica che il router si trovi sull'indirizzo MAC corrispondente a un determinato IP. Quando un router desidera distribuire un pacchetto a un determinato IP, deve scoprire chi possiede tale IP. Se non ha questi dati nella sua cache, trasmette un messaggio che richiede questi dettagli. Chiunque nella 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 la rete). Non con WiFi.

14
Manishearth

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

Per quanto riguarda il motivo per cui le reti WiFi aperte non dispongono di crittografia. Beh, proprio non lo fanno. Non so davvero perché abbiano deciso di non farlo, posso solo speculare. Una ragione molto ovvia 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 Open Wifi, perché quindi dovresti verificare l'identità dell'AP.

Come facciamo a sapere che "JFK Airport AP" è davvero il punto di accesso dell'aeroporto JFK? Dovremmo emettere certificati per punti di accesso chiamati "JFK AP"? Ciò porterebbe ad attacchi di ingegneria sociale? 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 di fiducia al primo utilizzo, ma che non funziona per le reti WiFi in parchi, aeroporti o in strada.

Ci sono alcune proposte per risolvere il problema, come na proposta degli studenti della Ohio State University , la chiamano autenticazione fittizia

La nostra soluzione utilizza gli algoritmi di crittografia a chiave simmetrica esistenti, ad esempio TKIP e AES, che sono già utilizzati nei prodotti WPA e 802.11i per proteggere i frame wireless da spoofing e intercettazione. algoritmi di crittografia esistenti, sono ovviamente necessarie le chiavi di crittografia. In questa sezione, proponiamo innanzitutto un nuovo algoritmo di definizione delle chiavi di autenticazione fittizia, quindi utilizziamo la chiave di sessione stabilita per proteggere i frame wireless.

Che mi piace molto. Se ci pensi un po ', vedresti che risolverebbe il problema dello sniffing e problemi di imitazione di AP (come con lo spoofing ARP) con il utilizzo di certificati emessi dalla CA.

Partiamo dal presupposto che ogni AP ha una coppia di chiavi pubblica-privata, indicata come pk e sk , ad es. chiavi RSA. La chiave pubblica è contenuta in un certificato firmato dalla CA o in un certificato autofirmato.

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.

12
Adi

Hai ragione a dire che non sono lo stesso problema: l'autenticazione con password e la crittografia simmetrica sono concetti completamente indipendenti che possono essere implementati ciascuno senza l'altro. Tuttavia, una password è uno dei diversi modi per produrre la chiave necessaria per far funzionare la crittografia.

Una connessione crittografata come quella tra il tuo computer e il tuo AP viene implementata usando la crittografia simmetrica. Perché 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 decodificarlo in seguito.

Un modo comune per farlo è utilizzare una chiave pre-condivisa (PSK), in cui entrambe le parti vengono rese consapevoli della chiave prima di tentare di stabilire la connessione. Questo è ciò che stai facendo quando imposti una passphrase Wi-Fi: quando inserisci la passphrase sul router, quindi di nuovo sul computer, ora hanno entrambe queste informazioni. La condivisione della chiave non avviene sulla rete, dove potrebbe essere intercettata, ma manualmente dalla 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 richiesta una passphrase e perché senza uno non ottieni la crittografia. Esistono altri modi oltre a una passphrase per produrre chiavi, ma non le troverai sul tuo AP.

Considera questa situazione: senza una passphrase, la chiave potrebbe essere generata (come con un PRNG forte) dall'AP. La chiave dovrebbe in qualche modo essere comunicata al computer. Il modo più semplice sarebbe attraverso 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 viene inviata la chiave (se così 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à valida come non crittografata e potresti non sprecare i cicli della CPU per rimescolarla. Dico che mentre quell'attacco non sarebbe efficace a meno che l'attaccante non sia presente all'inizio della connessione, non si può presumere con sicurezza che non sia così (sempre).

Esistono modi per aggirare questo particolare problema utilizzando la crittografia e l'autenticazione asimmetriche (basate su chiave pubblica), in cui tramite qualche magia matematica sei in grado di crittografare dati che nessuno, tranne il destinatario (nemmeno tu!) Può decrittografare, 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 un breve riassunto del perché:

  • Senza un precedente accordo di fiducia tra le parti, l'autenticazione non è significativa.
  • Senza un'autenticazione significativa, 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 crittografia.
  • Pertanto, uno schema di crittografia predefinito basato su DH non è sostanzialmente più sicuro di nessuna crittografia a meno che non sia stata stabilita prima la fiducia.
  • Senza un meccanismo di fiducia da parte di terzi (come PKI o rete di fiducia), l'istituzione di 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 che è 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, teoricamente, sarebbe quello di acquistare un certificato SSL per il tuo AP da una CA pubblica. Questo potrebbe diventare un po 'caro e penso che i proprietari di AP non abbiano la stessa probabilità di pagare un extra per fornire Wi-Fi sicuro agli sconosciuti. In alternativa, è possibile utilizzare un certificato autofirmato, ma ciò richiederebbe all'ospite di fidarsi ciecamente di un'auto-firma, che lo lascia aperto a MITM, oppure di ottenere e installare il certificato dopo aver verificato la sua firma rispetto all'originale, e questo una volta richiede nuovamente uno scambio diretto.

7
psmay

Quando parli di "nessuna password" e "stessa password", immagino che ti riferisca alla chiave precondivisa. Questa non è in realtà una password, ma utilizzata come valore noto dalla stazione e dall'AP per generare e scambiare in modo sicuro (almeno da fonti esterne senza il valore noto) materiale di codifica per il traffico crittografato. WPA/WPA2-Personal non eseguono l'autenticazione, ma solo crittografano.

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

Fondamentalmente, per impostare qualsiasi comunicazione crittografata, entrambe le parti hanno bisogno di un punto comune su cui costruire la crittografia. Sul web (SSL/TLS), questo viene spesso fatto tramite l'uso di certificati, ma un dispositivo 802.11 funziona al 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.

4
YLearn

Perché il WiFi aperto non è 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.

Per quanto riguarda il motivo per cui le reti WiFi aperte non dispongono di crittografia. Beh, proprio non lo fanno.

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

Come facciamo a sapere 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 abilitato alla 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 si chiama "MyHouse".

Vorrei collegare il mio telefono a "MyHouse", ma c'è un altro AP con lo stesso identico nome, tutto quello che devo fare è guardare il monitor del mio router e confrontare la stringa con la stringa visualizzata sul mio telefono, in questo modo, facile l'autenticazione è stata raggiunta. Aeroporti e luoghi pubblici possono utilizzare 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, ma> crittografare le connessioni degli utenti per prevenire attacchi in stile Firesheep?

Sì, può essere configurato, ma non sarebbe a livello di router. E quello che si connette dovrebbe fare alcuni passi in più.

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 VPN LAN o un server tunnel SSH

Un approccio simile può essere utilizzato sulla rete locale senza dipendere da siti esterni: utilizzare un server VPN locale/server tunnel SSH. I dati fluiranno in questo modo:

Dispositivo di rete (ad esempio il mio telefono)> AP> Dispositivo di rete (server tunnel VPN/SSH)> AP> Internet. (# flow1)

Il tunnel VPN/SSH funge da estensione dell'AP, se li incapsuliamo mentalmente, otterremmo:

Dispositivo di rete (Il mio telefono)> AP crittografato> Destinazione. (# flow2)

Soluzione 2. Note importanti!

  • È NECESSARIO 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 desideri implementarlo praticamente, puoi usare un computer a basso consumo sempre sul computer come RaspberryPi come un server SSH Tunnel, l'ho provato e non vedo alcuna latenza evidente.

Soluzione 3. Server tunnel VPN/SSH normale

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

Dispositivo di rete (Mio telefono)> AP> VPN> Destinazione. (# flow3)

In tutti e 3 i casi, i dati sono completamente crittografati utilizzando TLS/SSL/qualunque sia la tua VPN/SSH con cui è crittografata.

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 a la destinazione verrà inviata non crittografata all'AP.

Altre informazioni sulla soluzione LAN

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

Dispositivo di rete> dati crittografati> AP> dati crittografati> server VPN/SSH> dati non crittografati > AP> Internet

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

4
Hello World

Sospetto che la risposta abbia a che fare con l '"apolidia" del router WIFI. I pacchetti in entrata e in uscita vengono trattati in modo uniforme. Se una sorta di crittografia fosse negoziata in base alla connessione, il router dovrebbe mantenere lo stato per ciascun partner di comunicazione. Ciò spezzerebbe il modello "layer"; che i pacchetti siano trattati in modo uniforme e che i livelli superiori affrontino cose come la crittografia e la continuità.

2
ddyer