Otázka (pro většinu lidí) je oxymoron. Podle definice si lidé budou myslet, že „otevřené WiFi“ znamená „nezašifrované WiFi. Zdá se mi, že se ptáte„ Proč lidé, kteří v roce 1997 napsali standardní 802.11 cestu, učinili rozhodnutí, že oni udělali? "

Krátká odpověď - zjistíme to pouze tím, že se jich zeptáme (nebo zjistíme, zda na internetu neplavou nějaké diskusní dokumenty).

Můžeme však diskutujte o části otázky Firesheep. Útok „Firesheep“ je specifický typ útoku, kdy útočník kopíruje soubory cookie, které ověřují uživatele na webu.

Jediným požadavkem je, aby soubory cookie mohly být získané útočníkem - a proto sítě WiFi využívající WEP, WPA nebo WPA2 s jedním předem sdíleným klíčem jsou zranitelné, pokud útočník klíč má . A samozřejmě , mnoho malých podniků poskytuje přístup WiFi pomocí jediného klíče.

Mít „lepší“ přístupové body je nákladný způsob řešení tohoto problému a uživatelé budou i nadále zranitelní vůči výše uvedeným útokům. cenario (kde útočník může použít otravu ARP plus útok uprostřed proti webům pouze HTTP).

Proto pokud jak budou řešení fungovat, nejlepší a nejužitečnější bude rozšířená implementace HTTPS ( podle doporučení od tvůrce Firesheep, Erica Butlera)

Firesheep nemá nic společného se šifrováním WiFi. Pokud byste oba byli v šifrovaném připojení WiFi, mohl bych vaše data Firesheep stále zpracovat.

Co se Firesheep děje, se děje na úrovni routeru. Nezachytává vlny ve vzduchu (dobře, ne přesně).

V zásadě provádí útok ARP spoofing. Tento druh útoku lze spustit také v síti LAN; zahrnuje krmení lží routeru o MAC adrese odpovídající dané IP. Pokud si směrovač přeje distribuovat paket na danou IP adresu, musí zjistit, komu tato IP adresa patří. Pokud nemá tato data ve své mezipaměti, vysílá zprávu požadující tyto podrobnosti. Kdokoli v podsíti může odpovědět na vysílání a říci, že IP je jeho, i když tomu tak není. Díky tomu se může útočník usadit přímo mezi router a oběť v komunikačním kanálu.

Aby bylo jasno: Jedná se o problém s TCP / IP (protokol, který řídí síť). Ne s WiFi.

Ostatní odpovědi již vysvětlily, že útoky ve stylu Firesheep (v zásadě MitM trh ARP spoofing) nemají nic společného se samotnou WiFi. Toto je odkazová vrstva.

Proč otevřené sítě WiFi nemají šifrování. No, prostě ne. Opravdu nevím, proč se rozhodli ne, mohu jen spekulovat. Jedním ze zcela zjevných důvodů jsou útoky MitM, protože kdokoli by se mohl vydávat za přístupový bod (AP) a vyjednávat šifrované spojení s oběťmi. Což nás vede k problému PKI, pokud by vlastníci AP měli pro své přístupové body získat důvěryhodné certifikáty. Ale to maří celý účel Open Wifi Network, protože pak byste museli ověřit identitu AP.

Jak zjistíme, že „AP letiště JFK“ je ve skutečnosti přístupovým bodem JFK letiště? Měli bychom vydávat certifikáty pro přístupové body zvané „JFK AP“? Vedlo by to k útokům na sociální inženýrství? Musím si vytvořit vlastní certifikáty a poté požádat přátele, aby jim důvěřovali, když se připojí k mé síti? Nyní by se samozřejmě dalo namítnout, že můžeme použít model důvěry při prvním použití, ale to nefunguje pro WiFi sítě v parcích, na letištích nebo na ulici.

Existuje několik návrhů, jak tento problém vyřešit, například návrh studentů na Ohio State University, říkají mu Dummy Autentizace

Naše řešení využívá stávající šifrovací algoritmy symetrických klíčů, např. TKIP a AES, které se již používají v produktech WPA a 802.11i, k ochraně bezdrátových rámců před spoofingem a odposlechem. Aby bylo možné použít stávající šifrovací algoritmy, jsou zjevně potřebné šifrovací klíče. V této části nejprve navrhneme nový algoritmus pro založení falešného ověřovacího klíče. Potom použijeme zavedený klíč relace k ochraně bezdrátových rámců.

