Hrozí mi nějaké riziko z UPC Wi-free?

[Ráďa]

Nastavil jsem si na svém telefonu s Andoidem wifinu UPC Wi-free. Postupoval jsem podle návodu (https://www.upc.cz/pece-o-zakazniky/stavajici-zakaznik/wifree/#pripojeni). Jediné co jsem z něho porušil, bylo to, že jsem si nenainstaloval certifikát, který tam uvádějí. Připojení i přesto funguje. Otázka zní, zda to moje nastavení nepředstavuje nějaké bezpečností riziko (zejména krádež mých přihlašovacích údajů a jejich následné zneužití).

[Reklama]

[Petr Krčmář]

Hrozí. Certifikát je jediný způsob, jak může klient ověřit, že se připojuje ke správnému serveru. Pokud se tahle volba vynechá, klient se ochotně připojí k falešnému AP a heslo sdělí útočníkovi.

Takto se občas útočí na eduroam, který je taky postaven na 802.1X a uživatel se špatně nakonfigurovaným klientem je zranitelný.

[P_V]

klient se ochotně připojí k falešnému AP a heslo sdělí útočníkovi.

Měl jsem za to, že heslo k wifi se ověřuje nějakým vyspělejším způsobem, než jeho odesláním na AP.

[V.]

A to se nejdřív nedělá match na certificate chain? Že se rovnou ověřuje heslo?

[Petr Krčmář]

Je to složitější. Klient se připojí k AP, vysype svou domovskou organizaci a AP podle odpovědi RADIUS serveru zjistí, který server tuhle organizaci obsluhuje (tak to funguje u eduroamu, ale je to obecný princip). Pak otevře tunel k tomu serveru a nechá s ním povídat klienta. Tohle celé ale probíhá za AP a klient o tom nemá tušení. Takže dostane otevřený tunel někam neznámo kam.

Dalším krokem je pak sestavení TLS spojení naslepo proti tomu bezejmennému serveru „tam někde“. Takže se musí nastavit, jakým certifikátem se musí server prokázat (případně lépe, jaká autorita ten certifikát vystavuje). Pokud to tak není, pak se server prokáže libovolným certifikátem a klient mu to zbaští. To nechceme.

Heslo pak putuje tím TLS kanálem, samozřejmě ne otevřeně, ale pomocí challenge-response protokolu MS-CHAPv2. Ovšem ten je dávno prolomený a heslo je z něj možné dostat. Čili nakonec je to jen o trochu složitější než kdyby to heslo putovalo otevřeně.

Jedinou ochranou je tedy zajistit, že heslo posíláme opravdu tomu, komu chceme. A to právě zajistíme ověřením toho TLS spojení pomocí certifikátu, který máme v klientovi nějakým způsobem zapinovaný.

[Reklama]

[JardaP .]

Hm, by me zajimalo, proc se porad pouziva MS-CHAPv2, kdyz je probourany. Nebylo by jednodussi usnadnit si zivot a posilat clear text?

[Jenda]

Hm, by me zajimalo, proc se porad pouziva MS-CHAPv2, kdyz je probourany.

Protože jiné způsoby nejsou příliš podporované v zařízeních a různých OS

[JardaP .]

Protože jiné způsoby nejsou příliš podporované v zařízeních a různých OS

To sice jo, ale jak dlouho je tahle sracka prolomena?

[Ivan Nový]

Protože jiné způsoby nejsou příliš podporované v zařízeních a různých OS

To sice jo, ale jak dlouho je tahle sracka prolomena?

Stejně rychle jako jakékoliv jiné wifi.

[M.]

JardaP se spíše ptá, jak dlouho je MSCHAP prolomen, než za jak dlouho te hash zlomím.
Nu, samotný Microfot už tak od roku 2000 ne moc nahlas uváděl, že jsou tam jisté slabiny a neměl by MSCHAP cestovat volně vzduchem, ale jen obalen TLS nebo nečím podobným...

A porč s eo stále používá, míso too, posílat třeba PAP v TTLS? Jak zaznělo, ne každý klient je tak ohebný, aby něco takového dovolil neo to dovolí třeb jen v itneraktivním režimu, kfežto u toho PEPAPu, to funguje tak nějak samo. Také jsem se hodně dlouho snažil toho zbavit, ale nakonec jsme uznal, že pokud chci mít funkgující 802.1x v síti mximálně univerzálně (pro metalický Ethernet i wifi), ak to jinak asi nepůjde...

[Cek]

JardaP se spíše ptá, jak dlouho je MSCHAP prolomen, než za jak dlouho te hash zlomím.
Nu, samotný Microfot už tak od roku 2000 ne moc nahlas uváděl, že jsou tam jisté slabiny a neměl by MSCHAP cestovat volně vzduchem, ale jen obalen TLS nebo nečím podobným...

A porč s eo stále používá, míso too, posílat třeba PAP v TTLS? Jak zaznělo, ne každý klient je tak ohebný, aby něco takového dovolil neo to dovolí třeb jen v itneraktivním režimu, kfežto u toho PEPAPu, to funguje tak nějak samo. Také jsem se hodně dlouho snažil toho zbavit, ale nakonec jsme uznal, že pokud chci mít funkgující 802.1x v síti mximálně univerzálně (pro metalický Ethernet i wifi), ak to jinak asi nepůjde...

Jsem tolerantni, ale tu kontrolu pravopisu si zapni....tohle louskat je horsi nez svahilstina, ta se aspon da dat do Google translatoru :-)))

[mhepp]

Rád bych upřesnil některé chyby zde uváděné:

AD ověřování klienta: AP se baví jen a pouze se svým nastaveným radius serverem a o dalším nic neví. Tunel je tedy pouze mezi AP a domácím radius serverem. No a pokud na domácí radius server dorazí uživatel z neznámé organizace, tak se obrací na definovaný, nadřazený, který buďto zná příslušnou organizaci, nebo pošle svému nadřazenému. Výsledek ověření pak přijde od nadřazeného.

Ad MSCHAPv2: V rámci eduroam v naší organizaci jsme tuto otázku řešili... A máme dva závěry -- nic lepšího není a ono je to stejně obalené PEAP-em. PEAP obsahuje ochranu pomocí certifikátů, takže se klient nebude bavit s každým. Proto je důležité při konfiguraci 802.1X nastavit radius servery a hlavně správné certifikáty, což třeba na androidu není úplně triviální.

A když jsme u toho, tak MSCHAPv2 je v současnosti rozlousknutelný v podstatě v reálném čase, takže používat nezbalený MSCHAPv2 do TLS/SSL je rovno používání plaintextu. Z tohoto důvodu například nedoporučuji používat PPTP VPN od MS.