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

[redustin]

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.

[Reklama]

[LolPhirae]

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

[redustin]

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.

[vcunat]

Neslyšel jsem zatím, že by se zkracování platnosti mělo týkat kořenových certifikátů.

[LolPhirae]

Díky, zajímavé čtení, to vypadá na veliké radosti příští rok.

Neboj, M$ má jednoduchý návod, 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é.

[Reklama]

[r223]

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.

[redustin]

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

[LolPhirae]

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

[redustin]

Takže za reverzní proxy a dál pěkně HTTP. No, než podpora HTTP z té proxy taky zmizí. 

Bohužel reverzní proxy se blbě dává mezi PC a USB zařízení s USB-ethernetem.

[M_D]

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

[Zopper]

Takže za reverzní proxy a dál pěkně HTTP. No, než podpora HTTP z té proxy taky zmizí. 

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

[redustin]

Ř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?

[redustin]

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

[Zopper]

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

[redustin]

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.