HTTP/S a certifikáty v embedded zařízeních

[redustin]

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é.

[Reklama]

[XXX_Sam_XXX]

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.

[M_D]

Ř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. :-)

[r223]

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í.

[luvar]

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.

[Reklama]

[redustin]

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.

[František Ryšánek]

Ono se zřejmě dá, provozovat si privátní CA s podporou ACME v roli serveru. Zřejmě horší problém je, do embedded krabiček dostat certbot 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...

[redustin]

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.

[Vít Šesták (v6ak)]

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.

[redustin]

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í.

[Zopper]

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.

[Vít Šesták (v6ak)]

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.

[redustin]

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.

[redustin]

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?

[Vít Šesták (v6ak)]

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.