Šifrované připojení k embedden serveru na lokální síti

[Darkhunter]

Zdravím,
mám takový zapeklitý problém.
Chtěl bych se připojit z lokální sítě z Android aplikace a případě i z webu na embedded server.
Server poběží na lokální síti, takže se k němu bude připojovat přes IP adresu, což je také problém při vystavení certifikátu.
Hlavní problém je, že Android nepovoluje nezabezpečené připojení, takže musím použít HTTPS.
Já chtěl stejně HTTPS použít, protože se tam přenáší credentials atd.
Problém je ale, že v dnešní době jsou velká omezení ohledně HTTPS. Třeba prohlížeče povolují jen certifikáty, co mají expiraci maximálně 3 roky atd.
Já potřebuji, aby HTTPS na tom embedded serveru fungovalo minimálně 10 let. Server nebude připojený k internetu a bude se nasazovat do vzdálených lokalit, takže není možné osobně vyměnit certifikát.
Chtěl jsem si udělat vlastní CA a importovat certifikát buď do Androidu nebo do prohlížeče, ale pak jsem si uvědomil tyto problémy.

Nevíte, jak toto vyřešit? Se vsadím, že nejsem jediný s takovýmto problémem.

Děkuji.

[Reklama]

[Jakub Štech]

Asi kravina, ale co dát kořenový cert té Vaší CA do toho embedded zařízení a interně si ten user-facing certifikát obnovovat třeba jednou za půl roku?

[IDontCare]

Ted se to tady resilo:

https://www.root.cz/clanky/let-s-encrypt-se-stavi-na-vlastni-nohy-zmena-korene-odrizne-tretinu-androidu/

[by_cx]

10 let? Si vem jak vypadal web přes deseti lety a jak vypadá dneska. Je vcelku jistota, že cokoli tam dneska nasadíš nebude za 10 let fungovat. Vzal bych nějakou doménu, použil LE s ověřením přes DNS a dál to neřešil.

[M_D]

