Vlákno názorů ke zprávičce Apple podal návrh na postupné zkracování platnosti certifikátů pro HTTPS od dr_ak - Moc nechápu smysl toho zkracování.... Rozumím, že spolehlivě nefunguje...

Moc nechápu smysl toho zkracování....
Rozumím, že spolehlivě nefunguje propagace revokovaných certifikátů do prohlížečů...
Ale - životnost napadených a škodících webů se už teď pohybuje v rámci hodin, tak pokud bude platnost certifikátu i jen desítky dnů, tak stejně takový web bude moci škodit desítky dnů a reálně se nic nezlepší.. Nebo mi něco uniká?

Za mě to celé visí na třech pilířích.

A) za certifikátem jsou i nějaké kryptografické algoritmy, které se ale mohou stát velice rychle zranitelné a rychlá výměna certifikátů zmanená i možnost rychle vylepštovat kryptografické algoritmy. Pamatuji doby s md5, kdy byly platné certifikáty i v době, kdy už nebylo rozhodně správně je provozovat.

B) v rámci certificate transparency se evidují všechny vydané certifikáty, snížením platnosti se sníží i náklady na provoz jejich seznamů, to dost výrazně.

C) zlepšení certificate managementu, aby byl plně automatizovaný a dostatečně robustní, protože jeden napadený server ovlivňuje celé své okolí a hlavně uživatele.

Ač se Google rozhodl sám, tak se o tomhle mluví ve více kruzích. Za mě to je mezikrok jak celý proces udělat ještě více odolné.

Pořád tady platí se tohle omezení na 90 dní se týká pouze certifikátů, které jsou určeny pro veřejný internet a společný prostor, interní či vnitřní certifikáty pořád můžeš mít jakékoliv. Chápu to tak, že ve veřejném prostoru zase nemám takovou volnost si vše dělat podle sebe a musím se přizpůsobit většině.

ad B = není CT založen na Merkel tree a append-only logu, takže úspora se tam nemá jak projevit?

ano, CT je merkle tree, ale v něm jsou pouze hashe (a pár dalších údajů), log je distribuovaný, což znamená, že se vytváří pravidelně nové a nové stromy a podepisují se navzájem.

Mít data uložená je levné, mít ke k dispozici milionům požadavků za hodin je už o něčem jiném. Nic neroste věčně a o tom kolik dat můžeme mít v CTL se mluví, i nové CT 2.0 už počítá s uzamknutím CTL a vytvořením nového.

ad B) to by me zajimalo, japa chces realizovat usporu, kdyz mas rekneme milion certifikatu platnych rok, vs milion certifikatu platnych mesic. Jen budes mit 12x vetsi provoz pri jejich aktualizacich.

"interní či vnitřní certifikáty pořád můžeš mít jakékoliv"
To chci videt, jak budes chromaka nebo jabko presvedcovat o tom, ze ten tvuj 10 let platnej certifikat ma akceptovat ... jo aha, ono to nejde, jak bys vedel, kdybys to zkusil.

Ja to narozdil od tebe vim, protoze par jabkem postizenych kusu ve sve bubline mam. Jednoho krasneho dne vsichni dorazili, ze ten firemni CA cert ktery meli importovany uz neni duveryhodny.

Chápu to tak, že ve veřejném prostoru zase nemám takovou volnost si vše dělat podle sebe a musím se přizpůsobit většině.

To asi nechápeš úplně správně. Nepřizpůsobuješ se většině, ale gůglu (a potažmo jabku).

hm, IETF, NIST a další tvrdí přesně tohle doporučení. Google si to jen změnil teď sám a podle reakcí ostatních to moc nekonzultovat a nekoordinoval.

mohou stát velice rychle zranitelné
To „velice rychle“ je ale v řádu let – to opravdu není důvod, proč zkracovat platnost koncových certifikátů na měsíce. Ostatně i kdyby tu přistáli přátelští mimozemšťané, kteří by nám omylem vyzradili, jak louskat některé kryptografické algoritmy, aby to bylo opravdu „velice rychle“, budeme mít stejně problémy s certifikáty autorit. Protože ty používají úplně stejné algoritmy, a za 30 dní je rozhodně nevyměníte.

v rámci certificate transparency se evidují všechny vydané certifikáty, snížením platnosti se sníží i náklady na provoz jejich seznamů, to dost výrazně.
Jako že když na tom seznamu budete mít víc položek, budou náklady na jeho provoz výrazně nižší? To těžko, ty náklady naopak budou vyšší.

