Názory k článku
Apple podal návrh na postupné zkracování platnosti certifikátů pro HTTPS
-
Dnssec rozbiji provoz, jestli chces priklad, tak s tim nefunguje IPv6 only sit, ktera by chtela komunikovat do Ipv4 site. Protoze tam musi DNS vracet IPv4 prelozenou do IPv6 prostoru.
Dane prozmenu brani smirovani, browser se pak nebude ptat nejakyho seznamu certifikatu jestli zrovna tenhle zna.
A mimochodem https://bugzilla.mozilla.org/show_bug.cgi?id=14328
25let. To souvisi s tim DANE.
-
Dnssec rozbiji provoz, jestli chces priklad, tak s tim nefunguje IPv6 only sit, ktera by chtela komunikovat do Ipv4 site. Protoze tam musi DNS vracet IPv4 prelozenou do IPv6 prostoru.
To není fundamentální problém, řeší ho např. RFC7050. Kdyby byla vůle, tak technické problémy jsou řešitelné.
Skutečný důvod je, že by se tím decentralizovala moc, a to korporátní ilumináti nechtějí.
-
DannyStříbrný podporovatelTo je hodne izolovany case, koncove resolvery (na klientech) moc nevaliduji tak jako tak. A validaci na mezilehlem resolveru (toho, ktereho se ti klienti ptaji) jde vyresit i s DNS64. Mimoto, je tu i dalsi mozna cesta skrze IPv6 mostly, t.c. ve fazi draftu. Aneb cesticky tu jsou, kdyz se chce.
-
DannyStříbrný podporovatel
V dobe, kdy tu existuje vicero poskytovatelu vydavajici certifikaty bezplatne tento argument s penizky taky uz jaksi pada...
-
tak u Fortigate už cert měníme přes api, co je s tím za problém? Sophos to bude mít nejspíš podobně.
Díky automatizaci certifikátů se u klientů prakticky přestali povalovat certifikáty v chatech, emailech, na discích a všichni ví, kde přesně jsou. Zároveň se tahle část začala také automatizovat a testovat, tj. dnes už víme jaké správné nastavení je pro FW a ne, že k tomu nemá nikdo ani čárku a prostě to je nějak 5 let nastavené a nešahá se do toho.
Myslím, že ta kultura se výrazně zlepšila, jako vedlejší efekt krátkých certifikátů je to super.
Každopádně tohle zkracování přidělává neřešitelné problémy pro různé krabičky, které nejsou v servovně ale u zákazníků, u nich žádné dobré řešení není a vše se musí připojovat na internet a dělá proxy přes vlastní servery, což zrovna není dobré.
No, nebo se vykašlat na REST/web a prostě použít šifrovaný binární protokol.
-
provozovat systém a napsat k tomu "nemám důvěru, jestli se něco jiného nerozbije" vypadá na velký problém a nejde už vůbec o samotné certifikáty.
Co, co provozuješ (nebo spravuješ), bys prostě měl znát, mít možnost někde otestovat změny nastavení a být schopný vědět, co se změnou stane a stejně tak monitorovat produkci, že se chová správně.
Ono to nějak funguje a raději na to nešahám znám, ale dnes to jsou doslova otevřené dveře pro útočníky.
Právě tyhle krátké certifikáty hodně mých klientů donutili začít věnovat pozornost něčemu, na co roky sedal prach, zřídit testovací prostředí a narovnat vůbec tenhle proces.
-
"a napsat k tomu "nemám důvěru, jestli se něco jiného nerozbije""
Vis v cem je problem? Ze ja, a semnou kazdej kdo kdy v IT neco realne delal vi, ze se to rozbije zcela 100%. Specielne vsemozna API. Napises si na to nejakej script kterym budes neco nekde. Ono to bude fungovat, rok, dva, deset, a pak prijde nejakej frikulin, kterej rekne ze takhle to neni dost khull ... a proste ti to ze dne na den fungovat prestane.
A to nemusi byt jen o tom api samotnym, protoze ty pouzijes treba nejakou knihovnu ...
Cim vic takovyh volovin pak v infrastrukture mas, tim castes musis resit, ze se uz zase neco podelalo a zase neco nekde prestalo fungovat.
Donedavna kdyz sem nekde potreboval cert, dal sem mu platnost 100let, a vedel, ze tou dobou to ja uz rozhodne resit nebudu.
-
Nelze znat system ktery je blackbox. Znat znamena vedet o internals, o tom co presne kazda funkce dela, jak ovlivnuje vykon a stabilitu. Co presne se zmenilo po updatu sw atd.
Ja to u vetsiny provozovaneho HW neznam. Tim spis pokud dojde k major update a člověk je zas na zacatku.
A vlastne ani ne u vyvijeneho hw ktery ma v sobe binarni bloby.Umět nakonfigurovat u mne neznamená "znam". Pro to abych mohl rici "neco znam" musim se alespon na par mesicu zavrit s tou krabici do labu a otestovat funkcionalitu s nejakou specifickou verzi sw.
Abych mohl rici "znam" tak musim byt na urovni vyrobce. -
Filip JirsákStříbrný podporovatelPro deep inspekci ale máte certifikát interní certifikační autority, takže ten může platit libovolně dlouho (nebo jestli je tam nějaký limit patnáct nebo dvacet let, je to jedno).
-
Šílenej ajťákStříbrný podporovatelNo pokud do toho takhle šlápnou velcí hráči typu google a Džabko, tak lze od renomovaných dodavatelů ocekavat nové FW s podporou ACME...
Např. FORTIGATE umí acme od verze 7.0 -
Ne vzdy je to jednoduse mozne. Tim spis pokud mate jako korporat mate deal s CA a je hodne tezke z toho vycouvat. Hezky si vas omotaji kolem prstu privatnim api na vydavani certifikatu. A k tomu parta opicaku ktera se za to plati.
Nedokazu si predstavit kolik malych appek to bude muset resit.
Je sice mozne ze timto rozhodnutim se vytvori tlak na vydavatele certifikatu aby zavedli univerzalni mechanismy, nicmene to nejakou dobu trva. -
Jenze vydavatele certifikatu jsou ve skutecnosti to nejmensi. Tech tzv "duveryhodnych" je par. Problem je, jak budes ty certifikaty dostavat tam, kam je dostat potrebujes. Uz to, ze si ten cert vygenerujes jinde je vlastne fail. A do naprosto drtivy vetsiny veci ho proste nedostanes jinak, nez rucne.
A i kdyz nacpes, je s tim dalsi krasna vec ... ve vetsine pripadu pak musis tu vec celou restartovat. Kdyz to je 1x rocne, da se to zkousnout, 4x rocne uz je na hrane, ale castejs ...
-
Tyto mechanismy mame vicemene zmaknute. Vicemene protoze vzdy prijde nejaky hloupy startup kde cekam nejakou nestandartni "inovativni" zradu. Pro nas nejvetsi koule na noze jsou ty CA. Uz tu nekdo popisoval korporatni kolecko trvajici mesic. U externich sajt je toto take nas pripad. Uplne stejne blby proces.
Balancery, firewally obvykle problem nejsou pokud vendorovi nerupne v kouli - mluvim o tobe Palo Alto a tvych QA.
Pritom interni systemy maji proces automatizovany nebo alespon poloautomatizovany.16. 10. 2024, 07:10 editováno autorem komentáře
-
No... U nás platí pravidlo, že tyhle placené certifikáty prostě nesmí obnovovat automat, dokonce ani řadový pracovník. Je potřeba nejprve projít kolečkem v interním systému, kde odpovědná pověřená osoba popíše, na co a proč potřebuje utratit těch pár dolarů za certifikát, pak to musí schválit manager, potom teprve lze podat žádost. Vygenerovaný certifikát je pak předán na systém (často u dodavatele) k nasazení, které se děje výhradně ve stanovených termínech (1× týdně). Certifikát musí být obnovený nejméně 10 dní před vypršením platnosti, a to nejprve v testovacím prostředí a nejméně za týden ve dvou vlnách v produkčním prostředí.
Celkem tedy cca tři týdny pilné práce, kterou musíte ukončit 10 dní před koncem platnosti - to znamená, že při platnosti 45 dní máte poté 24 dní pauzu, než s tím začnete znova.
Nevím, zda bude rychlejší změna délky platnosti, nebo změna interních korporátních předpisů... ;oD -
DannyStříbrný podporovatel
Chybne nastaveny korporatni proces neni problem technologie :-) A ono tvrdy naraz do zdi donuti i korporat ty veci vyresit pricetneji.
-
To, že zadřete pár ajťáků neustálým obnovováním certifikátu rozhodně není
tvrdý náraz do zdi
!
Prostě se řekne, že je to jejich povinnost, a když to zvládali dosud, budou to zvládat i nadále - a ne-li, pocítí to na finančním ohodnocení. Rozhodně nepředpokládám, že kdokoliv svolí s automatem, generujícím opakovaně nové a nové platby - jak jde o peníze, jsou managoři zcela nesmlouvaní! -
Ako dlho si myslis ze ten ajtak bude plytvat svojim casom v takej robote? Ti ludia sa tam budu tocit este v skusobke.
Bud sa to bude dat plne zautomatizovat, kor vo vacsich firmach kde to bude treba robit dookola ako u *ebnutych na povale na desiatkach az stovkach serverov (mam na mysli take ktore ma v sprave jeden clovek, su pravdaze firmy ktore maju zopar desiatok tisic serverov ala google, MS, amazon, ... ale tie nespravuje jeden clovek) a ako zvycajne manazment to prideli za ulohu tomu spravcovi alebo devopsakovy. -
TL je od té úrovně managementu, která takové věci řeší, ještě hodně daleko.
Ve velké firmě (navíc mimo IT obor) je nebohý ajťák jen trpěnou nutností, kterou určitě dřív nebo později nahradí AI. (Zrovna minulý týden šla kolem nějaká manažroutská delegace, a když jim vysvětlili, že jsme IT pracovníci, tak si neodplivli jen proto, že jsou slušně vychovaní, a taky že ten koberec má větší hodnotu, než my.) -
Kolik z těchto velkých korporátů si myslíš, že to má procesně dobře vyřešené?
https://cs.wikipedia.org/wiki/Seznam_největších_zaměstnavatelů_v_Česku
-
Bral jsem, že toto vlákno je o efektivnosti korporátních předpisů, a s tím počet zaměstnanců velice hezky koreluje.
Naše firma je v první desítce a nemá ani předpis jak postupovat ani tu automatizaci... Takže předpokládáš špatně, firmy toto vyřešené obecně nemají, a když už, tak zhruba tak, jak psal RRŠ.
-
"No banky vsechny"
Lol ... tak proto sem volal do KB s tim, ze maji expirovany certifikat, nacez si me tam predavali jak horky brambor, snazili se zeme delat d.bila ... az me konecne prepojili na nejakyho ITka (presne mam pred ocima ITcrowd) a ten po pokusu ne poslat kamsi ... znicehoz rek ..."zkuste to za 15 minut". A sel ten cert vymenit.
Takze mi vykladej, jak maji neco procesne zvladnuty.
-
Filip JirsákStříbrný podporovatel
Někdo chce mít hodně aktuální seznam živých webů.
Přemýšlel jste nejdřív, než jste tohle napsal? Kdo je podle vás ten „někdo“? K čemu by mu ten seznam byl? Nemá náhodou daleko lepší prostředky, jak by takový seznam získal? Takové, které neselžou ani u hvězdičkových certifikátů? A opravdu má ten někdo takovou moc, aby zmanipuloval celé CA/B fórum? -
Filip JirsákStříbrný podporovatel
Škoda, že já jsem nepsal nic o veřejných webech. Každopádně kdyby chtěl Apple vytvářet seznam živých webů, má k tomu jako autor několika operačních systémů a prohlížeče mnohem lepší možnosti, než CT – který je navíc veřejný, takže ten seznam může využít a prodat úplně kdokoli. Takže z té vaší konspirace proti Applu (nebo možná proti Googlu, v diskusi se ukázalo, že konspirátoři mají problém přečíst si aspoň nadpis zprávičky) vyplývá, že by se Apple (nebo Google) vlastně zbavovaly své konkurenční výhody.
Mimochodem seznam webů, které nejsou veřejně dostupné, musí být opravdové terno – nevíte čí ten web je, co na něm je, jenom víte, že někde v internetu to doménové jméno někdo používá. Když budete mít štěstí, podaří se vám ho přeložit. Po takovém seznamu fakt všichni touží, a nejvíc touží po tom, někomu za něj zaplatit, i když si ho mohou stáhnout zadarmo.
-
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ě.
-
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.
-
Filip JirsákStříbrný podporovatel
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á. -
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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... -
Filip JirsákStříbrný podporovatel
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.
Asi jste nechtěl napsat cache, ale MitM útočník. No, právě proto se certifikáty používají, aby do toho nemohl vstoupit někdo uprostřed.certifikát na serveru s množstvím domén - změna by znamenala zápis do mnoha DNS,
Zápis do mnoha domén není problém. Není důvod mít v jednom certifikátu mnoho domén. A když se mění klíč pro certifikát pro větší množství domén, je úplně jedno, jestli jsou ty domény v jednom certifikátu nebo ve více – počet změn v DNS bude pořád stejný.certifikát vystavený pro více serverů za loadbalancerem, tedy více platných certifikátů se stejným jménem serveru...
To nijak nesouvisí s loadbalancerem, naopak loadbalancer obvykle množství veřejných certifikátů snižuje, protože jeden loadbalancer nahradí více serverů. Každopádně to opět není problém – můžete používat stejný klíč na více loadbalancerech, můžete dát do DNS více otisků klíčů nebo tam můžete dát otisk klíče certifikační autority (třeba vlastní). -
Měl jsem opravdu na mysli
cache
- například pro DNS dotazy. V takovém případě snadno dojde k tomu, že dostanete již neplatný otisk...
Řekněme, že máte servery s mnoha různými aplikacemi/weby. Některé jsou vytíženější, a tedy je nad nimi loadbalancer, jiné odkazujete napřímo. Na serverech je proto vždy certifikát, obsahující všechny weby zde běžící (jako aliasy). Počty webů na serverech se průběžně vyvíjejí, takže vždy vygenerujete nový certifikát, s novým seznamem aliasů. Například:
1. server = Adam, Bořena, Cyril + 22 dalších,
2. server = Adam, David, Emil, František + 36 dalších,
3. server = Božena, Emil, Gustav, Helena + 26 dalších,
jeden loadbalancer pro web Adam (na 1. a 2. server),
druhý pro server Božena (2. a 3.), oba provoz neterminující.
Každá změna na některém serveru znamená desítky zápisů do DNS.
Pro servery Adam a Božena potřebujete mít zapsané dva platné certifikáty.
(Pokud myslíte, že jde o hypotetický příklad, tak Vás ujišťuji, že je to příklad z praxe.) -
Filip JirsákStříbrný podporovatel
V takovém případě snadno dojde k tomu, že dostanete již neplatný otisk...
Nikoli. S běžnou dobou expirací záznamů v DNS cache (odpovídající tomu, co pro záznam uvádí autoritativní server), se počítá. Pokud někdo cachuje výrazně déle, než uvádí TTL, je to jeho problém.Některé jsou vytíženější, a tedy je nad nimi loadbalancer, jiné odkazujete napřímo.
Proč ten loadbalancer nedáte před všechny?s novým seznamem aliasů
Proč aliasy? Proč ne samostatné certifikáty pro každý alias?oba provoz neterminující.
Asi myslíte neterminující TLS. Opět – proč? Tím akorát omezíte možnosti loadbalanceru.Každá změna na některém serveru znamená desítky zápisů do DNS.
Jedině v případě, kdy budete cpát všechny názvy do jednoho certifikátu, pro každý certifikát použijete nový klíč a do DNS nedáte otisk klíče autority ale otisk klíče koncového certifikátu.Pro servery Adam a Božena potřebujete mít zapsané dva platné certifikáty.
Nepotřebujete. Ale když chcete, tak můžete. Nebo si tam dáte otisk certifikátu certifikační autority.Pokud myslíte, že jde o hypotetický příklad, tak Vás ujišťuji, že je to příklad z praxe.
Ano, i v praxi je možné něco nakonfigurovat tím nejblbějším možným způsobem. To je ale problém toho, kdo to tak konfiguruje.Jinak úplně stejně vám můžu dokázat, že nelze používat certifikační autority. Protože weby A, B, C musí mít společný certifikát od autority X a weby provozované na 1. serveru musí mít certifikát od autority Y a weby B a C nelze přesunout mimo server 1. Vidíte, důkaz, že TLS založené na certifikátech vydávaných certifikačními autoritami nemůže fungovat.
Jenže ono to funguje, akorát to nikdo nekonfiguruje tak blbě, jak jsem popsal. Stejně tak to nemusí nikdo konfigurovat tak blbě, jak jste popsal vy.
-
Pokud máte TTL 48 hodin, nemusíte si změny všimnout klidně celý den. Běžně máme na serverech TTL v řádu hodin...
Ten popsaný zmatek je prostě kompromisem, který vznikl jistým vývojem. Není to ideální, ale tak to prostě je - a změna by byla drahá. Jeden certifikát per server je prostě nejjednodušší řešení v daném případě - a také nejlevnější.
Ano, pak se certifikát mění často, pro všechny služby naráz.
Neterminující (nikoliv jen z pohledu TLS, ale spíše TCP) loadbalancery používáme naprosto běžně - jsou pro tok dat transparentní, což nám přináší některé výhody. Opět: je to dané aplikací - tedy nejedná se o standardní web.Zapsáním certifikační autority do DNS v podstatě zcela anulujete výhody tohoto řešení: nemáte jak zjistit, že certifikát je neplatný, nahrazený jiným.
15. 10. 2024, 21:27 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Pokud máte TTL 48 hodin, nemusí si klient změny všimnout klidně dva dny. Přesto to ničemu nevadí.
Aktualizace desítek DNS záznamů najednou (když už byste ji tedy chtěl provádět) také není něco, co by mělo složit nějaký DNS server.
Jak už jsem psal, nikde není řečeno, že se nové technologie musí přizpůsobovat současným blbým řešením.Třeba daleko častější problém, než to, co popisujete, je nutnost ruční výměny certifikátů. Přesto má Let's Encrypt platnost certifikátů 90 dnů a bude se zkracovat – a podle návrhu u všech CA. Holt ti, kteří musí certifikáty měnit ručně, to buď nějak dokážou zautomatizovat, nebo to budou muset měnit ručně dost často…
Navíc i kdyby se přidala možnost poslat otisk klíče už s odpovědí na DNS HTTPS záznam, ještě dlouho budou prohlížeče podporovat situace, kdy v tom záznamu otisk klíče nebude. Ony budou prohlížeče dlouho počítat s tím, že žádný HTTPS záznam nemusí existovat. Zatím se vůbec nemluví o tom, že by někdy mohl být povinný. Vždyť teprve asi před měsícem se vůbec uživatelé začali s HTTPS DNS záznamy potkávat, když to začal Cloudflare nasazovat na své free služby. Takže máte spoustu let na to z těch minimálně tří nevhodných řešení alespoň jedno změnit.
Certifikační autorita v DNS může být moje vlastí autorita. Pokud by došlo ke kompromitaci koncových privátních klíčů, můžu vyměnit i ty klíče CA.
-
DannyStříbrný podporovatel
Pokud mate u TLSA zaznamu nastavene TTL na 48 hodin, tak to proste delate blbe. TTL muzete mit pro kazdy zaznam v DNS jiny a samozrejme, nekde dava mit smysl TTL vetsi a jinde to je naopak nesmysl. Ono to nechce byt otrok minulosti a nesnazit se porad veci delat stejne jak pred dvaceti lety a pak nadavat, ze nove postupy a reseni maji "problem".
TLSA zaznamu muzete mit i nekolik, tedy samozrejme neni problem ani postupna rotace certifikatu zrovnatak neni vubec zadny problem. Mate to dokonce explicitne zminene v RFC 6698 v priloze A4 v prikladech... aneb vase argumenty jsou z kategorie "ajtaka", co ani necte dokumentaci, ale pritom ma "jasno".
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
OCSP stapling. Protože Let's Encrypt plánuje podporu OCSP zrušit. Samotné OCSP v prohlížeči zpomaluje zobrazení stránky a prozrazuje CA, kdo který certifikát chce ověřit (tedy kdo se dívá na jaký web). Kdyby se to používalo správně, tedy že certifikátu důvěřuju teprve tehdy, když CA potvrdila jeho pravost, přestává web fungovat jako decentralizovaný systém a z CA se stává single point of failure. Pokud by se používal jen OCSP stapling, odstraní se problém únikem informací, kdo na jaký web přistupuje, ale single point of failure zůstává.
-
Prave tymto skracovanim vznika single point of faliture a to vo forme Lets Encrypt repektive Googlu (ktory kazdy rok meni pravidla tak aby vysachoval ostatne CA-cky). CA-ckok je vela a su decentralizovane, navyse ide fallbaknut na CRL.
Nemyslim si, ze by to spomalovalo nacitanie webu, ved o OCSP sa postara server a OCSp odpoved ma nejaky cas platnosti (radovo hodiny), takze ide znovupouzit.
Aj aj tento problem by slo riesit tym, ze ked sa teraz certifikaty akceptuju bez ohladu na revokaciu 40 dni, preco by sa nemohli akceptovat certifikaty platne 5 rokov s tym, ze od posledneho overenia platnosti ubehlo maximalne 40 dni?
-
DannyStříbrný podporovatel
Proc vysachovat CA? Vzdyt existuji i otevrene impleme ACME certifikacnich autorit, tedy nic nikomu nebrani si provozovat i svou vlastni (privatni) automatizovanou CA.
Ad OSCP a CRL... podivejte se do historie, jak to vznikalo. CRL bylo pred OSCP, pak se prislo s OSCP prave proto, ze CRL moc v praxi nefungovaly. Duvod odklonu od OSCP je primarne ochrana soukromi, aneb jeden problem se sice vyresil - ale na ukor vytvoreni problemu jineho.
-
Filip JirsákStříbrný podporovatel
Ne, zkracováním nevzniká single point of failure, protože i v té nejkratší variantě bude platnost certifikátu 45 dní, můžete ho měnit třeba po 30 dnech, takže budete mít pořád 15 dní na řešení případných problémů. Navíc máme ACME, takže přejít na jinou autoritu nebude problém – naopak to bude daleko snazší, než dnes (protože to budou muset implementovat všechny autority).
Google žádná pravidla nemění, navíc nemá žádnou certifikační autoritu.
V okamžiku navazování spojení nejde udělat fallback na CRL – to byste musel mít CRL už stažené.
O OCSP se nestará server, dělá to klient. Server se případně stará o OCSP Stapling, který je ovšem závislý na OCSP.
Myslel jsem si, že při OCSP Stapling je validita odpovědi v řádu minut. Teď jsem si to dohledal, že se běžně používá potvrzení s platností 7 dnů – tím pádem je to pro rychlé odvolání certifikátu stejně nepoužitelné.
Zavádět v prohlížečích novou závislost na ověřování platnosti certifikátu nedává smysl, když to nyní nefunguje a prohlížeče to používají buď volitelně nebo vůbec. Revokace certifikátů ze strany CA je zkrátka v online komunikaci nevyřešený problém a zkracování platnosti certifikátů je zatím jediné reálné řešení.
-
Filip JirsákStříbrný podporovatel
Jestli má ten ajtík vše tak dokonale vyřešené, že za sebe nepotřebuje během dvoutýdenní dovolené zástup, jistě zvládne mít i bezchybný automat na výměnu certifikátů. Nebo ten certifikát taky může měnit automaticky po 15 dnech, takže bude mít na řešení problému 30 dnů. To si pak může vzít čtyři týdny dovolené v kuse a ještě ten problém stihne vyřešit.
-
Jestli tohle projde, tak ACME 2 vypadá jako cesta kupředu / perspektivní způsob přežití.
A v takové situaci mi bude připadat bizardní, proč není nějaký kanonický ACME klient součástí např. OpenSSL a serverových vindózů (ať už IIS nebo přímo samotného OS). Proč se k tomu musí používat tvorba třetích stran. I když... sice se na jednu stranu mohu ošklíbat nad Pythonem (CertBot) nebo .NET (win-acme), na druhou stranu si nejsem vůbec jistej, jestli bych radši řešil budoucí bugy v 3rd-party projektu co má repo na GitHubu, vs. v nějaké standardní součástce Windows :-D vs. v nově vyvstalém problému 3rd-party softwaru po aktualizaci Windows... pick your poison. Možná je pozadu především můj mindset = provozovat si svůj vlastní server jakéhokoli druhu. Tzn. operátoři cloudových služeb se taky usmívají.
-
DannyStříbrný podporovatel
A proc by mel byt ACME soucasti OpenSSL? Jednak je to tak trosku proti unixove (KISS) filosofii, druhak OpenSSL neni zdaleka jedinou implementaci SSL/TLS. K tomu prvnimu staci uz jen dodat, ze je lepsi delat jednu vec a delat ji poradne... nez spoustu veci v ramci jedne binarky, kdy se pak dost zvetsuje prostor pro chyby.
-
Filip JirsákStříbrný podporovatel
Kanonický ACME klient je Certbot. Nevidím důvod, proč by měl být součástí knihovny OpenSSL, ani součástí Windows – vždyť je to aplikace jako každá jiná. No a pokud používáte rozumný software, žádný software třetích stran pro ACME nepotřebujete. Takový Caddy server má podporu ACME vestavěnou, funguje perfektně a v základní variantě bez jakékoli konfigurace. Prostě jenom nastartujete server. Nějaká kanonická implementace přibalená k něčemu by pro mne byla úplně zbytečná.
-
Ohledně Caddyho - to je masakr. Už to animované intro na homepagi projektu. Nenapadá mě netrollí komentář :-)
Moje zarezlé šedé závity dumají, kam se nám posouvá celý ten příběh o delegaci důvěry, o autenticitě a odpovědnosti. Co bude dál - indikační ikonka se zámečkem vedle adresního řádku bude mít barvu pozadí ze spojitého intervalu červená-zelená, a při přejetí myší sdělí vyskakovací bublina, kolik provozovatel webu utratí ročně za certifikát? :-) -
-
Především si vážím Vašich reakcí - jsou vždycky technicky precizní a informačně hodnotné.
Z mé strany... narážím na obecný koncept "chain of trust", a jak se postupně rozpíjí. Pozoruji zvenčí z povzdálí ten vývoj PKI ekosystému:
- jenom důvěryhodné velké CA
- no dobře, tak přijmeme do klubu i pár levnějších hráčů
- ale ne aby si každý mohl zřídit veřejnou CA sám pro sebe a automaticky byl důvěryhodný a všeobecně uznávaný (v prohlížečích i jinde) - to zas ne
- pak vznikne software a "organizační mechanismus", který velkému provozovateli (hostingů apod.) dá možnost, objednávat certifikáty automatizovaně, téměř samotížně. Takový provozovatel uzavře rámcovou smlouvu s uznávanou CA. Takže následně CA vystavuje důvěryhodné certy všem požadavkům od daného velko-provozovatele hostingů.
- a pak tu automatizaci ve velkém přijme prostý lid (jako já), protože bez automatizace by člověk nedělal nic jiného než ručně aktualizoval certy.Podle mého vzniká spektrum různě důvěryhodných certů - odstupňované podle toho, kolik peněz a úsilí držitel certu vynaložil na pořízení certu. Automatizace povede k "úsporám z rozsahu". Certy budou levnější. Přitom celý boj proti spamu a příbuzným činnostem je založený na tom, že se drží jakási nákladová bariéra, kterou se šmejdům nevyplatí překonávat.
-
Filip JirsákStříbrný podporovatel
Certifikáty nejsou rozlišené podle toho, kolik peněz nebo úsilí vynaložíte na jejich získání.
Certifikační autority byly založené na tom, že delegujete ověřování na někoho, komu důvěřujete. Pak se ukázalo, že CA je čím dá víc a není možné, aby si každý člověk udržoval svůj vlastní seznam důvěryhodných certifikačních autorit – například proto, že typicky nemá jak by důvěryhodnost CA posoudil. Takže ten výběr důvěryhodných CA delegoval na někoho, komu stejně důvěřuje – autora operačního systému nebo prohlížeče. No a ti zase potřebovali nějaká jasná pravidla, co musí CA splnit, aby jí důvěřovali – jednak aby nezklamali důvěru uživatelů, kteří na ně spoléhají, jednak aby to bylo nějak věrohodné a predikovatelné a nezáleželo to na tom, koho z firmy se zrovna podaří nějaké CA ukecat. Takže třeba Microsoft nebo Mozilla mají svá pravidla pro to, kdy zařadí certifikát CA mezi důvěryhodné autority, a kdy ho naopak vyřadí. Pokud nějaká CA o zařazení požádá a pravidla splní, na seznam se dostane.
Kdyby si každý mohl zřídit svou vlastní důvěryhodnou autoritu, nefungovalo by to, protože ne každému můžete důvěřovat. Ostatně kdybyste každému mohl důvěřovat, nejsou potřeba žádné certifikační autority, žádné certifikáty, žádná šifrovaná komunikace.
Mechanismus pro automatizované vydávání certifikátů ACME nevznikl kvůli velkým provozovatelům. Ti největší si vydávali svoje certifikáty už předtím sami. (Měli svou autoritu, jejíž certifikát podepsala nějaká uznávaná autorita.) AUtomatizované vydávání certifikátů vzniklo proto, aby certifikáty mohly být co nejlevnější (ideálně zadarmo), aby si je mohl dovolit každý a bylo možné celý web dostat na HTTPS. Když chcete certifikáty vydávat levně, musíte je vydávat automaticky, protože lidská síla je to nejdražší.
Důvěryhodnost certifikátů není přímo úměrná ceně a nákladům na vystavení certifikátu. Pro mne je Let's Encrypt určitě důvěryhodnější, než čínská autorita. Ale když kterákoli z nich vydá certifikát pro portal.gov.cz, prohlížeč protestovat nebude.
Se spamem to nijak nesouvisí. Účelem TLS certifikátů je zajistit jenom to, že komunikuju s tím, s kým si myslím, že komunikuju. Jestli je to padouch nebo hrdina, to certifikáty neřeší.