Tak jde o to, zda ti připojující klienti bude běžný spotřebitel nebo specializované servisní zařízení. Pokud se mám připojit s něčím, co si za 10 let koupím v prvním obchodě, tak se dá předpokládat, že doba platnosti certifikátu bude to poslední, to možná už nebude klientské zařízení akceptovat ani TLSv1.3 nebo http/2.0 protokol. :-(
Pokud má jít o specializovaný servisní terminál, který bude existovat v omezeném množství kusů a budu i jeho dodavatelem, tak pak se s tím už nějak pracovat dá (když se rozhlídnu a vidím ty tuny systémů na bázi Windows NT4.0, co stále kolem fungují v server i workstation edici).

[Reklama]

[Filip Jirsák]

Android povoluje nezabezpečené připojení. Nicméně nejjednodušší řešení je dát před ten server reverzní proxy server, na něm zakončit pořádné HTTPS (s doménovým názvem z veřejného DNS a s důvěryhodným certifikátem). Komunikace mezi tím reverzním proxy serverem a embedded serverem pak může být i nešifrovaná, pokud to musí být. A nebo si tam vystavíte nějaký self-signed certifikát s dlouhou platností.

[Darkhunter]

Asi kravina, ale co dát kořenový cert té Vaší CA do toho embedded zařízení a interně si ten user-facing certifikát obnovovat třeba jednou za půl roku?

To vůbec není špatný nápad...Ale tam stejně po té době budou i jiné problémy...

Ted se to tady resilo:

https://www.root.cz/clanky/let-s-encrypt-se-stavi-na-vlastni-nohy-zmena-korene-odrizne-tretinu-androidu/

Jo, ale já mám asi teď trošku jiný problém. Nebudu závislý na LE.

10 let? Si vem jak vypadal web přes deseti lety a jak vypadá dneska. Je vcelku jistota, že cokoli tam dneska nasadíš nebude za 10 let fungovat. Vzal bych nějakou doménu, použil LE s ověřením přes DNS a dál to neřešil.

Ale to zařízení nebude připojené k internetu, takže nemůžu validovat...

Tak jde o to, zda ti připojující klienti bude běžný spotřebitel nebo specializované servisní zařízení. Pokud se mám připojit s něčím, co si za 10 let koupím v prvním obchodě, tak se dá předpokládat, že doba platnosti certifikátu bude to poslední, to možná už nebude klientské zařízení akceptovat ani TLSv1.3 nebo http/2.0 protokol. :-(
Pokud má jít o specializovaný servisní terminál, který bude existovat v omezeném množství kusů a budu i jeho dodavatelem, tak pak se s tím už nějak pracovat dá (když se rozhlídnu a vidím ty tuny systémů na bázi Windows NT4.0, co stále kolem fungují v server i workstation edici).

Jo, to mě taky napadlo. Prostě koupit nějaké tablety a distrubovat je po celou dobu životnosti. Jedna verze tabletu locklá na jednom Androidu. Ale pořád mám problém s tím certifikátem...

Android povoluje nezabezpečené připojení. Nicméně nejjednodušší řešení je dát před ten server reverzní proxy server, na něm zakončit pořádné HTTPS (s doménovým názvem z veřejného DNS a s důvěryhodným certifikátem). Komunikace mezi tím reverzním proxy serverem a embedded serverem pak může být i nešifrovaná, pokud to musí být. A nebo si tam vystavíte nějaký self-signed certifikát s dlouhou platností.

Jo, jenže ono to nemá připojení k internetu...
Self-signed je jedna možnost, ale ten mi to taky zamítne, když bude mít delší dobu než 39 měsíců ne?

[_Jenda]

Chtěl bych se připojit z lokální sítě z Android aplikace a případě i z webu na embedded server.

Aplikace nemůže mít certifikát zařízení zapinovaný?

Bohužel přidávání vlastní CA do Androidu efektivně nelze, řešilo se to v diskuzi pod tím odkazovaným článkem. Navíc nechceš přidat CA, která kromě toho zařízení pak bude moct podepsat i root.cz, že jo.

Co s prohlížečem nevím, za mých mladých let šlo udělat ,,Přidat výjimku a tento certifikát si pro tento hostname pamatovat", ale to bylo ve jménu pokroku zrušeno (musí se přidávat výjimka po každém restartu, a samozřejmě fingerprint po každém restartu si nikdo kontrolovat nebude)

Nevíte, jak toto vyřešit? Se vsadím, že nejsem jediný s takovýmto problémem.

Nijak. Pro sebe bych to řešil pomocí socat proxy s natvrdo nastaveným certifikátem nebo SSH tunelem (btw. na SSH servery starší tak 10 let se dnešním openssh taky nejde připojit (Debian Lenny myslím funguje, ale koukám, že poslední server s Lennym mi před chvílí někdo vypnul, takže nemůžu zkusit, CentOS 5 už ne)), ale jak to udělat pro BFU a na Androidu netuším.

10 let? Si vem jak vypadal web přes deseti lety a jak vypadá dneska. Je vcelku jistota, že cokoli tam dneska nasadíš nebude za 10 let fungovat. Vzal bych nějakou doménu, použil LE s ověřením přes DNS a dál to neřešil.

Moje věci z před-10-lety normálně fungují, a pokud nebudeš používat javascriptové orgie (což je jedině dobře a ocení to i uživatelé), tak budou i tvoje. Jediný problém by v tomto případě byla nepodpora TLS 1.2.

[M_D]

Vlastní CA a vydané certifikáty na dlouhou dobu, je stále ještě asi cesta, ale z pohledu někoho, kdo musí takové vykopávky udržovat (a to 10 let starý systém je ještě mládě), tak narazíte spíše na ty zmíněné protokoly. Když vezmu současnou techniku a jak se tváří na servery, co umí jen SSL nebo max TLS1.0...
Proto půjde o to, zda mohu už projektově brát, že ty embedded servery jsou aktualizovatelné, třeba max každé 2 roky se k nim dostane servis, který by třeba ten server upradoval. Zda jde opravdu o ostrovní izolované systémy (kam přijde servis až po těch 10 letech) nebo jsou v izolované síti s centrálním dohledem.

[Filip Jirsák]

Jo, jenže ono to nemá připojení k internetu...

Tzn. jde o síť úplně odstřiženou od internetu? Vy tam přijdete s telefonem a připojíte se na místní AP? Pak tam klidně můžete použít self-signed certifikát, protože ten si jednou nainstalujete – a nikdo jiný se tam připojovat nebude.

Ale pokud tam v síti internetová konektivita je, můžete použít důvěryhodné certifikáty od Let's Encrypt, ZeroSSL nebo Buypass. Ten certifikát by nezískával embedded server, nýbrž proxy server. (A nemusí to ani dělat sám, může to pro něj zprostředkovat jiné zařízení). A stačí možnost vložit záznam na příslušný DNS server a stáhnout vystavený certifikát přes HTTPS. Třeba Caddy může fungovat jako proxy server, zároveň umí automaticky získávat certifikáty přes ACME, a už má implementovánu podporu pro několik cloudových poskytovatelů DNS.

Self-signed je jedna možnost, ale ten mi to taky zamítne, když bude mít delší dobu než 39 měsíců ne?

Ne. Ta pravidla na délku platnosti se týkají jen certifikátů vydávaných uznávanými certifikačními autoritami. A ta délka už nejsou tři roky, ale rok a kousek.

Ale v tom případu, který jsem popisoval, by se self-signed certifikát používal jen pro komunikaci mezi embedded serverem a proxy serverem, tím pádem by pravidla prohlížečů nehrála vůbec žádnou roli. Tomu self-signed certifikátu by musel důvěřovat jenom ten proxy server.

Výhoda předřazeného proxy serveru je také v tom, že v něm můžete průběžně aktualizovat šifrovací protokoly a algoritmy. Za 10 let tu budeme mít třeba TLS 1.6 nebo něco takového, nové šifrovací algoritmy – a dostat to na ten embedded server bude dost obtížné ne-li nemožné.

[czechsys]

Self-signed s dlouhou platnosti a umozneni importu vlastniho certifikatu.

Vse ostatni zalezi na tom, ze jste neuvedl, jestli se k tomu serveru pripojuje pouze technik, nebo i zakaznik. Z toho se odviji dalsi pozadavky.

10 let je dlouha doba. A ja citim, ze za tech 10 let se do certifikatu brutalne rizne, stavajici system pomalu a jiste kolabuje.

[czechsys]

Jo, jenže ono to nemá připojení k internetu...

Ale pokud tam v síti internetová konektivita je, můžete použít důvěryhodné certifikáty od Let's Encrypt, ZeroSSL nebo Buypass. Ten certifikát by nezískával embedded server, nýbrž proxy server. (A nemusí to ani dělat sám, může to pro něj zprostředkovat jiné zařízení). A stačí možnost vložit záznam na příslušný DNS server a stáhnout vystavený certifikát přes HTTPS. Třeba Caddy může fungovat jako proxy server, zároveň umí automaticky získávat certifikáty přes ACME, a už má implementovánu podporu pro několik cloudových poskytovatelů DNS.

Totalni kravina.

Urcite nebudu povolovat neznamymu zarizeni treti strany pristup do administrace DNS.

[Josef Komjati]

Jo, jenže ono to nemá připojení k internetu...

Ale pokud tam v síti internetová konektivita je, můžete použít důvěryhodné certifikáty od Let's Encrypt, ZeroSSL nebo Buypass. Ten certifikát by nezískával embedded server, nýbrž proxy server. (A nemusí to ani dělat sám, může to pro něj zprostředkovat jiné zařízení). A stačí možnost vložit záznam na příslušný DNS server a stáhnout vystavený certifikát přes HTTPS. Třeba Caddy může fungovat jako proxy server, zároveň umí automaticky získávat certifikáty přes ACME, a už má implementovánu podporu pro několik cloudových poskytovatelů DNS.

Totalni kravina.

Urcite nebudu povolovat neznamymu zarizeni treti strany pristup do administrace DNS.

Sice s Vámi vesměs souhlasím, ale nedá mi to.. Pokud má k dispozici dedikovanou doménu / zónu, pak to zase takové porno není. V API se tokenu povolí jen create v určité zóně jednou za interval a máte to pod kontrolou.

Ale jinak je to specifický use case.

[Filip Jirsák]

Totalni kravina.

Urcite nebudu povolovat neznamymu zarizeni treti strany pristup do administrace DNS.

Příště místo rychlého odsouzení raději věnujte čas lepšímu přečtení komentáře. Nejedná se o žádné neznámé zařízení třetí strany, ale o administrátorem provozovaný reverzní proxy server. A není potřeba přístup k administraci DNS, ale pouze k nastavení obsahu jednoho TXT záznamu. Pokud chcete příslušné A/AAAA záznamy vystavovat do internetu a vystavovat tam port 80 nebo 443, klidně můžete ověřovat certifikát přes HTTP-01 nebo TLS-ALPN-01. Nebo můžete údaje do DNS zadávat ručně. Já jsem jenom uvedl nejsnazší způsob, jak pro zařízení, které není dostupné z internetu, obstarat dobře použitelný certifikát.

[Ondrej Nemecek]

Pokud to má fungovat za 10 let s běžným Android zařízením coby klientem, tak to lze ošetřit IMHO jedině upgradem firmware toho zařízení, tedy umožněním servisní údržby zařízení (bez toho stejně nemůžete garantovat podporu či funkčnost). Protože prostě nevíte, co se za 10let změní.

Aktualizace certifikátu nemusí stačit, jelikož se mohou změnit i důvěryhodné algoritmy.

Servis lze předsunout na tu proxy, jak někdo navrhoval, ale princip se tím IMHO nezmění.

Nebo yrobit speciálního dedikovaného klienta a používat pouze ten, jak také někdo navrhoval. Dedikované zařízení může s trochou snahy bez údržby fungovat i za těch 10 let, na uzavřené síti nebudou rizika snad tak velká. Ale nezapomeňte co se stalo s medicínskými zařízeními, kdy si někdo myslel, že nebudou nikdy připojena do internetu a že tedy není třeba řešit upgrady a bezpečnost. Dnes je to velký průšvih.