Ač se Google rozhodl sám
Přímo v titulku zprávičky je napsáno, že návrh podal Apple. Minulé zkrácení prosadil také Apple, faktické zkrácení u velkého mnosžtví certifikátů zařídil Let's Encrypt. Shoda na tom, že je potřeba platnost webových certifikátů zkracovat, je poměrně široká.

Vůbec nejde o napadené a škodící weby. Jde o legitimní weby, kterým unikne privátní klíč. Kdyby dneska utekl privátní klíč nějaké bance, Googlu, Alze nebo nějakému menšímu e-shopu, tak se někdo dokáže vydávat za ten web přes rok – pokud by privátní klíč utekl hned na začátku. Banka nebo Google ty klíče snad mají dobře zabezpečené, nicméně už taková Alza má privátní klíče nejspíš uložené jako soubory někde na disku, možná na nějakých VPS. Takže pravděpodobnost úniku není úplně malá.

No a pak je tu samozřejmě specifický případ změny vlastníka domény, kdy původní vlastník může mít dál v držení certifikáty a privátní klíče přes rok po prodeji domény.

Jinými slovy, revokace je v koši, a nemá smysl to řešit jinak, než timeoutovat.

Smysl bude mít přidání otisku veřejného klíče do HTTPS DNS záznamu (což by u prohlížečů mohlo projít, padnou všechny výhrady proti DANE). Pak bude možné DV certifikáty od certifikačních autorit zrušit (a tím napravit historický omyl), používat self-signed certifikáty a od CA si případně nechat vystavovat OV certifikáty. V DNS ten certifikát půjde zneplatnit v řádu minut či hodin, podle nastavení DNS.

Seznamy revokovaných certifikátů jsou pro prohlížeče nepraktické, protože udržovat ve všech prohlížečích kompletní seznam všech odvolaných certifikátů není moc efektivní. Online se dotazovat na platnost certifikátu znamená prozrazovat, kdo se na jaký web dívá. A řešit to přikládáním OCSP potvrzení ke certifikátu ze strany serveru se Let's Encrypt nějak nechce, a vzhledem k tomu, že vydávají zdaleka nejvíc TLS certifikátů, bude to tak, jak se rozhodnou. Upřímně se jim moc nedivím, že se jim do toho nechce, protože pak se z té CA stává single point of failure – stačí tu CA odstavit na hodinu a velká část webu bude nedostupná.

Tenhle návrh mi nepřijde úplně praktický. Podle mne to bude náchylné na odmítání komunikace/ověření. Jakmile do hry vstoupí nějaká cache (případně cache proxy), bude se stávat, že certifikát na webu nebude souhlasit s otiskem v DNS.
Kromě toho by bylo potřeba se vypořádat s dalšími situacemi, například:
* certifikát na serveru s množstvím domén - změna by znamenala zápis do mnoha DNS,
* certifikát vystavený pro více serverů za loadbalancerem, tedy více platných certifikátů se stejným jménem serveru...

revokace ale nikdy nefungovala správně, stačilo zabránit stažení seznamu, což malý DDoS v vhodnou dobu poslouží dobře.

V CRL je uvedeno, do kdy musí být vydáno další CRL. Takže správně implementovaná revokace funguje správně – akorát je použitelná jen v případě, kdy máte na ověřování podpisu dost času. Používat na online komunikaci certifikáty, které z principu mají zastaralé údaje, je historický omyl. Správné řešení je mít klíče v DNS chráněném DNSSEC, ale než se k tomu v prohlížečích dopracujeme, bude to ještě chvilku trvat.

Nj ... to je tak, kdyz nekdo netusi co je to DNS ... vis jirsaku, to by krome toho klice potreboval totiz taky.

To ze si muze kdokoli nechat vystavit cert na temer libovolnou domenu, pokud ma pristup k nejakemu (libovolnemu) emailu na ni ani nemluve. Proc by nekdo jako krad nejaky webovej klic? Koho to zajima? Aha, presne nikoho.

No, to je ale podobné, pokud se někdo bude vydávat za banku, tak měsíc mu bude na záškodnictví taky asi stačit...

15. 10. 2024, 17:56 editováno autorem komentáře

Měsíc je doba, po kterou se ještě dají použít nějaká jiná opatření. Rok už by se dal řešit jedině tak, že by se ta doména přestala používat. Jinak samozřejmě ani ten měsíc není ideální – proto máme v PKI zabudován mechanismus revokace certifikátů. Který ovšem nebyl úplně stavět pro situaci, kdy je ověřovatel certifikátu v náramkových hodinkách a řeší se, aby se zobrazení webu nezdrželo o deset milisekund.