Vlákno názorů k článku Centralizovaná automatizace certifikátů pomocí orchestračního nástroje Ansible od kamui - Cerifikáty jsou fajn, ale chtělo by to i...

Cerifikáty jsou fajn, ale chtělo by to i nějakou bezcertifikátovou alternativu. Konkrétní příklad - u rodičů jsem zprovoznil postarší Qnap NAS - je ovšem problém na něm zprovoznit HTTPS, protože vestavěný acme program už nefunguje, protože LE změnilo svoje API, takže jediná možnost je manuální import certifikátu odjinud. S LE ponovu každý měsíc. Můžu tam dát dlouhodobý self-signed certifikát, ale to prohlížeče budou řvát a aktivně bránit uživateli, aby pokračoval. Proč u takových certifikátů nejde jako u SSH napoprvé klíč manuálně zkontrolovat a pak mu trvale důvěřovat? Tohle je situace která prakticky nemá řešení a předpokládám že se to týká mnoha podobných zařízení.

Tak tam nedavejte primo self-signed, ale ten self-signed pouzijte jako CA pro vydani certifikatu pro ten Qnap NAS.
A ten self-signed CA, necht si uzivatel naimportuje do trusted storu prohlizece.
Problem solved ;-)

To jiste, a ten user si bude kazdou hodinu generovat novej certifikat pomoci toho korenovyho ... aby se z toho browser nahodou nepotento.

Jo, to jo, ale zavádí to problém, že musíš spravovat celou CA. A až ti prohlížeče zkrátí důvěryhodnost certifikátu na pár dní, co potom?

Ono stejne pokud nekdo dela self-signed, tak to dela pres openssl na disku, takze udelat misto jednoho self-signed jednu self-signed CA a pod ni certifikat zarizeni jsou dalsi 2 radky v tom scriptu - generovani CSR a podepsani CA.

Vlastni CA ve storu ma platnost treba 10/20 let.
A vlastni certifikat pro NAS treba taky.
Zadny certifikat se neobnovuje, platnost se kontroluje vuci tem zavedenym/vydanym .....

To sice ano, ale budou těmto certifikátům důvěřovat prohlížeče? Ten tlak na zkracování platnosti certifikátů je poměrně silný...

Proč u takových certifikátů nejde jako u SSH napoprvé klíč manuálně zkontrolovat a pak mu trvale důvěřovat?
Pokud vím, prohlížeče tohle stále umožňují. Ale problém je v tom, že přesně tuhle cestou si do prohlížeče nainstalujete falešný certifikát útočníka. Jakmile uživatelům umožníte falešným certifikátem se proklikat, uživatelé to udělají.

Tohle je situace která prakticky nemá řešení a předpokládám že se to týká mnoha podobných zařízení.
Ta situace má řešení – výrobci budou pro svá zařízení poskytovat dlouhodobou podporu, při které zajistí bezpečnostní aktualizace včetně aktualizace softwaru pro vydávání certifikátů. Bohužel to většina uživatelů neřeší, takže tržního řešení bychom se asi nedočkali, ale EU už k tomu pomaloučku směřuje (právo na opravu výrobku jde tímto směrem).

Pokud vím, prohlížeče tohle stále umožňují. Ale problém je v tom, že přesně tuhle cestou si do prohlížeče nainstalujete falešný certifikát útočníka. Jakmile uživatelům umožníte falešným certifikátem se proklikat, uživatelé to udělají.

Riziko by se dalo minimalizovat tím, že prohlížeč by na tohle stále uplatňoval HSTS, tj. u webu s HSTS by self-signed certifikát a vyjímku nepovolil. To manuální ověření by se uplatnilo pouze při prvním spojení, a uživatel by byl jasně a zřetelně vyzván k tomu, ať otisk klíče zkontroluje, jako u toho SSH.

Takhle pokud vím HSTS už funguje. Pořád by to bylo výrazné bezpečnostní riziko. Nedělám si iluze, jak kontrolují otisk klíče uživatelé SSH – a u uživatelů webových prohlížečů by to bylo ještě násobně horší.

Web nikdy nebude bezpečný, když vytvoříte situaci „pokud se chcete dostat na web, musíte tady něco odklikat nebo opsat“ a budete doufat, že se nad tím uživatel zamyslí. Ne, čím víc překážek tam bude, tím víc se bude uživatel soustředit na překonání překážek a tím méně bude přemýšlet nad tím, zda to není nebezpečné.

Mal som podobný problém so Synology NAS. Na GitHub som našiel a osvojil skript, ktorý certifikáty od LE nakopíruje na NAS a reštartuje potrebné služby (viď https://github.com/pstefka/smarthome/blob/91225655603d72949f6f511a7cf00d7d32e44281/scripts/nas/replace_synology_ssl_certs.sh) .. predpokladám, že niečo podobné existuje aj pre Qnap. Potom už len nájsť vhodný orchestrátor, napríklad spomínaný Ansible v spojení so Semaphore UI a hotovo ;)

Tohle řeším tak, že certifikát se obnoví na jiném stroji (domácí laptop, ale asi by to uměl i kontejner na tom qnapu) standardní cestou (ověření přes DNS) a pak se skriptem přenese na QNAP (který není dostupný z internetu) v rámci post jobu. Všechno automaticky na pozadí. Podmínka je ssh na qnap, samozřejmě.

Něco jako dvakrát scp a pak script s

cd /etc/default_con­fig/stunnel
cat privkey.pem backup.pem > stunnel.pem
cp stunnel.pem /etc/config/stun­nel.pem
cp stunnel.pem /etc/stunnel/
/etc/init.d/stun­nel.sh restart


Dokumentaci jsem k tomu nenašel, takže pokus-omyl a prohlížení jejich skriptů. Možná to jde lépe.

A ted si predstav, ze v uplne domaci siti mas takovych kramu bez problemu desitky (kamery, apcka, televize, ...), kazdej je jinej, dokumentace neni k nicemu, kazdej ten kram ma nejaky jiny omezeni (treba starsi upsky APC nedovolej vic nez 768bit rsa) ...

V libovolny firemni infra muzes mit takovych kramu tisice. Uz vidim, jak pro kazdej ten kram vymejslis a udrzujes nejakej extra script ... a to jen proto, ze nejakej negramotnej ...tl si usmyslel, ze 10let platnej cert je fujky fuj.

Neni mnohem jednodussi a radove bezpecenjsi proste mit starou verzi browseru, kterej drzi pysk? A ano bezpecnejsi, protoze ty hromady scriptu ti casem se zcela 100% jistotou failnou a cert se nevymeni.

A teď si představ že na tu NASku nechodím jen já z jednoho počítače, ale i zbytek rodiny z různých klientů (mobil. čtečka, ...). A že v síti mám přesně dvě zařízení (router a NAS) kde to chci řešit. A počet změn klientů za posledních pět let je menší než počet úprav skriptů (dvě, pokud vím).

Takže pro mne je jednodušší tohle. YMMV.

Zadnej problem, pak dopadnes presne takhle...

https://www.bleepingcomputer.com/news/hardware/logitech-options-plus-g-hub-macos-apps-break-after-certificate-expires/