Vlákno názorů k článku Komunikace webové aplikace se serverem pomocí Ajax a SSE od tzl - Přijde mi trochu zavádějící (a možná i zbytečné)...

Ono je hlavně absolutně nevhodné připojovat se k embedded zařízení přímo prohlížečem. Tam mají být jenom věci nutné pro funkci toho zařízení a jednoduchou (ale bezpečnou) komunikaci někam ven. Pěkné GUI ovládacího prostředí, kam se budete připojovat prohlížečem, má běžet úplně někde jinde.

Zvlášť když dnes se na takovýhle věci použije appka. Už vidím, jak hledám v záložkách prohlížeče web mého elektroauta, abych ho předehřál/vychla­dil.

Tady nejde ani tak o vykon, jako spis o komplikace. Https je podle me navrzeno naprosto spatne. Neexistuje zpusob, jak by zarizeni mohlo mit platne VEREJNE certificaty. Nemam absolutne nic proti self-signed certifikatum, ale browsery je neakceptuji. Musis se proklikat nekolika varovanimi, abys povolil vyjimku. Pak se pripojis jinym browserem nebo z jineho telefonu a jsi tam, kde jsi byl, zase musis pridavat vyjimky.
Vubec si nedokazu predstavit, jak by se dalo dosahnout toho, aby embeded zarizeni, ktere je za trema NATama, melo certifikat od LetsEncrypt nebo nekoho podobneho. Navic by byla polovina flash zabita jenom staranim se o certifikaty.

7. 11. 2022, 09:04 editováno autorem komentáře

Tak jestli je za 3 NATama, tak se na něj zvenku stejně nedostaneš. Jak píšu výše, tohle se dnes řeší aplikací. I kdyby to byl jen zabalený webový prohlížeč (ale s integrovaným tím self signed certifikátem). Koneckonců obecné prohlížeče jsou na tom stejně, taky maj přibalené certifikáty (těch veřejných autorit).

7. 11. 2022, 10:56 editováno autorem komentáře

Josef Pavlik: Jak byste HTTPS navrhl lépe? To, že prohlížeče vyžadují platné veřejné certifikáty je správně. Chyba je jen to, že DV certifikáty neumí stáhnout z DNS.
Zařízení ve vnitřní síti může mít platné veřejné certifikáty. Měl by to zařizovat „router“ té sítě, stejně jako zařizuje přidělení IP adres a DNS záznamy. (U větších sítí to fyzicky může být jiné zařízení, než router, v SOHO sítích to typicky je jedna krabička.) Že je to zařízení za NATy je chyba, to zařízení má mít IPv6. Ale je to jedno, certifikát pro něj má zajistit router.
Ovšem to samozřejmě platí v případě, kdy je to koncové zařízení něco většího a má to mít vlastní HTTPS server – třeba NAS. Pokud jde o nějaké malé IoT zařízení, to nemá vůbec přímo komunikovat s prohlížečem. To má jen poskytovat data nějakému komplexnějšímu systému, který bude ukládat historii, vyhodnocovat a podobně. To malé zařízení může běžet na baterku, bude mít výkon na to, aby něco jednou za deset minut změřilo a odeslalo, ale je zbytečné takovéhle zařízení trápit HTTPS komunikací s trvale běžícím serverem.

Ja mam na mysli iot zarizeni, ktere ma web intefrace tak akorat na setup, pripadne na to, aby se na nej clovek mohl cas od casu podivat, kdyz je nekde nejaky problem. Za normalnich okolnosti dodava data uplne jinym protokolem nekam na server. Cpat do takoveho zarizeni https by byla zvracenost.
Jak bych https navrhl lepe? Predevsim tak, aby byla oddelena funkce kryptovani komunikace od funkce overeni protistrany. Pri prihlasovani se na iot jsem si (vetsinou) celkem jisty tim, s kym komunikuji. Ale to, ze heslo potom jde viditelne pres http, to se mi moc nelibi. Kdokoliv na siti ho muze wiresharkem odchytit. Ale pro takove zarizeni je vicemene nemozne udrzovat si platny verejny https certifikat. Nemam predstavu, jak by ho dodaval router, o certifikatech mam jenom mlhave predstavy, vim jenom, ze je to pekny bolehlav.

Ja mam na mysli iot zarizeni, ktere ma web intefrace tak akorat na setup, pripadne na to, aby se na nej clovek mohl cas od casu podivat, kdyz je nekde nejaky problem.
Pořád ale není důvod, proč na takové zařízení lézt s běžným prohlížečem.

