Fórum Root.cz
Hlavní témata => Server => Téma založeno: redustin 11. 03. 2025, 09:11:01
-
V návaznosti na vypršený certifikát v chromecast audio... jak se vlastně taková situace plánuje řešit v embedded? Prohlížeče míří k zákazu non-SSL komunikace vs. trend zkracování max. akceptovaných platností certifikátů.
Zcela konkrétně mě zajímá varianta USB device s kompozitním USB - např. audio + ethernet s local name (avahi) pro pohodlné ovládání browserem. Jak to do budoucna bude s browsery + certifikáty pro takové local-only řešení? Budou browsery akceptovat .local adresy bez SSL? Díky moc za názory.
-
Nijak. Budou končit M$ certifikáty pro Secure Boot. Problém neřešitelný, ta zařízení nikdo neopraví (až skončí i ten KEK, tak ani při hypotetické spolupráci výrobce). Ale hlavně, že to je super bezpečné.
https://neodyme.io/en/blog/bitlocker_why_no_fix/#secure-boot-certificates
-
Díky, zajímavé čtení, to vypadá na veliké radosti příští rok. Přijde mi, že pro tyhle případy s očekávatelnou dlouhodobou životností není PKI se záměrně omezenou platností klíčových prvků nejvhodnější technologie.
Tak možná, že nemusím řešit embedded zařízení, když je za rok nebude k čemu připojit :-)
Nicméně co se týče těch embedded zařízení - jaké jsou trendy? Vždyť to musí řešit i automotive a průmysl, kde jsou očekávané životnosti podstatně delší, než v consumer IT.
-
Neslyšel jsem zatím, že by se zkracování platnosti mělo týkat kořenových certifikátů.
-
Díky, zajímavé čtení, to vypadá na veliké radosti příští rok.
Neboj, M$ má jednoduchý návod (https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d), jen musíš několikrát upravit registry, povrtat se ručně v EFI oddílu a mezi každým krokem nejméně dvakrát rebootovat. Po absolvování této procedury pak můžeš trávit dlouhé zimní večery úpravou veškerých bootovacích médií.
Nicméně co se týče těch embedded zařízení - jaké jsou trendy? Vždyť to musí řešit i automotive a průmysl, kde jsou očekávané životnosti podstatně delší, než v consumer IT.
Asi ne. To, co jsem nalinkoval, je přece úplně to první, co člověka napadne, než podobnou technologii začne někam zavádět. Jak se to bude aktualizovat / revokovat, jak to jde automatizovat, co se stane, až ty certifikáty expirují. Ale evidentně to nikdo neřešil ani v horizontu nějakých směšných 15 let.
Notoricky se nadává např. na zoufale děravá zařízení ve zdravotnictví, ale to je zjevně furt lepší, než potenciální kolaps zdravotní péče, pokud by se tam začaly implementovat podobné absolutně nedomyšlené "vynálezy".
Šílenost, toto.
Neslyšel jsem zatím, že by se zkracování platnosti mělo týkat kořenových certifikátů.
Ale ty kořenové certifikáty také mají omezenou platnost, a např. v případě toho zmíněného Secure Bootu a bordelu kolem je asi za minutu dvanáct, a řešení žádné.
-
Notoricky se nadává např. na zoufale děravá zařízení ve zdravotnictví, ale to je zjevně furt lepší, než potenciální kolaps zdravotní péče, pokud by se tam začaly implementovat podobné absolutně nedomyšlené "vynálezy".
Tohle já jsem nepochopil, proč je vlastně problém. Nemocnice je velká organizace s vlastní IT, ty zařízení potřebují jen málokdy někam lézt, a do internetu už vůbec. Vždyť je to řešitelné na úrovni struktury sítě, a pravidel, zařízení, které používá exatkně své dva porty klidně na separátním VLANu nikdo moc nebude schopen napadnout/zneužít.
-
Dobře, ale co konkrétně pro ten browser jako ovládací rozhraní embedded zařízení? Plain HTTP a spoléhat se, že browsery to budou nějak rozumně podporovat do budoucna? Lokální self-signed certifikáty a nabízet postup pro přidání CA certifikátu do browseru, nebo spoléhat, že browsery budou podporovat "odškrtnutí" neznámého certifikátu? Jaké jsou vlastně "next-to-best" practices v této oblasti?
Jedná se i o mobilní browsery pro přístup na consumer embedded zařízení na lokální síti, ale tam by se dal předpokládat přístup na internet, takže by si zařízení mohlo samo generovat třeba LE certifikáty (dokud LE bude fungovat...)
-
Tohle já jsem nepochopil, proč je vlastně problém.
Tady jeden z příkladů. Fakt to není tak jednoduché, jako že "dám tam firewall".
https://unit42.paloaltonetworks.com/infusion-pump-vulnerabilities/
Plain HTTP a spoléhat se, že browsery to budou nějak rozumně podporovat do budoucna?
Nebudou. Už dnes problém, viz nedávná zprávička o HTTPS first apod.
Lokální self-signed certifikáty a nabízet postup pro přidání CA certifikátu do browseru, nebo spoléhat, že browsery budou podporovat "odškrtnutí" neznámého certifikátu? Jaké jsou vlastně "next-to-best" practices v této oblasti?
To bohužel taky problém neřeší. Krom certifikátů např. již dnes máme reálný problém s nepodporou TLS 1.2+ ve firmwaru těch zařízení a likvidací podpory starších verzí v prohlížečích, knihovnách, operačních systémech. Takže za reverzní proxy a dál pěkně HTTP. No, než podpora HTTP z té proxy taky zmizí. ::) :-X
-
Takže za reverzní proxy a dál pěkně HTTP. No, než podpora HTTP z té proxy taky zmizí. ::) :-X
Bohužel reverzní proxy se blbě dává mezi PC a USB zařízení s USB-ethernetem.
-
Řeší se interní CA. Ale občas ne jednou, protože řada věcí ani nerozdýchá certifikáty s SHA256 a spokojeně si mrzne v době MD5/SHA1 a podobné...
Jinak se řeší izolací, k tomu je virtuál s něčím jako Win7 a starší a v něm dostatečně starý prohlížeč. Což je také cesta, jak udržet některé takovéto stařešiny v provozu. Jsem zvědav, zda se dožiju vyhlazení Windows NT4.0 z mého středně vzdáleného technologického okolí. :-)
-
Takže za reverzní proxy a dál pěkně HTTP. No, než podpora HTTP z té proxy taky zmizí. ::) :-X
Bohužel reverzní proxy se blbě dává mezi PC a USB zařízení s USB-ethernetem.
Proč by se to dávalo blbě? Jen musí běžet na tom PC, aby člověk nemusel řešit routování.
-
Řeší se interní CA.
Díky. A jak s tím zkracováním akceptované délky platnosti certifikátů? Je nějaký standard pro vydávání certifikátů interní CA (něco jako ACME), který by se běžně na embedded zařízeních používal - tedy něco jako že se zadá jen název stroje s interní CA a ono si to už bude o certifikáty žádat samo, pomocí standardního protokolu, všechny "krabičky" stejným způsobem?
-
[Proč by se to dávalo blbě? Jen musí běžet na tom PC, aby člověk nemusel řešit routování.
Jasně že to technicky lze. Ale kouzlo ovládání USB zařízení přes jeho interní HTTP server je v tom, že není potřeba nic instalovat na hostitele (v případě standardního USB protokolu ani žádný driver), na kompletní ovládání v GUI stačí browser (navíc z principu multiplatformní). Takhle by to místo multiplatformní appky vyžadovalo reverzní proxy.
Vlastně ta proxy by také potřebovala funkční certifikát, ne? Takže by se starost s certifikátem přenesla z "krabičky" do proxy běžící na hostiteli, to by asi moc neřešilo.
-
Netvrdím, že je to ideální. Jen oponuji, že "Bohužel reverzní proxy se blbě dává mezi PC a USB zařízení s USB-ethernetem." není úplně pravda, když stačí pustit jednoduchou službu. Rozchodit Nginx-proxy není těžké, a jak to začne být potřeba pro ty USB věci, nejspíš se rozšíří i nějaký tool, co to zabalí do klikátka i s generováním certifikátu a instalací do systému.
Nicméně pokud jste se v poslední době divili, proč SOHO výrobci tolik cpou svoje aplikace, no, tohle je ten důvod. Korporát dokáže obrátit jakoukoliv situaci ve svůj prospěch, a tlak na větší bezpečnost není výjimkou. Většině uživatelů to bude fungovat bez nutnosti řešit něco dalšího, stačí jejich appka, a jako bonus mají větší sledování.
-
Co kdyby to USB zařízení (např. po stisku tlačítka) vyexportovalo svůj interní CA certifikát přes mass storage - to by standardní OS mohl po "rozkliknutí" certifikátu ve správci souborů jeho import do svého skladu certifikátů CA, ne? A pak už by si zařízení jen pravidelně generovalo nový HTTPS certifikát samo.
Samozřejmě by to neřešilo zastarávání šifer, ale to by při použití nejnovějších šifer v době instalace mohlo (hodně) pár let vydržet.
Jde mi o cestu, jak to udělat pro uživatele co nejjednodušší, bez potřeby vývoje a údržby multiplatformní ovládací aplikace.
-
Rozchodit Nginx-proxy není těžké, a jak to začne být potřeba pro ty USB věci, nejspíš se rozšíří i nějaký tool, co to zabalí do klikátka i s generováním certifikátu a instalací do systému.
Není to těžké, ale obávám se, že instalace third-party proxy není pro běžného uživatele reálná, bude se logicky ptát, proč tak složitě, proč nemá krabička ovládací aplikaci.
Ono USB krabiček s takhle složitou prací s USB zatím moc není, protože je USB gadget v linuxu poměrně nová méně známá technologie (samozřejmě kromě Androidu) a psát celou takovou podporu v nějakém mikrokontroléru mi přijde dost složité.
-
Doporucuju obcas navstivit nejakou fabriku, kde se pouzivaji embedded devices a proskenovat si to tam.
Resp. "podivat" se na SW, ktery s nima komunikuje.
Security through obscurity v 99% pripadu a naprosto deravy jak cednik.
Nejaky certifikaty, to je tresnicka na dortu.
Respekt vsem ostatnim, kde se ta bezpecnost opravdu resi.
-
Řeší se interní CA.
Díky. A jak s tím zkracováním akceptované délky platnosti certifikátů? Je nějaký standard pro vydávání certifikátů interní CA (něco jako ACME), který by se běžně na embedded zařízeních používal - tedy něco jako že se zadá jen název stroje s interní CA a ono si to už bude o certifikáty žádat samo, pomocí standardního protokolu, všechny "krabičky" stejným způsobem?
Zkracování se týká těch veřejných CA. Pokud si udělám vlastní privátní CA a naimportuji do prohlížeče/OS, tak stále ve Firefoxu, Chrome, Edge jedou dlouhé doby platnosti. Jen Safari to řeže a odmítá certy s platností nad 2 roky (nad cca 384 dní). Chrom na jabkách to také nějakou dobu takto dělal, co používal OS validátor, ale asi to už opravili.
Tohle je ale řešení pro firmu a interní/technologické systémy. Pro veřejnost ne.
Protokolů je několik, včetně historického SCEP, ale z pohledu embedded světa to skoro nic neumí. U řady ani nejde ručně vyměnit to, co tma je od výrobce/samo si vygenerovalo při zapnutí. V řadě případů u nejrůznějších technologických embedded krabic, tak i u nových, je HTTPS stále sprosté slovo. Nebo zapnutí HTTPS tu krabici totálně odvaří, protože je v tom CPU, co to nedává. Třeba si hraju teď s analyzátorem plynů, bedna za XX MKč, má to web, po zapnutí HTTPS přestane půlka věcí fungovat a přihlášení trvá cca 10 minut, proti pár vteřinám na HTTP a ve většině případů to skončí timeoutem. Něco, že by šlo třeba změnit default heslo, tak to je z říše snů.... To je ta technologicko/výrobní realita zmiňovaná o příspěvek výše. :-)
-
Rozchodit Nginx-proxy není těžké, a jak to začne být potřeba pro ty USB věci, nejspíš se rozšíří i nějaký tool, co to zabalí do klikátka i s generováním certifikátu a instalací do systému.
Není to těžké, ale obávám se, že instalace third-party proxy není pro běžného uživatele reálná, bude se logicky ptát, proč tak složitě, proč nemá krabička ovládací aplikaci.
Ono USB krabiček s takhle složitou prací s USB zatím moc není, protože je USB gadget v linuxu poměrně nová méně známá technologie (samozřejmě kromě Androidu) a psát celou takovou podporu v nějakém mikrokontroléru mi přijde dost složité.
Právě, že to ani tak složité není.
-
Len jedna ukazka, co je realne, ked sa niekto snazi: https://hackaday.io/project/186999-canique-pico-gateway
vybrane tls 1.2 algoritmy a cca 1.2 sekundy na nadviazanie tls spojenia... Ked clovek nevybera a ide nahodne, tak sa kludne moze dostat na timeout pri 125 MHz mcu. Vid https://forums.raspberrypi.com/viewtopic.php?t=362979 kde spominaju 9 az 12 sekund na nadviazanie spojenia.
Inak povedane, chce to nejake usilie na strane navrhu/vyvojara a tls (https) je zvacsa to posledne, co sa pri produkte riesi. Preto to vypada tak, ako to vypada. Plus ak chcem platny certifikat na domacej sieti (platny = pride na navstevu sused a pojde to aj jemu na mobile bez pridavania vlastneho certifikatu), tak musim vlastnit nejaku verejnu domenu. Aspon nijak inak si neviem predstavit, ze si vydam platny certifikat... Mozno existuje na to aj sluzba, co rozdava certifikaty na domeny ako ujoKarolZPlzne.domaceCertifikaty.root.cz a podobne.
-
Děkuji všem moc za dosavadní diskusi.
Zkoušel jsem importovat CA certifikát z .crt souboru (který by byl vygenerovaný na krabičce -> USB mass storage disk), ve windows s tím nebyly žádné problémy, ani do Trusted Root Certification Authorities storu. To by zvládl i laik.
Takový kořenový certifikát s plnými možnostmi podepisování by byl z hlediska bezpečnosti neakceptovatelný. Nicméně zdá se, že by již měla fungovat možnost omezit jeho podepisování pouze na konkrétní domény - viz https://security.stackexchange.com/questions/31376/can-i-restrict-a-certification-authority-to-signing-certain-domains-only . To mi přijde už jako rozumné řešení - uživatel by si jednoduše naimportoval CA kořenový certifikát, který by směl podepisovat pouze doménu .local , tedy jen pro zeroconf/mDNS přístupy. Nic víc bych pro tento účel asi nepotřeboval.
-
Ono se zřejmě dá, provozovat si privátní CA s podporou ACME v roli serveru (https://smallstep.com/blog/private-acme-server/). Zřejmě horší problém je, do embedded krabiček dostat certbot (https://certbot.eff.org/) klienta nebo něco podobného. Bezpečnostní cirkus je důmyslná soustava navzájem zaklesnutých bludných kruhů... :-( Ustřelit si omylem nohu je snazší než kdy dřív...
-
Díky. V mém případě by krabička byla plně pod mou kontrolou, tudíž by mohla dělat cokoliv. Jen přesvědčit browser, aby byl (i za pár let) ochoten si s ní povídat :-) Bez instalace nějaké další služby na síti a v ideálním případě i bez instalace čehokoliv dalšího (third-party) na připojeném PC s browserem.
-
Nevím o tom, že by prohlížeče měly v dohledné době zakázat plain HTTP. Ale jo, už dnes omezují některé technologie bez HTTPS.
Pokud jde o USB, nabízí se WebUSB. Ale na iPadu a iPhone mají uživatelé smůlu.
-
Nevím o tom, že by prohlížeče měly v dohledné době zakázat plain HTTP. Ale jo, už dnes omezují některé technologie bez HTTPS.
Tomu trochu nerozumím - pokud se omezí technologie bez HTTPS, omezí se tedy HTTP. HTTPS-first je právě o tom - výrazná varování pokud komunikace nejede přes HTTPS (tedy jede přes plain HTTP). A HTTPS vyžaduje platný certifikát, jinak další výrazné varování (či výhledově rovnou odmítnutí natvrdo bez jiné varianty).
Pokud jde o USB, nabízí se WebUSB. Ale na iPadu a iPhone mají uživatelé smůlu.
IIUC WebUSB je o zajištění přístupu na USB protokoly přes web/HTTP. To v mém případě není potřeba, zařízení jsou lokální a mají normální drivery v OS hostitele. Není potřeba na USB funkce přistupovat vzdáleně přes web. Ale je z hostitele potřeba přistoupit v prohlížeči na webový server běžící na USB zařízení.
-
Nevím o tom, že by prohlížeče měly v dohledné době zakázat plain HTTP. Ale jo, už dnes omezují některé technologie bez HTTPS.
Tomu trochu nerozumím - pokud se omezí technologie bez HTTPS, omezí se tedy HTTP. HTTPS-first je právě o tom
Podle situace možná stačí, když bude v prohlížečích pořád nějaká unsafe volba "považuj tenhle zdroj za důvěryhodný."
Na jeden resource v lokální domácí síti, který je běží na http, ale poskytuje nějaké https-only funkce (třeba clipboard access) to používám, akorát mi pak prohlížeč vyhazuje warning při každém spuštění, že je to zapnuté. Na druhou stranu, restartuju typicky jen jednou týdně. Ale asi to není něco, co bych chtěl učit svou tetičku, a není zaručené, že to bude takhle fungovat i za pět let.
-
Omezení není zákaz. Pokud jde o jednoduché věci, hádám, že ta omezení nebudou překážkou.
WebUSB není o HTTP, ale API k USB přes JS.
-
Omezení není zákaz. Pokud jde o jednoduché věci, hádám, že ta omezení nebudou překážkou.
Díky. Co konkrétně znamená "jednoduché věci"? Nejde mi o nic složitějšího, než standardní HTML + JS přes HTTP, tedy normální webové ovládací rozhraní pro zařízení. To je ale hlavní funkce prohlížeče - jednoduché nebo už složité, půjde HTTP?
WebUSB není o HTTP, ale API k USB přes JS.
Jasně, ale tohle zjednodušené userspace libusb přes JS by znamenalo, že by člověk musel psát celou podporu daného USB funkce (např. zvukovky nebo mass storage) a současně napsal komplet používající software v JS, pro běh v prohlížeči. Cílem je naopak využít stávající systémové drivery pro jednotlivé USB funkce/třídy a stávající aplikace (např. audio analyzátor používající audio API daného OS) a v prohlížeči mít ovládací GUI zařízení, pro které se standardně programuje OS-specific ovládací GUI (tj. všechny starosti související s nativní aplikací, různé pro různé OS atd.)
A nebo by se WebUSB hodilo pro jednoduché ovládání třeba přes USB HID - místo tahání webového rozhraní z krabičky přes virtuální USB síťové rozhraní mít v prohlížeči lokální SPA a v ní komunikovat s krabičkou třeba přes USB HID. Pro jednodušší věci by to asi šlo. Ale jednodušší je mít rovnou na zařízení webový server, protože na ten by se mohlo přistupovat i rovnou po síti, pokud by měla USB krabička reálné síťové rozhraní (mluvím o ARMu s plnohodnotným linuxem, které ethernet/wifi běžně také mají).
Bohužel je WebUSB nová a málo podporovaná technologie, to by bylo spíš pro nějaký proof of concept. Ale dobré vědět, může se někdy hodit, díky.
-
Ještě koukám na to WebUSB. Pokud připojím USB zařízení bez další konfigurace OS, na všechny jeho standardní funkce se napojí systémové ovladače a předpokládám, že se na ně libusb/WebUSB nedostane. To by vyžadovalo blacklist zařízení v OS, což už je pro uživatele veliká komplikace. Možná proto Chrome v dokumentaci k extenzi WebUSB píše "The WebUSB API exposes non-standard Universal Serial Bus (USB) compatible devices to the web".
WebHID je zatím v plenkách https://developer.mozilla.org/en-US/docs/Web/API/WebHID_API#browser_compatibility . U přístupu na HID přes browser píše Mozilla https://developer.mozilla.org/en-US/docs/Web/API/HID "This feature is available only in secure contexts (HTTPS)" - jak se vlastně dostane lokální SPA do secure contextu?
-
HTTPS-only – z hlavy nevím, zkoušel jsem hledat ucelený seznam a našel jsem 7 let starý článek: https://www.digicert.com/blog/https-only-features-in-browsers
Na druhou stranu, pro big picture to může stačit. Tuším, že typicky tam přibývají nové featury, ale neobjevují se tam staré, které dříve fungovaly i přes plain HTTP.
Když nad tím přemýšlím, spuštění webového serveru na USB mi nepřijde jako až tak super koncepční řešení:
1. IP adresa se může krýt s něčím v místní síti apod.
2. Pokud to USB zařízení není připojeno 24/7 a počítač se připojuje i do nedůvěryhodných sítí, může útočník mít webový server na stejné IP adrese a portu jako má to USB zařízení administraci. V tu chvíli sice nemá přímý přístup k zařízení, ale může například otrávit cache, a k zařízení přistoupit později.
3. K zařízení dostane přístup každý uživatel ve víceuživatelském prostředí. Reálně jde spíše o různé sandboxy než skutečné uživatele.
4. S trochou nepozornosti (neověřování hlavičky Host) k tomu má přístup každý skrze DNS rebinding. Byť toto je zrovna řešitelný problém.
U WebUSB není nutné implementovat celý driver, stačí jen driver na to, s čím ta stránka má interagovat, tedy zřejmě s nastavením. V podstatě jde jen o ty věci, kde byste u webového rozhraní dělal endpoint.
WebHID mi přijde víc high-level než WebUSB, a IMHO to má fungovat se vstupními zařízeními jako klávesnice a myš. Pro nastavování bych spíše použil WebUSB.
-
Podle situace možná stačí, když bude v prohlížečích pořád nějaká unsafe volba "považuj tenhle zdroj za důvěryhodný."
Ty nedelas nikde v administraci IT ze? Tohle nestaci uz davno.
Mam trebas pod spravou veci, ktery pouzivaji flash. Do kteryho aktualniho browseru si nainstaluju flash? Nebo se kterym aktualnim browserem, bude fungovat nejaka ta 5tkova java?
Takze mam nekolik systemu ruzneho stari a v kazdym nekolik ruznych browseru ruzneho stari, aby se k tem vecem vubec nejak dalo dostat. Vcetne napr win XP + IE.
Jeste tak nejsvepravnejsi je v tomhle ohledu palemoon, kde si muzu povolit ruzne "nebezpecne" sifry, ale ani v nem nefunguje zdaleka vse.
Az se guugl prohlasi, ze zille neda prachy pokud nezrusi http, tak bude zruseny lusknutim prstu.
-
Když nad tím přemýšlím, spuštění webového serveru na USB mi nepřijde jako až tak super koncepční řešení:
Ta IP kolize v 1. není až takový problém, pokud jde tu IPadresu změnit. Prostě podobná situace, jako u veškerého wifi IOT s AP mode pro první nastavení.
A ten zbytek... No, tam záleží, jak moc zajímavý cíl to je. Například amatérský osciloskop do USB, který má webový frontent místo instalování nějaké aplikace do systému, mi zní jako krásné využití tohohle systému. A ani úspěšný útok nemá moc co udělat jiného, než si to bricknout, nebo si v tom zařízení udělat bezpečnou enklávu pro znovu-šíření. Jasně, pokud by to ovládalo nějaké čerpadlo v rafinerii, nebo dvoutunového robota ve fabrice, tak to může udělat o dost víc škody, ale... Tak nějak pochybuju, že tam budou mít tyhlety moderní vymyšlenosti, co tady řešíme. Ovládací software dostupný jen pro WinXP je v těch kruzích pořád v módě. ;D
Podle situace možná stačí, když bude v prohlížečích pořád nějaká unsafe volba "považuj tenhle zdroj za důvěryhodný."
Ty nedelas nikde v administraci IT ze? Tohle nestaci uz davno.
Řešil jsem specificky situaci "funkcionalita je podmíněna použitím HTTPS," jako nějaké webgl nebo clipboard věci, a navrhl to jako self-help alternativu k pouštění lokální proxy, ne snahu držet naživu zařízení s ovládáním přes Flash. ::)
-
Wi-Fi AP mode pro první nastavení je vlastně dobré přirovnání, to je podobné ohnutí nějaké technologie k úplně jinému účelu, s podobnými dopady. Dokonce typicky ještě o něco horší, protože to typicky znamená, že se musím odpojit od sítě, zatímco u USB jen přibyde nová síť.
Kolize většinou není problém, ale když je, je to opruz. Změnit nastavení – ale prvně se tam potřebujete dostat. Jo, odpojíte druhou síť, a pak to půjde.
A k bezpečnosti: Samozřejmě záleží na zařízení i na jeho použití. Já hlavně chtěl vyvrátit představu, že když je to po kabelu, který mám pod kontrolou, tak je plain HTTP v pohodě. Jo, pasivní odposlech tam nehrozí, ale jiné scénáře jako cache poisoning ano.
-
Ještě koukám na to WebUSB. Pokud připojím USB zařízení bez další konfigurace OS, na všechny jeho standardní funkce se napojí systémové ovladače a předpokládám, že se na ně libusb/WebUSB nedostane. To by vyžadovalo blacklist zařízení v OS, což už je pro uživatele veliká komplikace. Možná proto Chrome v dokumentaci k extenzi WebUSB píše "The WebUSB API exposes non-standard Universal Serial Bus (USB) compatible devices to the web".
WebHID je zatím v plenkách https://developer.mozilla.org/en-US/docs/Web/API/WebHID_API#browser_compatibility . U přístupu na HID přes browser píše Mozilla https://developer.mozilla.org/en-US/docs/Web/API/HID "This feature is available only in secure contexts (HTTPS)" - jak se vlastně dostane lokální SPA do secure contextu?
Jo, tohle mi přišlo jako vcelku dobrý nápad. Speciálně právě pro lokální administraci různých zařízení a gadgetů.
Není to zdaleka tak nové, registruju to minimálně 8 let. Největší praktický problém je v tom, že je to v podstatě aktivita od Google. Takže jejich produkty to sice podporují už hodně dlouho, ale v podstatě nikdo jiný.
Na Andoridu, ChromeOS to chodí v pohodě, do PC, macOSu nebo Linuxu si člověk doinstaluje jakýkoliv Chromium based prohlížeč, pokud už ho tam rovnou nemá. Ale není cesta, jak to rozchodit na iOSu (což je pořád tak čtvrtina uživatelů na mobilních patformách).
Ten myšlený use case mi přišel tak, že místo toho, aby výrobce gadgetu dělal nativní aplikaci pro x různých platforem, tak udělá webovou administrační aplikaci s JS na svém webu, aktualizuje jí podle potřeby (bez koleček schvalování, publikování na storech) a když si uživatel ten web otevře, a povolí přístup, tak může ovládat gadget.
Takže není to off-line, ale to myslím, nebyl ten hlavní point. Pokud je to nějaký otevřený projekt, může to plácnout třeba na GitHub Pages - github.io a propojit do hlavního projektu, kde jsou pak zdrojáky. O HTTPS se pak nemusí starat.
HID zařízení (BaseClass - 03h) s nějakou šikovně vybranou podřídou, aby se to v systému nechytalo jako standardní vstupní zařízení (tzn. dostupné pro custom ovladač, nebo třeba WebHID), se vcelku běžně používají. Jak pro nějaká vstupní ovládací zařízení (pady, joysticky, tlačítkové panely), tak i třeba ovládání USB zvukovek (pokud to nejsou zrovna ovládací prvky, co chce výrobce namapovat do standardní audio třídy). Oproti těm některým ostatním základním třídám, které rovnou vyžadují samostatný ovladač, to má výhodu v tom, že to nikde v systému (Win) nevisí jako neznámé zařízení a jsou už definované základní parametry inicializace, komunikace co používá interrupt transfery s nízkou latencí.
Zas samozřejmě pokud by bylo potřeba přenášet nějaké kýble dat pomocí bulk nebo iso transferů, tak to není úplně nejvhodnější. Proto tam taky často bývá třeba další endpoint vyloženě s DFU třídou pro update firmware.
Jinak, neříkám, že je to pro konkrétní použití (co neznám) úplně nejvhodnější, jestli je tam nějaký silnější SBC, co už má Ethernet, tak se vyloženě nabízí to využít. Protože přístup z více zařízení, i přes WiFi atd. I když tam samozřejmě můžou přijít zmíněné komplikace s certifikáty atp.
Jen jsem chtěl zmínit na co ta USB JS API asi byla původě míněná.
-
1. IP adresa se může krýt s něčím v místní síti apod.
Přes USB jsou to link-local adresy 224.0.0.0/24, tj. v jiném segmentu, než zbytek místní sítě. Tam bych se konfliktu nebál. Vzdálený přístup na takovou adresu by vyžadoval NAT a routování, což už je věc uživatele (tj. extrémně nepravděpodobné).
-
Ten myšlený use case mi přišel tak, že místo toho, aby výrobce gadgetu dělal nativní aplikaci pro x různých platforem, tak udělá webovou administrační aplikaci s JS na svém webu, aktualizuje jí podle potřeby (bez koleček schvalování, publikování na storech) a když si uživatel ten web otevře, a povolí přístup, tak může ovládat gadget.
Takže není to off-line, ale to myslím, nebyl ten hlavní point. Pokud je to nějaký otevřený projekt, může to plácnout třeba na GitHub Pages - github.io a propojit do hlavního projektu, kde jsou pak zdrojáky. O HTTPS se pak nemusí starat.
Jo, to by bylo hezké řešení. Na github dát aplikaci (tam by mohla vydržet spoustu let bez údržby) a komunikovat přes nějaké HID webusb. Bohužel podpora v prohlížečích je taková, jaká je... tedy nepoužitelné.
Pořád mi nejlépe vychází to webové rozhraní s importem CA certifikátu přes mass storage... please any comments?
-
Ad 224.0.0.0/24 – IIUC je to určeno na multicasty v místní síti. Pravda, asi se to moc nepoužívá, ale čisté mi to nepřijde.
Ad dostupnost zvenku – zmínil jsem ostatní uživatele (v praxi spíše sandboxy, třeba na Androidu), cache poisoning (pokud se počítač připojuje do různých sítí) a DNS rebinding (pokud server neřeší Host, mohu si z prohlížeče udělat proxy). To všechno jsou realistické útoky, kde pro útočníka není překážkou, že k tomu nemá přímý přístup po síti. Analogicky: pancéřové dveře jsou hezká věc, ale útočník poleze oknem.