Certifikáty na souborovém systému jen ke čtení

[majvan]

Když ten certifikát nebudete updatovat vůbec (resp. nebudete mít tu možnost), existuje riziko, že když dojde ke kompromitaci privátního klíče, nemáte jak to vyřešit – jak ta zařízení přesvědčit, aby kompromitovanému klíči nevěřila. Tj. ani tak nejde o to, že by s delším používáním rostlo riziko kompromitace, to není tak velký problém – podstatné je, že kdyby k tomu došlo, nemáte jak tu situaci vyřešit. (Maximálně můžete informovat všechny zákazníky, ať to zařízení přestanou používat a odpojí ho od sítě.)

To je isto pravda, ale to zariadenie dokáŽe pracovať samostatne aj bez toho serveru, takže sa len nepodarí nejaká operácia. Na to, aby som nenechal všetky zariadenia pracovať v tomto degradovanom režime, tak by mali zariadenia vždy inštalované 2 certifikáty. Jeden súčasne používaný a druhý jeho náhrada. Ak príde ku kompromitácii, vymením certifikát a zariadenia budú fungovať ďalej.
Tým som získal dostatok času na vytvorenie nového záložného certifikátu a postupné servisovanie zariadení pre výmenu starého kompromitovaného certifikátu za nový.

Pokud to zařízení nebude poslouchat na síti a bude jenom v roli klienta dvou známých protokolů (DNS a HTTPS), přičemž to HTTPS bude omezené na jeden server pod kontrolou poskytovatele zařízení, je vektor útoku velmi malý. Takové zařízení bude podstatně bezpečnější, než pravidelně aktualizované zařízení, kde běží spousta služeb.

Presne tak. Príde mi, že vzdialený servis s možnosť patchovania celého systému, a teda možnosť úpravy celého FS, má oveľa väčšie riziko (severity * probability) ako kompromitácia https certifikátu.

[Reklama]

[Filip Jirsák]

To je isto pravda, ale to zariadenie dokáŽe pracovať samostatne aj bez toho serveru, takže sa len nepodarí nejaká operácia. Na to, aby som nenechal všetky zariadenia pracovať v tomto degradovanom režime, tak by mali zariadenia vždy inštalované 2 certifikáty. Jeden súčasne používaný a druhý jeho náhrada. Ak príde ku kompromitácii, vymením certifikát a zariadenia budú fungovať ďalej.
Tým som získal dostatok času na vytvorenie nového záložného certifikátu a postupné servisovanie zariadení pre výmenu starého kompromitovaného certifikátu za nový.

Tohle platí v případě, že přijedete o ten privátní klíč (např. se zničí token, kde je uložený). Pokud by došlo ke kompromitaci privátního klíče (tj. získal by ho někdo jiný), čas nemáte – protože i když vy začnete používat druhý klíč na serveru, úročník má k dispozici ten první kompromitovaný klíč, kterému ta zařízení stále důvěřují.

Proto jsem psal, že v tomto případě je potřeba mít dobře zabezpečený ten privátní klíč, ideálně na nějakém HSM nebo tokenu, odkud nejde vyexportovat. Aby se minimalizovalo riziko kompromitace privátního klíče. Protože ztrátu privátního klíče dokážete ošetřit tím, že zařízení bude důvěřovat většímu množství klíčů, ale kompromitaci takhle ošetřit nelze.

[majvan]

Tohle platí v případě, že přijedete o ten privátní klíč (např. se zničí token, kde je uložený). Pokud by došlo ke kompromitaci privátního klíče (tj. získal by ho někdo jiný), čas nemáte – protože i když vy začnete používat druhý klíč na serveru, úročník má k dispozici ten první kompromitovaný klíč, kterému ta zařízení stále důvěřují.

Súhlasím, zle som sa vyjadril. Ak by bol predchádzajúci certifikát zničený (ale nie kompromitovaný), mám čas na update.

Existuje teda nejaký spôsob, ako riešiť, že bol privátny kľúč kompromitovaný? Napríklad, že by sa pri TLS verifikovali dva certifikáty naraz Len to by potom si musel zvoliť TLS jeden, s ktorým začne komunikáciu - a môže to byť práve ten kompromitovaný.
Asi neexistuje iné riešenie v tomto prípade, len práve ísť cestou PKI a obmieňať v zariadeniach certifikáty root CA.

[Filip Jirsák]

Existuje teda nejaký spôsob, ako riešiť, že bol privátny kľúč kompromitovaný? Napríklad, že by sa pri TLS verifikovali dva certifikáty naraz Len to by potom si musel zvoliť TLS jeden, s ktorým začne komunikáciu - a môže to byť práve ten kompromitovaný.
Asi neexistuje iné riešenie v tomto prípade, len práve ísť cestou PKI a obmieňať v zariadeniach certifikáty root CA.

V rámci TLS spojení můžete ověřovat vždy jen jeden certifikát serveru.

Odvolání certifikátu v případě kompromitace privátního klíče se řeší pomocí CRL nebo OCSP. CRL ovšem vyžaduje pravidelně si stahovat seznam odvolaných certifikátů a udržovat si ho u sebe. Tj. opět to vyžaduje zápis na disk. OCSP se ověřuje online, ale Let's Encrypt se snaží přestat OCSP poskytovat. Obojí (CRL i OCSP) je opět závislé na certifikátu certifikační autority, takže byste stejně musel řešit tu aktualizaci certifikátů CA.