Což se mi opravdu líbí. Pokud se nad tím trochu zamyslíte, zjistíte, že by to vyřešilo problém s čicháním a problémy s vydáváním AP (například s ARP spoofing) s použitím certifikátů vydaných CA.

Předpokládáme, že každý přístupový bod má pár veřejného a soukromého klíče označený jako pk a sk , např. klíče RSA. Veřejný klíč je obsažen v certifikátu podepsaném CA nebo certifikátu podepsaném svým držitelem.

To by samozřejmě vyžadovalo upgrade všech stávajících přístupových bodů WiFi a opravy operačních systémů. Není to snadná věc.

Máte pravdu, že nejde o stejný problém: Ověřování pomocí hesla a symetrické šifrování jsou zcela nezávislé koncepty, které lze implementovat bez druhého. Heslo je však jedním z několika způsobů, jak vytvořit klíč potřebný k šifrování.

Šifrované připojení, jako je například mezi vaším počítačem a vaším přístupovým bodem, je implementováno pomocí symetrického šifrování. Aby symetrické šifrování fungovalo, musí obě strany (počítač i přístupový bod) sdílet klíč (malé množství důvěrných dat) pro šifrování streamu a následné dešifrování.

Jeden běžný způsob, jak toho dosáhnout používá předsdílený klíč (PSK), kde jsou obě strany informovány o klíči před pokusem o připojení. To je to, co děláte, když nastavíte přístupovou frázi Wi-Fi: Když zadáte přístupovou frázi na routeru, pak znovu na počítači, oba tyto informace nyní mají. Ke sdílení klíče nedochází přes síť, kde by jej bylo možné odposlouchávat, ale ručně pomocí klávesnice, což je obvykle mnohem bezpečnější.

(Klíč technicky není samotná přístupová fráze, ale některá data, která jsou z ní odvozena.)

Šifrování vyžaduje klíč. To je důvod, proč jste požádáni o přístupovou frázi a proč bez ní nedostanete šifrování. Existují i ​​jiné způsoby než přístupová fráze k výrobě klíčů, ale na svém přístupovém bodu je nenajdete.

Zvažte tuto situaci: Bez přístupové fráze může být klíč vygenerován (například se silným PRNG) AP. Klíč by nějak musel být předán počítači. Přímý způsob by byl přes samotné bezdrátové připojení (za předpokladu, že AP nemá žádný jiný způsob odesílání dat do počítače). Jakmile je toto přijato, zbývající provoz na připojení lze zašifrovat.

Potíž je v tom, že připojení není šifrováno během odesílání klíče (pokud by to bylo, přijímající strana by nemohla klíč přečíst). Odposlouchávač může snadno získat nezašifrovaný klíč a sledovat zbytek relace, jako by nebyl zašifrován.

Teoretici by řekli, že protože je to možné, vaše připojení je již stejně dobré jako nezašifrované a vy možná také neztrácí cykly CPU tím, že to zakóduje. Říkám, že i když by tento útok nebyl efektivní, pokud by útočník nebyl na začátku připojení, nemůžete bezpečně předpokládat, že tomu tak není (po celou dobu).

Tady jsou způsoby, jak vyřešit tento konkrétní problém pomocí asymetrického šifrování a autentizace založeného na veřejném klíči, kde pomocí nějaké matematické magie můžete šifrovat data, která nikdo kromě příjemce (ani vy!) nemůže dešifrovat, ale může to být komplikované nastavit a od doby, kdy jsem si naposledy koupil, pravděpodobně nebude vestavěnou funkcí vašeho AP.

Aktualizace: Diffie-Hellman

I když Používá se výměna klíčů Diffie-Hellman, stále existuje problém důvěry.

Zde je krátký přehled důvodů:

• Bez předchozího vytvoření důvěry mezi stranami, ověřování nemá smysl.
• Bez smysluplného ověřování nemá DH smysl. (Je zranitelný vůči útoku typu man-in-the-middle.)
• Bez smysluplného DH nemá šifrování založené na výměně DH smysl.
• Komunikace bez smysluplného šifrování je ( zhruba) ekvivalent komunikace bez jakéhokoli šifrování.
• Výchozí šifrovací schéma založené na DH tedy není podstatně bezpečnější než žádné šifrování, pokud nebyla nejprve vytvořena důvěra.
• Bez mechanismu důvěryhodnosti od třetích stran (jako je PKI nebo web důvěryhodnosti), vytvoření důvěry vyžaduje přímou výměnu informací (osobně, telefonicky atd. v závislosti na úrovni paranoie).
• Ke sdílení PSK by mohl být alespoň tak snadno použit jakýkoli užitečný mechanismus pro přímou výměnu.