Predevsim tak, aby byla oddelena funkce kryptovani komunikace od funkce overeni protistrany.
To je ale pro web nepoužitelné. A pokud chce někdo používat protokol určený pro web, musí se přizpůsobit požadavkům toho protokolu. Pokud mu nevyhovují, ať použije jiný protokol. Je nesmysl rozbíjet web kvůli tomu, že se někomu zalíbil protokol, který používá, ale potřeboval by si ho přizpůsobit tak, že by byl pro web nepoužitelný.

Nemam predstavu, jak by ho dodaval router
ACME protokolem, tak, jako to dělá třeba Let's Encrypt. Akorát by router nevystavil ten certifikát sám, ale zajistil by jeho vystavení u LE.

Proč na to zařízení lézt přes prohlížeč? Protože je to nejjednodušší řešení bez dalších závislostí, a dělá se to tak už desítky let!

Proč na to zařízení lézt přes prohlížeč? Protože je to nejjednodušší řešení bez dalších závislostí, a dělá se to tak už desítky let!
Desítky let se to nedělá, před dvaceti lety se na to běžně používaly specializované aplikace, byť se startovaly z prohlížeče (různé Active.X, Java Applety apod.). No a hlavně pokud chce někdo využít prohlížeč, tak musí splňovat požadavky, které prohlížeče mají – tj. HTTPS, aktuální verze TLS, důvěryhodné certifikáty atd. Pokud je to pro vás pořád nejjednodušší řešení, pak to tak klidně dělejte.

Specializovane aplikace jsou metla lidstva. Predstav si, ze mas router, ktery si uz 5-10 let vesele routuje. Ted potrebujes neco zmenit v konfiguraci. Spojis se na nej (pres http), vzpomenes si na heslo, prihlasis se a udelas co je potreba.
Pokud by na to byla potreba specialni aplikace, kde ji ted po 5-10 letech budes hledat? Na kterem computeru jsi ji mel nainstalovanou? Odkud se da stahnout (nezapomen, nefunguje ti router), protoze ten computer je uz nekde vyhozeny? Nebo proste ten windows xp nebootne, tak z nej linuxem bootnutym z druhe partition tahas ten blbej program, co se neda nikde stahnout, abys ho nainstaloval na jiny windows, ktery jeste bootuje (osobni zkusenosti).
Jestlize to bude neco jako java applet, je hodne pravdepodobne, ze to skonci s "unhandled java exception #123456, protoze tvoje dnesni verze javy neni kompatibilni s tehdejsi javou. To je bolehlav. Pokud to bude activex, bude to jeste lepsi, kde ti to pojede?
Takze NASTESTI naprosta vetsina zarizeni maji pristup pres normalni http a i prestoze je to nebezpecne, nejak se na to dostanes i po 10 letech.
Desim se okamziku, kdy vsechny browsery ve tvem vlastnim zajmu uplne zakazou http a budou vyzadovat https s platnym verejnym certifikatem (nezapomenme na certifikaty, kterym treba propadne platnoust nebo upadnou v nemilost a browsery, jeden jako druhy, je nebudou akceptovat.

Josef Pavlik: Myslíte si, že 5–10 let staré webové rozhraní toho zařízení bude nějaká výhra? Poběží to v konkrétní verzi Internet Exploreru, nebo ve starých verzích Chrome, protože to používá nějaké tehdy experimentální API, které je dnes už finální a funguje jinak. Nějaké soubory rozhraní to bude stahovat z už neexistujícího webu a server bude podporovat maximálně SSLv3.

Ale i ta komunikace se zařízením se dá udělat ve webovém prohlížeči, bez proprietární aplikace a bezpečně. Samotnou webovou aplikaci můžete dostat jako statické soubory, které dáte na libovolný web server (nebo to provozuje výrobce toho zařízení). Zařízení může vystavit API přes HTTP, a mezi prohlížeč a to zařízení dáte proxy server, který bude univerzální pro všechna zařízení, na jednu stranu bude s prohlížečem komunikovat přes bezpečné HTTPS a na druhou stranu může komunikovat s tím zařízením klidně po HTTP. Ta zařízení (spolu se „zadní“ stranou toho proxy serveru) pak mohou být v oddělené síti, kam se nikdo jiný nedostane.

Takže řešitelné to je, akorát je to holt trochu víc práce. Ale jinak to nepůjde – je bláhové myslet si, že celý svět bude používat web nebezpečným způsobem jenom proto, že vy se chcete připojovat k bezdrátovému teploměru bezpracně.

Ted jsi popsal naprosto presne zpusob, jakym delame pristup na nase zarizeni :-) :-) :-).
Mame server, na ktery se klient pripojuje pres https. Tento server nedela nic jineho, nez reverse proxy na nase zarizeni po http, ovsem po kryptovane vpn. Certifikaty udrzujeme jenom na jednom miste, vsechno ostatni jede pres stary dobry http, protoze nektere z techto zarizeni bezi na 20 let starem hardware a stejne tak stare verzi Connectiva, coz je odnoz Redhat, radove tak Redhat 8. Zapomen na https, to v te dobe sice asi uz existovalo, ale nejsou tam kompatibilni knihovny, ktere by byly schopny delat SSL kompatibilni s dneskem. Uz jenom dostat se na to pres ssh je komplikovane, musis mit nastavene optiony, ze povolujes historicke zpusoby kryptovani :-). Tohle se ovsem tyka pouze urcitych specialnich extra funkci, zarizeni jako takove jede i offline. Tento system resi hlavne problem zarizeni, ktere je za trema NATama.
Ovsem reknni klientovi, ze si ma koupit novy hardware. Uvidis, kam te posle. Zvlast dnes, kdy koupit novy hardware je skoro jak za komunismu. Jak zpivaval Kryl "K shaneni ma cas jen ten, co marodi".