Pokud je to něco, co musí být opravdu bezpečné, nezbyde vám, než umět ty certifikáty CA aktualizovat. Nicméně pokud by to bylo něco takového, nebudete řešit certifikáty od LE, protože by pro vás nebyl problém zaplatit za nějaký komerční certifikát a HSM.

Pokud se smíříte s tím, že pravděpodobnost napadení není úplně neměřitelná, ale potřebujete to mít levné, pak bych zvolil variantu s tím, že v zařízení bude několik veřejných klíčů, kterým bude HTTPS klient důvěřovat. Jeden budete používat, ostatní budou záložní. Ty záložní klíče budou uložené třeba někde v trezoru (nebo radši dvou), abyste o ně nepřišel. A používaný klíč bude na nějakém USB tokenu nebo něčem podobném, přinejhorším v softwarovém HSM s dostatečnou úrovní zabezpečení (tj. aby se ke klíči nedalo dostat s jedním heslem, ale těch bezpečnostních prvků bylo víc). Pak je samozřejmě důležité, jak se s tím tokenem/HSM bude komunikovat. Bude to poskytovat klíče pro webový server, takže to musí být online. Tj. pak je nekritičtější komunikace mezi webovým serverem a tím HSM/tokenem – to je místo, které by se útočník pokusil napadnout a nechat si podepsat svou vlastní komunikaci. Pořád to ale má tu výhodu, že kdyby se to útočníkovi povedlo, bude se moci za server vydávat v danou chvíli – ale nezíská privátní klíč trvale. Takže  až útok odhalíte a chybu opravíte, útočník o přístup přijde.

Pozor ale také na to, že pak musí HSM/token podepsat každé navázané TLS spojení, takže musí mít potřebnou propustnost. Běžné levné USB tokeny jsou dělané na to, že tím člověk podepisuje nějaké dokumenty, takže mu bohatě stačí propustnost jeden podpis za několik sekund. To by vám na webovém serveru asi nestačilo.

[majvan]

Vďaka za odpoveď.
Možno som sa zle vyjadril, pre mňa nie je Let's Encrypt nejaký požiadavok, ak by som šiel cestou CA. Akú má výhodu komerčný certifikát, resp. certifikát od inej CA ako Let's Encrypt?

Tiež som celkom nepochopil s tým HSM. Predpokladám, že k serveru nebudem mať prístup (cloud), takže TLS bude bežať s privátnym kľúčom z úložiska cloudu.
Ja si len zapíšem u mňa na Trezor ten privátny kľúč pre prípad, že by som potreboval certifikát a kľúč opätovne uploadoval do cloudu (napríklad pre prípad, že by som službu so zdrojmi musel ešte raz definovať).
Správne tomu rozumiem?

[Reklama]

[mark42]

HSM je najbezpecnejsi sposob uschovy privatneho kluca. Je to bezpecnejsie ako mat ho niekde v beznom ulozisku, pretoze tam sa otvara moznost, ze hacker alebo admin ten kluc pouzije alebo skopiruje (vytiahne zo zalohy atd...) Oproti tomu samotne HSM len prijima poziadavky a za pouzitia PK ich vybavuje (napr. dodava podklady pre vytvorenie sifrovaneho spojenia, alebo podpisuje dokumenty).

[Filip Jirsák]

Akú má výhodu komerčný certifikát, resp. certifikát od inej CA ako Let's Encrypt?

Aktuálně vydávají komerční CA certifikáty s roční platností. Takže pokud nemůžete použít automatizaci přes ACME protokol a musíte certifikáty řešit a někam nahrávat ručně, je jednodušší to dělat jednou za rok než 4–5 krát za rok. Ale jsou tlaky na zkrácení platnosti certifikátů, takže pravděpodobně i ty komerční CA budou někdy donucené platnost certifikátů ještě zkrátit.

Tiež som celkom nepochopil s tým HSM. Predpokladám, že k serveru nebudem mať prístup (cloud), takže TLS bude bežať s privátnym kľúčom z úložiska cloudu.

To chce vybrat nějaký důvěryhodný cloud, a pak s tím klíčem rozumně pracovat. Ideálně pokud ten cloud má nějaké úložiště citlivých informací a dá se to nějak rozumně dostat do aplikace (aby to nebyl soubor na disku, který bude moci přečíst i ta aplikace běžící na webovém serveru, nebo dokonce jiné aplikace běžící na stejném serveru).

V tomhle případě je hodně důležité, jaká bude povaha těch dat, která ta zařízení budou odesílat. Pokud to bude posílat teplotu ve skleníku u pár desítek či stovek českých klientů, pak se asi nestane nic vážného, pokud by ta data unikla nebo by je někdo zfalšoval. Pokud to bude něco, že z těch dat půjde odvodit, zda je někdo doma u desítek tisíc domácností po celém světě, nebo přes to půjde v podobném počtu domácností vypnout vzdáleně lednici, tak bych asi nešel do toho, že nějaká poměrně banální chyba může způsobit únik privátního klíče a já ho pak nebudu schopen zneplatnit.

Ja si len zapíšem u mňa na Trezor ten privátny kľúč pre prípad, že by som potreboval certifikát a kľúč opätovne uploadoval do cloudu (napríklad pre prípad, že by som službu so zdrojmi musel ešte raz definovať).

V tom případě musíte mít klíč uložen tak, aby byl exportovatelný, což nevím, zda Trezor umožňuje.