Navázání důvěry je problém, který je obtížné vyřešit mezi cizími lidmi bez přímé výměny , a taková přímá výměna je již dostatečná ke sdílení PSK.

Jedním ze způsobů, jak se přímé výměně vyhnout, je teoreticky koupit certifikát SSL pro váš přístupový bod od veřejné CA. To by mohlo být trochu drahé a myslím si, že majitelé AP nemají takovou pravděpodobnost, že si připlatí za to, aby poskytovali zabezpečené Wi-Fi cizím lidem. Místo toho lze použít certifikát s vlastním podpisem, ale to by vyžadovalo, aby host buď slepě důvěřoval svému vlastnímu podpisu, který jej ponechává otevřený pro MITM, nebo získal a nainstaloval certifikát po kontrole jeho podpisu proti originálu - a to opět vyžadovat přímou výměnu.

Když mluvíte o „bez hesla“ a „stejném hesle“, myslím, že máte na mysli předem sdílený klíč. Toto není ve skutečnosti heslo, ale používá se jako známá hodnota stanicí a přístupovým bodem ke generování a bezpečné (alespoň z vnějších zdrojů bez známé hodnoty) výměně klíčovacího materiálu pro šifrovaný provoz. WPA / WPA2-Personal se ve skutečnosti neověří, pouze šifruje.

WPA / WPA2-Enterprise používá k ověření protokol 802.1X, a pokud je ověření úspěšné, ke generování a výměně klíčovacího materiálu.

K nastavení jakékoli šifrované komunikace je velmi důležité, aby obě strany potřebovaly nějaký společný bod, na kterém bude šifrování stavět. Na webu (SSL / TLS) se to často provádí pomocí certifikátů, ale zařízení 802.11 pracuje ve vrstvě 2, což mnoho z těchto metod vylučuje.

802.11 používá k zajištění této možnosti společný bod, buď PSK, nebo informace z ověřování 802.1X.

Proč není otevřené WiFi šifrováno?

Je to stejný důvod, proč WPA-PSK nepoužívá výměnu klíčů Diffie-Hellman / RSA.

První bod Adnana je nejpřesnější odpovědí.

Proč otevřené sítě WiFi nemají šifrování. Prostě ne.

Neexistuje žádný technický důvod. je to pravděpodobně finanční a / nebo byrokratický důvod. A změna stávající infrastruktury není snadná.

Jak zjistíme, že „JFK Airport AP“ je ve skutečnosti přístupovým bodem na letišti JFK?

Všimněte si, že existuje rozdíl mezi ověřováním a šifrováním . Popsaný problém představuje problém s ověřováním, který existuje bez ohledu na to, zda šifrujeme připojení Wi-Fi. Jinými slovy: Skutečnost, že RSA neposkytuje ověřování, nijak nesouvisí s otázkou, proč se RSA neprovádí v otevřených sítích Wi-Fi. Problém s ověřováním lze také vyřešit pomocí extrémně jednoduché metody popsané v následujícím příkladu:

Náš budoucí směrovač Wi-Fi s šifrováním používá Diffie-Hellman / RSA. Router má malý LED displej, který zobrazuje jeho veřejný klíč, nebo snad jednoduchý hash veřejného klíče. Přístupový bod se jmenuje „MyHouse“.

Chtěl bych připojit svůj telefon k „MyHouse“, ale existuje další AP se stejným názvem, vše, co musím udělat, je podívat se na monitor mého routeru a porovnejte řetězec s řetězcem zobrazeným na mém telefonu, čímž se dosáhne snadné autentizace. Letiště a veřejná místa mohou využívat podobné techniky zobrazováním veřejného klíče / hodnoty hash na velkých obrazovkách nebo na některých nízkonákladových štítcích.

Postranní poznámka: Kontrolka LED je pouze příkladem, je k dispozici mnoho dalších metod.

Lze některé směrovače nakonfigurovat tak, aby umožňovaly veřejný přístup s zatím žádné heslo> zašifrovat připojení uživatelů, aby se zabránilo útokům typu Firesheep?

Ano, lze to nakonfigurovat, ale nebylo by to na úrovni routeru. A ten, kdo se připojuje, by musel podniknout několik dalších kroků.

Řešení 1. HTTPS webový proxy

Mimořádně jednoduchá technika, kterou lze okamžitě použít, je procházení web pomocí webového proxy šifrovaného HTTPS, například HideMyAss. Tímto způsobem se používá kryptografie veřejného klíče, ale děje se to přes vrstvu TCP.

