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.
Poslední příspěvky
odkedy som nan presiel prakticky grep nepouzivam okrem trivialit.