Jeste se vratim k zarizeni pripojitelne pouze pres nejaky server nejakeho obskurniho vyrobce. Pokud ten cinan mezitim zkrachoval a server uz nejede, mas smulu, uz se na svoje zarizeni nedostanes. Takze tohle taky neni rozumna cesta.

Samozřejmě nejste jediní, kdo to tak dělá. Nejvíc v tom samozřejmě jedou Google, Amazon a Apple se svými domácími asistenty. S jednou drobnou odlišností – oni to uživateli nezpřístupňují přes zdokumentované otevřené rozhraní přes HTTPS, ale skrze svůj proprietární cloud. Nicméně účelem je to samé. Ostatní mají na výběr dvě možnosti – buď to pozorovat, smát se jim, jak to dělají blbě a za pár let se zase divit, že mají oligopol v další oblasti. A nebo se dohodnout na standardu, který budou moci implementovat domácí routery a z druhé strany ta IoT zařízení. Tak, aby router zařízení nově připojenému do sítě (po odsouhlasení majitelem) nejen přidělil IP adresu, ale také zaregistroval veřejný DNS název a zprostředkoval k němu vydání certifikátu (pro nadupanější zařízení typu NAS) nebo zprostředkoval komunikaci skrz vlastní proxy server (pro IoT zařízení typu okenní kontakt). Protokoly na to existují, jde jenom o doladění toho, jak se mají konkrétně používat.

Lip bych to nenapsal :-)

Jeste jsem zapomnel - nektere access pointy NEMAJI HTTP(S) INTERFACE. Konfigujuji se nejakym naprosto silenym zpusobem nejak pres cloud. Flashujeme do nich openwrt, aby to bylo udrzovatelne.

Nemel jsem to ani vzpomenout. Zrovna dnes se tady uz od rana se**me zrovna s timto shitoznim access pointem. Nekde neco zmenili, nedari se ho upgradnout pracne pripravenyma scriptama. Bylo nutno nainstalovat ten jejich shitozni 'Unifi network', coz je monstrozni uzavrena aplikace, nechci ani vedet jaky bordel mi dela v systemu. Je to napsane v jave, ma to asi 160M, bezi to jako daemon, na ktery se pres web interface pripojis a pak konfigurujes access point. Kdyz uz chteli delat monstrozni web aplikaci, proc ji nedali primo do toho access pointu bez nutnosti instalovat pochybne programy a registrovat se na jeste pochybnejsich sitech. A stejne to nejde upgradnout ani takhle. Celkovy zaver je takovy, ze asi budeme muset vyhodit 5 uplne novych access pointu, protoze s originalnim firmware nejsou k nicemu a ubyquyty od tohoto okamziku nechci az do smrti videt.
Mimochodem, pripojujes se na to pres https nemaji tam ani platny certifikat, musis presvedcit firefox, ze jim veris a ze ma pouzit tento neduveryhodny certifikat. Jak mam neco takoveho udelat, kdyz jim neverim?

15. 11. 2022, 14:36 editováno autorem komentáře