Řešení 2. LAN VPN server nebo SSH tunelový server

Podobný přístup lze použít v místní síti bez závislosti na externích webech: Použijte místní server VPN / server SSH Tunnel. Data by proudila tímto způsobem:

Síťové zařízení (Řekněme, můj telefon)> AP> Síťové zařízení (VPN / SSH tunelový server)> AP> Internet. (# flow1)

Tunel VPN / SSH funguje jako rozšíření AP, pokud bychom je mentálně zapouzdřili, dostali bychom:

Síťové zařízení ( Můj telefon)> Šifrovaný přístupový bod> Cíl. (# flow2)

Řešení 2. Důležité poznámky!

• MUSÍTE použijte kabelové připojení mezi tunelem VPN / SSH a APif pomocí řešení LAN, podívejte se na konec mé odpovědi.

• Pokud byste to chtěli prakticky implementovat, můžete používat lowpower malý vždy na počítači, jako je RaspberryPi jako server SSH Tunnel, Itried it a nevidím znatelnou latenci.

Řešení 3. Pravidelný server tunelu VPN / SSH

Dalo by se použít VPN, která není v síti LAN, pak bychom dostali:

Síť zařízení (Můj telefon)> AP> VPN> Cíl. (# flow3)

Ve všech 3 případech jsou data plně šifrována pomocí TLS / SSL / Ať je vaše VPN / SSH šifrována.

Pokud používáte řešení LAN VPN / SSH, server musí být kabelový , jinak bude provoz, který je předáván serverem VPN / SSH z klienta do cíle, odesílán nešifrovaný do AP.

Více informací o řešení LAN

Pokud používáte bezdrátové připojení na otevřené WiFi s řešením tunelového serveru LAN VPN / SSH, tok dat probíhá tímto způsobem. Jedná se o rozšíření „flow1“, ve kterém je do toku přidáno, zda jsou data šifrována či nikoli:

Síťové zařízení> šifrovaná data > AP> šifrovaná data > server VPN / SSH> nešifrovaná data > AP> internet

Z tohoto důvodu musíme použít kabelový kabel mezi serverem VPN / SSH a přístupovým bodem se tak nešifrovaná data nikdy neposílají vzduchem.

Mám podezření, že odpověď má co do činění s „bezstavovostí“ routeru WIFI. S příchozími a odchozími pakety je zacházeno jednotně. Pokud by bylo sjednáno nějaké šifrování na základě jednotlivých připojení, router by musel udržovat stav pro každého komunikujícího partnera. To by narušilo model „vrstvy“; že s pakety je zacházeno jednotně a vyšší vrstvy řeší věci jako šifrování a kontinuita.

V současné době skutečně existuje přístup k šifrování připojení k otevřeným hotspotům wifi pomocí „Oportunistického bezdrátového šifrování“. OWE je specifikováno v RFC 8110.

Nevím, kteří klienti nebo hotspoty tento standard skutečně podporují.

Nejsem bezpečnostní expert a kryptografii rozumím jen základně, ale myslím si, že máte naprostou pravdu a připojení k wifi by mělo být šifrováno pomocí DH, aby bylo chráněno alespoň před odposlechem. To nemůže chránit před MitM, ale tento útok je těžší udělat. Zejména tomu lze významně zabránit důvěrou prvního použití.

A ve skutečnosti můžeme jít dále a implementovat PKI jako pro HTTPS. Například můj router také slouží mé domovské stránce a má vlastní doménu a certifikát HTTPS podepsaný CA. Bylo by skvělé, kdyby se v seznamu bezdrátových sítí zobrazil zelený visací zámek stejný jako v prohlížeči. Pro velké veřejné přístupové body, například na letištích, by to také mohlo být cenově dostupné řešení.

Také nemám ponětí, proč místo obvyklých algoritmů TRACKED použít obvyklý TLS / SSH.

To je velká nezodpovědnost, že to nebylo implementováno tak dlouho a miliardy uživatelů jsou nyní zranitelné i bez toho, aby o tom věděli.

Nedávno však vyšlo WPA3, které má Perfect Forward Secrecy a OpenWrt to podporuje v posledních sestaveních snímků. Zde je zajímavý článek s prvními dojmy o něm https://gist.github.com/est31/d92d17acbb4ea152296f9b38764cd791

Doufám, že to problém vyřeší, ale kdo ví - možná má také určité chyby zabezpečení.