Vlákno názorů k článku Krátké vlny: Ministerstvo financí prosazuje nesmysl, internet není krabička cigaret od Uncaught ReferenceError: - uhozené to je, ale tak funguje řada captive...

uhozené to je, ale tak funguje řada captive portálů, prostě ti to zobrazí okno, kde musíš potvrdit podmínky či se přihlásit. Např. wifi v českých drahách.

Tohle ale není mechanismus, který by šel použít pro blokování, protože to zajišťuje router a pouze při připojení, pak nějakou dobu drží session.

OS dostane odpověď a otevře podle svých možností adresu captive portalu v nějakém webview, výchozím prohlížeči.

To zní jako dost uhozený nápad, ale dokážu si představit, že Windows nebo tabletové/smar­tphonové OS (obecně OS založené na premisách "nic jiného než GUI neexistuje" a "Internet = web") by něco takového opravdu provádět mohly. Aspoň je šance, že si v takovém případě uživatel všimne, že se mu otevřelo další okno (případně se to stane ještě předtím, než vůbec zkusí zobrazit nějakou stránku), což by mohlo být trochu varováním.

Máte pravdu asi oba.
To DHCP jsem netušil, ale dává to smysl.

Ale např. iPhone zkouší "captive.apple­.com".

to si asi nerozumíme, captive portal jako option DHCP odpovědi nemá nic společného s podvržením stránky při přístupu na jinou. OS dostane odpověď a otevře podle svých možností adresu captive portalu v nějakém webview, výchozím prohlížeči. To vůbec neznamená, že router na cestě bude dělat MitM na běžný provoz.

Jak už jsem psal, něco takového vyžaduje aktivní spolupráci na straně prohlížeče. Kdyby to dělal jen OS, prohlížeč by měl pořád protestovat proti tomu, že certifikát nesouhlasí s URL. Tak či onak se mi taková představa ani trochu nelíbí, protože taková featura umožňuje šikovnému a vybavenému útočníkovi provést MitM útok způsobem, který půjde snadno přehlédnout.

pozor, adresa captive portálu může být i součástí odpovědi od DHCP, operační systém pak tu stránku otevře a zobrazí captive portál, teprve poté se vytvoří stabilní L2, L3 vrstvy na který běží už internetový provoz.

No, on ten captive portal taky s HTTPS fungovat nemůže, nakonec je jedno, na jaké úrovni se to udělá, pokud mi na pokus navázat HTTPS spojení zkusí někdo hijacknout a podvrhnout mi něco jiného, tak to prohlížeč pozná. Tedy pokud mluvíme o tradičním pojetí toho captive portal, kdy se prostě místo správné stránky zobrazí nějaká od jeho provozovatele. Dnešní prohlížeče ale mají nějakou featuru, kdy se pokoušení tyhle portály detekovat (tak, že zkusí své známé URL a dívají se, co se stane) a vyjít jim vstříc. Já tuhle featuru ale ve Firefoxu zásadně vypínám, protože pravidelně způsobuje, že když zapomenu zapnout připojení, tak i když ho pak zapnu a všechno funguje, prohlížeč dál zarputile trvá na tom, že nejsem připojený, dokud ho neukončím a nepustím znovu.

Rozdil je to pomerne podstatny - captive portal funguje prakticky na L2, kdy se wifi controller rozhoduje na zaklade (ne)znalosti klienta. Zadne sifrovani, zadne rozhodovani na zaklade URL, nic takoveho. Tohle by muselo fungovat na L7 a v ten okamzik do toho hodi vidle prave HTTPS.

Bud by musel ISP podvrhnout obsah webu (a tim rozbije HTTPS a browser rve) nebo by musel podvrhnout presmerovani (a tim rozbije HTTPS a browser rve) nebo by musel na urovni DNS presmerovat domenove jmeno na jinou IP (a tim rozbije HTTPS a browser rve).

Upřímně nevidím tak velký rozdíl mezi tímto a captive portál na wifi které vyžadují přihlášení / zaplacení na příštup k internetu. Nikdo přece neříká že to fyzicky musí vypadat jako něčí doména, stačí to přesměrovat.