Vlákno názorů k článku Google chce omezit platnost certifikátů na 90 dnů, změna zřejmě přijde brzy od Ondro - Neviem, mozno sa na to zle pozeram ale...
-
Neviem, mozno sa na to zle pozeram ale nevidim dovod extremne skracovat platnost certifikatov. 10 rokov bolo vela ale aj tych 10 rocnych sa dalo zbavit pdoobne ako to urobil Apple so Safari. Plus nikto pricetny necakal 10 rokov na ani jeden strane. Bud ich prestal akceptovat alebo vymenil za nieco novsie. To sa aj dialo.
Ak pride nejaka horzba, tak nikto nebude cakat kym automat nepoziada o tyzden novy certifikat. Plus, ci ten automat bude k niecomu, lebo dana sluzba/zariadenie nemusi zvladat novy typ certfikatu.
Z mojo pohladu vidim potencialne rizko pri extremne kratkych certifkatov. Co ak sa nieco udeje so systemom vydavani certfikatov? Extremen kratkymi certifikatmi si vieme podpilit konar pod sebou.
Plus co usetrime na revokaciach to pridame na zvysenom objeme vydavani certfikatov a automatizacii.Vlastne co tym vyriesime? Mame tu Let's Encrypt a 90 dnove certfikaty ale ved od nich si viem ziskat certifikat bez problemov na v podstate cokolvek rychlo a jednoducho. Vdak nim asi kazdy sifruje ale to je tak vsetko.
-
DannyStříbrný podporovatelPrecitajte si to znovu :-) Ne, zbavit se jich jednoduche neni. A ani Apple neni takovy buldozer, ktery by na hulvata zrusil platnost drive vydanych - lec stale platnych - certifikatu. Nova omezeni se vzdy zavadela pro nove vydane certifikaty...
Co za riziko tam je? Jestli jsou to tri mesice nebo ctrnact dni je uz vlastne z pohledu obnovy fuk, to stejne resi automat. Muzete mit klidne paralelne dve nezavisle CA, ze kterych si ten certifikat ziskate, kdyz chcete byt opravdu paranoik.
Revokacni seznamy moc nefunguji, to je proste fakt. Mate jine reseni? Od CRL se udelal pokus smerem k OSCP, ale v srpnu 2023 z toho CA/B vycouvalo a pokorne se k CRL vratilo. I pres jeho zname mouchy...
Ano, ucelem je vyresit sifrovani - protoze nic "navic" realne take nefunguje... zelene zamecky se jmenem firmy u EV certifikatu? Hahaha, to BFU stejne nezkouma. Co vic nez zasifrovani transportu tam od toho certifikatu cekate?
-
> Co vic nez zasifrovani transportu tam od toho certifikatu cekate?
No ja som povodne od certifikatov ocakaval ze skutocne certifikuju kto so mnou komunikuje takze minimalne ked som na nejakom webe banky alebo platobnej brany tak sa tam pozriem a certifikacna autorita naozaj oznaci ze majitelom je banka X alebo skutocna platobna brana nie nejaky fake web. -
DannyStříbrný podporovatel
A to je presne ta vec, co nikdy poradne nefungovala ;-) Jako byste to z praxe neznal, lidi ochotne odklikaj i neplatnej certifikat, jen aby se nekam dostali a je jim to fuk. To, ze jsou nakonec jinde nez chteli zjisti az pote, co se fakt stane nejaky pr*s*r... no a ze si to par geeku opravdu zkontroluje to nevytrhne.
-
Je rozdíl, když tam někdo kliká z neznalosti a někdo s vědomím že si nutně chce třeba přečíst blogový zápisek a nebude tam zadávat žádné informace.
Otázka zabludišťáka:
co byste si vybral kdyby bylo na výběr:
1. HTTP
2. https s neplatným certifkátem (expired)
3. totéž ale certifikát na generické jméno hostingu
4: totéž ale na zjevně divné jméno certifikátu (TLD jako .click,.store,...)
5. totéž ale https s špatnými šiframi(případně jen volba 1 vs 2-5)
-
Filip JirsákStříbrný podporovatelJe rozdíl, když tam někdo kliká z neznalosti a někdo s vědomím že si nutně chce třeba přečíst blogový zápisek a nebude tam zadávat žádné informace.
To není rozdíl, to je v obou případech neznalost.Něco jiného by bylo, kdyby si někdo nutně potřeboval přečíst cokoli, co někdo může podvrhnout na adrese blogového zápisku. V takovém případě ale zase není potřeba řešit neplatný certifikát a stačí si přečíst něco z
/dev/random. -
Smazaný profil
tak jasně, budu si chtít přečíst blogísek o vaření, ale s neplatným certifikátem nebo přes http jsem ohrožen podvrženým receptem, který mě speciální vražednou kombinací mouky, másla a tří vajec otráví a s ohledem na osobní bezpečnost raději vygeneruju mnohem bezpečnější recept podle /dev/random....
13. 9. 2024, 08:35 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
To, že upečete sraženou buchtu údajně podle receptu uznávaného šéfkuchaře, je ten menší problém. On to ale může být také blog uznávané osobnosti o tom, zda investovat či neinvestovat do bitcoinu, do čeho jiného investovat, jak danit příjmy z bitcoinu, jak se vyvíjí válka na Ukrajině, že nějaký politik udělal nějaký přešlap. Že jsou to drobnosti? Ano, jsou, ale když se těch drobností sejde spousta… Proč asi Rusko podporuje lidi, kteří šíří bludy o ploché Zemi, chemtrails, o neexistenci globální změny klimatu, proti Green Dealu? Protože jim jde především o to vytvořit chaos, aby lidé nedůvěřovali institucím ani sami sobě navzájem.
-
Smazaný profil
vy se tu snažíte tvrdit, že nedostatečně zabezpečený přenos je nepřekonatelný problém za všech okolností, tak jsem vám ukázal, že fakt neni. Šířit bludy můžete i na webu, který aktualizuje certifikát každou hodinu. Motat do diskuze o certifikátech plochou zemi a chemtrails už je na návštěvu odborníka.
-
Filip JirsákStříbrný podporovatel
Ne, pokud vám na přenášeném obsahu nezáleží, pak nezabezpečený přenos problém není. Akorát je pak otázka, proč chcete přenášet něco, na čem vám vůbec nezáleží.
Šířit bludy samozřejmě může i web, který má zabezpečený přenos. To ale nevyvrací, že by web, který bludy nešíří, měl používat zabezpečený přenos, protože jinak informacím na webu uvedeným nemůžete věřit.
Vy jste komentář do této diskuse také psal s předpokladem, že ostatní uvidí právě to, co jste napsal, a ne něco jiného.
-
Když by browsery podporovaly DANE, tak by revokaci mohl udělat vlastník certifikátu odstraněním záznamu v DNS. Pro takové certifikáty by se pak klidně mohla zachovat dlouhá platnost.
Ostatně tenhle princip se používá u SMTP, viz RFC 7678
SMTP servers cannot expect broad Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) support from SMTP clients. As outlined above, with DANE, compromised server or trust anchor keys can be "revoked" by removing them from the DNS without the need for client-side support for OCSP or CRLs.
-
DannyStříbrný podporovatel
No, ano... ale to by si kaprici (CA/B) vypustili svuj rybnik a to bohda nedopusti :-) Protoze v ten moment by nebyly potreba komercni CA... s DANE si muze kazdej provozovat vlastni... to uz holt s technikou nic spolecneho nema (reseni je uz dlouho), to je uz jenom politika (nektere zajmove skupiny o takove reseni nestoji).
-
No, takže máme problém, nechceme ho opravdu řešit, tak vymyslíme pseudořešení s postupným zkracováním platnosti v principu nevyhovujícího systému. Takže dneska na 90 dní, za půl roku na 60 dní, za rok na 30 a nakonec budeme obnovovat certifikáty po 60 sekundách...
A pak teda možná přejdeme na online ověřování s tím, že stejně budou existovat CA, které vydají doménový certifikát komukoliv, kdo má kontrolu nad kořenem webové prezentace, takže budeme mít zcela důvěrnou komunikaci se zcela nedůvěryhodným podvodníkem (podobně jako když Google odmítá ze svých služeb odstranit zjevně podvodné reklamy na investování s ČEZem, protože "jejich podmínky" inzerent prý neporušuje).
No nevím, jestli je tohle opravdu řešení problému, nebo spíš typické "papírově něco děláme, aby to vypadalo, že chceme problém řešit, což reálně nechceme, ale vytvořením dalších byrokratických překážek to aspoň skrýváme". V reálu si myslím, že Google jen testuje svou sílu a vliv na globální internet.
11. 9. 2024, 08:10 editováno autorem komentáře
-
No taky to tak vidím...
OK - deset let platnost certifikátů je blbost, roční je ideální. Tam, kde je vysoké riziko zneužití ať si to stáhnou klidně na 21 dní nebo 10...
Ale netuším proč musím co 90 dní měnit certifikáty, kam mi ve výsledku stejně leze jen dodavatel... Ta logika mi prostě uniká... Zbytečně to věci komplikuje, přestože není třeba tam mít tak "ostré" lokty. Možná by se měli zamyslet k čemu ten certifikát ten uživatel vlastně potřebuje a podle toho dělat délky platností,,,
-
Filip JirsákStříbrný podporovatel
Pokud se nainstaluje certifikát té CA jako důvěryhodný (do systému nebo do prohlížeče, podle toho, odkud je prohlížeč bere), tak ne. Bude důvěřovat té autoritě, a na certifikáty od lokálních autorit (těch, které si doinstalujete sám) se ta pravidla o platnosti certifikátů nevztahují. Podobně byla dlouho výjimka na SHA-1 certifikáty – certifikáty vydávané oficiálními autoritami už nesměly používat SHA-1, ale certifikáty vydávané lokálními autoritami mohly SHA-1 dál používat.
-
Filip JirsákStříbrný podporovatel
Apple tvrdí něco jiného:
This change will not affect certificates issued from user-added or administrator-added Root CAs.
-
Filip JirsákStříbrný podporovatel
To bola az druha zmena, to pisu o skrateni platnosti na 398 dni. To sa netyka prvej zmeny, nastavenia limitu 825 dni, ten stale plati.
Ano, bavíme se o té lhůtě 398 dní. Pardon, pokud jsem to napsal nejasně – není to tak, že by pro interní certifikáty neplatila žádná pravidla, ale ta pravidla nejsou tak přísná, jako pro veřejné autority. Respektive ta pravidla se nejprve vynucují u veřejných autorit (přes CA/Browser Forum), teprve později se začnou uplatňovat i u interních autorit. -
Filip JirsákStříbrný podporovatel
toto znie ako use-case pre vlastnu CA
Není. Za prvé tím přiděláte práci i dodavateli, musí dostat váš certifikát mezi důvěryhodné certifikáty na svých zařízeních. V jednodušším případě do systémových úložišť, ve složitějším přímo do aplikací.Co je ale důležitější, bezpečák dodavatele by měl instalaci certifikátů vaší autority odmítnout. Protože v praxi se nepoužívá omezení, pro které domény může která CA vydávat certifikáty. Nebo-li když dostanete certifikát své CA jako důvěryhodný do nějakého systému dodavatele, můžete pak tím certifikátem podepsat třeba doménu google.com, a systém dodavatele tomu certifikátu bude věřit. Nevím, jestli máte s dodavatelem tak dobré vztahy, aby vám až takhle věřil…
-
Filip JirsákStříbrný podporovatel
Já těch 90 dnů považuju za dolní hranici toho, co dává v současné podobě smysl. Protože certifikát je z principu něco, co stvrzuje stav v nějakém okamžiku a předpokládá se, že to bude platit i nějakou dobu v budoucnosti.
Pokud je potřeba záruka, že provozovatel webu je oprávněným držitelem domény právě teď, nedává smysl spoléhat se na certifikáty s delší dobou platnosti, ale je potřeba ty informace přenášet přes DNS, aby byly stejně aktuální, jako DNS. Tj. použít protokol DANE. Protože z tohohle pohledu je 14 dní stejně dlouhá doba, jako 90 dní. Pokud se chci na HTTPS certifikáty absolutně spolehnout a řešit i případy, že někdo prodá doménu nebo unikne privátní klíč certifikátu, pak je mi jedno, jestli se někdo bude moci prokazovat neplatným certifikátem 14 dnů nebo 90 dnů – i těch 14 dnů je dost na to, aby mohl napáchat škody.
