Uniklý klíč z dumpu z dubna 2021 je úspěšně použitý pro podepsání tokenu v červnu 2023, tj. po více než dvou letech? Co nějaký key rollover?
Navíc u takto citlivého klíče bych čekal, že bude uložený v HSM a v paměti (serveru) se tudíž nikdy vyskytovat nebude - může se tu jednat samozřejmě o paměť a crashdump toho HSM, to se z vyjádření jednoznačně určit nedá, zmiňují to tam jako "signing system", což může být jak podepisovací server tak HSM za ním. Každopádně následné nakládání s dumpem je jednoznačné selhání.
Klice CA se prece taky nerotuji po roce, vsak se podivejte jakou platnost maji "duveryhodne" autority ve vasem prohlizeci. Ano, bylo by ocekavatelne, ze podobne citlive klice budou v HSM, ale v praxi to holt byva tak, ze se casto hledaji zpusoby, kterak nekde usetrit... :-) A pokud by crashdump HSM obsahoval privatni klice, dost by to popiralo smysl jeho existence... a myslim ze i Microsoft by se to pak snazil hodit na jeho vyrobce... ale to se nedeje :-)
CA je něco jiného než služba, která podepisuje autentizační tokeny. Rozdíl je třeba už jen v době platnosti jimi podepisovaného materiálu. Mimochodem, defaultní nastavení microsoftího ADFS je rotace token signing certifikátu včetně klíče právě po jednom roce.
Se zbytkem souhlas.
11. 9. 2023, 20:00 editováno autorem komentáře
Pokud myslíte úložiště důvěryhodných certifikátů, tam by datum expirace certifikátu nemělo mít žádný vliv. Datum expirace je u takových certifikátů nadbytečný údaj a je u certifikátu uváděno jenom proto, že je to povinná položka certifikátu. Certifikát je důvěryhodný tím, že ho do úložiště důvěryhodných certifikátů umístíte, na ničem dalším nemá záležet. Pokud certifikát za důvěryhodný nepovažujete, nemá v úložišti důvěryhodných certifikátů vůbec být.
Určitě? Máte k tomu zdroj? Ruku do ohně za to nedám, ale myslím, že jsem kdysi musel řešit expirovaný root CA certifikát, který expiroval dřív než koncový certifikát. (Šlo o interní CA, ne o nějakou běžně uznávanou.)
Spíš bych tipoval, že je to kvůli časovému razítku, které dokazuje, že podpis proběhl před expirací – pak dává smysl, že systém potřebuje ověřovat i dnes již expirované certifikáty.
Tak treba u Androidu to uplne neplati, ze...? Kdyz jsme u toho, kdo tady blaboli.
Ta expirace certifikatu se dela treba z duvodu bezpecnosti, treba md5/sha1 se jiz nedoporucuje pouzivat a proto se expirovanym certifikatum nema duverovat. Duverovat expirovanym certifikatum neni best practice a ze se to relativne bezne deje je tim ze lidi dane problematice nerozumi. Za svuj zivot jsem videl v aplikacich duveru vuci certifikatu zalozenou na naprosto cemkoliv vcetne emailu.
Dané problematice evidentně nerozumíte vy. Např. použitý hashovací algoritmus s tím vůbec nijak nesouvisí, a pokud někdo vydal certifikát podepsaný MD5 s platností do roku 2200, ten certifikát expiruje až v roce 2200. Navíc to bezpečnost nijak neohrožuje, protože do úložiště důvěryhodných certifikátů sice dáváme certifikáty, ale důležitý je jen veřejný klíč – vše ostatní je tam buď pro rychlejší nalezení veřejného klíče, nebo úplně k ničemu.
JSH: Jediná věc, kterou napsal bez prezdivky… správně, je to, že časové razítko je jen zvláštní forma elektronického podpisu. Tedy nemusíte nic kontrolovat u notarizační služby, stejně jako u ní nekontrolujete podpisy. Zkontrolujete, že podpis u časového razítka sedí a že byl vytvořen s pomocí privátního klíče příslušejícího k veřejnému klíči uvedenému na certifikátu autority časových razítek. A pak zkontrolujete, zda certifikát autority časových razítek vydala některá z autorit, které důvěřujete. Pokud je vše splněno, víte, že časové razítko vydala důvěryhodná autorita časových razítek, tudíž že můžete důvěřovat času uvedenému v razítku a že objekt opatřený časovým razítkem existoval před okamžikem uvedeným na časovém razítku. Takže třeba podpisy chráněné časovým razítkem můžete ověřovat k času uvedenému na razítku, protože víte, že už v té době podpis existoval.
"ako chciet od CA vydat falosny certifikat."
Coz zvladne kazde male dite ktere zvlada email. Sectigo ... staci ti email na domene pro kterou chces cert. Asi ti nevydaj cert na proflaknuty domeny (google ....) ale na jakoukoli jinou lusknutim prstu. Ve skutecnosti ti staci kdyz ses z toho emailu schopen ziskat link. Takze nemusi byt ani tvuj a staci ti na to par vterin u neciho emailu.
A to je jen priklad ... takze mi povidej, jak strasne nemozny je ziskat henten "duveryhodny" cert.
To bych chtěl vidět. Minimálně na https://www.sectigo.com/ssl-certificates-tls/dv-domain-validation tvrdí něco jiného.
Vít Šesták: Ověřování CAA záznamů je od roku 2017 podmínkou toho, aby certifikační autorita byla zařazená mezi důvěryhodné certifikační autority v prohlížečích. Takže není nutné to zjišťovat v podmínkách každé CA zvlášť. A je úplně jedno, co si tu komentující „j“ vymyslí za nesmysly.
Coz zvladne kazde male dite ktere zvlada email. Sectigo ... staci ti email na domene pro kterou chces cert. Asi ti nevydaj cert na proflaknuty domeny (google ....) ale na jakoukoli jinou lusknutim prstu. Ve skutecnosti ti staci kdyz ses z toho emailu schopen ziskat link. Takze nemusi byt ani tvuj a staci ti na to par vterin u neciho emailu.
Když to zvládne každé malé dítě, proč to nezvládnete vy? Nestačí vám libovolná e-mailová schránka na dané doméně – Sectigo pro validaci používá jenom pět vyjmenovaných názvů schránky. Takže vám nestačí pár vteřin u něčího e-mailu, ale muselo by to být u e-mailu admina dané domény nebo webu. Aby vás nějaký admin nechal u svého e-mailu, musel by být podobný nedouk, jako vy. A takovému adminovi byste podobným způsobem nejspíš dokázal ukrást i celou doménu (teda vy ne, ale někdo jiný).
No a pak tu máme třeba CAA DNS záznam, kterým můžete určit, kdo může pro danou doménu vydávat certifikáty. Takže si se Sectigo neškrtnete, pokud je příslušná doména sama nepoužívá – a pokud ano, asi její správce ví, že si má e-maily pohlídat.
No a pak tu máme ještě Certificate Transparency, ze kterého byste se o falešném certifikátu dozvěděl. Tedy vy ne, ale někdo, kdo problematice rozumí.
A to je jen priklad ... takze mi povidej, jak strasne nemozny je ziskat henten "duveryhodny" cert.
Celou dobu je řeč o certifikátech pro podpis softwaru. Vy jste najednou přišel s DV certifikáty. Proč? Odpovím si sám – protože nechápete rozdíl.
Vis tupy jirsaku, zazil sem to opakovane, umyslne jsem vygeneroval zcela nahodny email a certifikat by vydan. Ale jestli chces abych ti to dokazoval, udelam ti cenu ...1M Eur se specielni slevou protebe ... na 1G Eur.
Stejne tak jako tupy jirsak samozrejme netusi, ze systemu je uplne urite jestli jde o web nebo o podpis aplikace, podstatne je, ze prislusny certifikat kterym to bylo podepsano miri k CA ktera je oznacena za "duveryhodnou" ...
CAA samozrejme naprosto ignoruji, coz jsem si taktez overoval.
Vaše pohádky o tom, co jste zažil, jsou irelevantní, když problematice nerozumíte a nedokážete tedy interpretovat, co se vlastně stalo. Navíc pro svá tvrzení nemáte žádné důkazy.
Certifikát pro podpis aplikací musí mít jako účel užití uvedeno code signing, zatímco TLS certifikát tento účel mít nebude a naopak bude mít v rozšířeném použití uvedeno, že je to serverový TLS certifikát.
CAA záznam se také vztahuje jenom k serverovým TLS certifikátům.
bez prezdivky ...: Prázdný sud nejvíc duní. Pokaždé, když napíšete nějakou hloupost, začnete nadávkami ostatním.
Ano, časové razítko je podpis. Ale není to podpis váš, je to podpis autority časových razítek. Která se zavázala k tomu, že bude podepisovat pouze časový údaj shodný s celosvětově koordinovaným časem.
Takže otázka je pořád stejná – jak donutíte autoritu časových razítek, aby vám vydala časové razítko v minulosti?
V prvé řadě by člověk čekal, že Microsoft bude psát kód tak, aby pokud možno nepadal. Potom by předpokládal, že bude dumpy kompetentně čistit. Potom by čekal, že bude vývojové prostředí celkem bezpečné a ne tak prolezlé, že výskyt klíče v nějakém random dumpu je hned problém globálních rozměrů.
Takže efektivně Microsoft přiznal, že už nemá nad ničím kontrolu, protože mu ve vývojovém prostředí sedí či seděla nejméně jedna mocnost, která měla dostatečnou úroveň znalosti, že z random dumpu vytáhne ten správný klíč. Sám Microsoft připouští, že počítačům s jeho softwarem nelze věřit. Po tomto incidentu a jiných, jako https://www.wiz.io/blog/chaosdb-explained-azures-cosmos-db-vulnerability-walkthrough bych se hodně zamyslel, jestli se dá Microsoftu/ Azure věřit vůbec v nějakém ohledu. Firmě, která za 30 let existence svého operačního systému neumí kompetentně vyřešit updaty. Kombinace Windows, Office, Active Directory, Exchange/ Outlook, Edge, MS Teams atd. jsou očividně děravé jak řešeto a to i přímo uvnitř Microsoftu. Jak máme vyžadovat určitou úroveň po firmách, které mají zlomek možností Microsoftu včetně třeba toho, že ty produkty nepíšou a že nemají miliardové rozpočty na bezpečnost.
NÚKIB by měl z dlouhodobého hlediska největší přínos, kdyby z důvodu státní bezpečnosti nasazení softwaru Microsoftu v Česku plošně zakázal, dokud Microsoft produkty nepřepracuje, aby to nebyly takové bastly. Začít by mohli třeba tím, že bude možné Windows a všechny stěžejní aplikace updatovat za běhu.