Z principu je špatně, že si Firefox sám ověřuje certifikáty, IE i Chrome využívaly služeb OS.
Teď je z toho kočkopes, kdy prohlížeč řeší spoustu věcí, které vůbec řešit nemá (kromě certifikátů např. DoH) a spousta dalších aplikací podobné bezpečnostní mechanizmy nepoužívá. Mělo by se tlačit na tvůrce OS, který se má o tohle starat.
Ale ved OS to ma davno vyriesne (DNS a OCSP). Lenze tvorcovia prehliadacov vramci akoze boja za sukromie si vsteky tieto prvky tlacia k sebe (vsak kto sa o vase sukromie postara lepsie ako firma predavajuca data svojich pouzivatelov?), toto je len dlasia snaha gigantov z decntralizovaneho internetu si spravit svoj monopol, kde maju pod kontrolou vsteko od serverov, cez prenosovy kanal az po browser, ktory obcas aj zobrazi HTML.
Těžko efektivně tlačit na výrobce OS, dokud to žádný prohlížeč nepodporuje. Těžko propagovat něco vázaného jen na určité kombinace prohlížeče a OS. Těžko získávat čerstvý seznam certifikátů přes OS, pokud by to tvůrci OS řešili přes systém stahování aktualizací, kdy aktualizace může nepříjemně překvapit, třetina aktualizací může vyžadovat restart a rozhodně není žádoucí to podstupovat několikrát denně. Z principu je to v tuto chvíli dobře.
Tato funkce prohlížeče by na rozdíl od DoH neměla nijak zasahovat do soukromí, takže není důvod tvůrce podezřívat z postranních úmyslů.
A OS nějakou takovou službu poskytuje? Ten můj bohužel ne, můžeš používat systémové openssl, ale to žádné takovéhle kontroly nedělá.
No a stejný problém je s DNSSECem. Tam je navíc problém že API operačního systému (takové ty funkce rodiny gethostbyname) neposkytují informace "ověřeno DNSSEC", "ověření selhalo" (nelze odlišit od jiné chyby) atd., ne?
Samozřejmě, že slyšel. Ovšem OCSP stapling řeší jen část problémů: zátěž na responderech, prodlevu na klientské straně a únik informací. Ovšem nepříjemná závislost na funkčních responderech zůstává, časová prodleva při revokaci taky. Navíc samotný stapling neřeší hlavní bezpečnostní problém: když útočník ukradne soukromý klíč a vytvoří si falešný server, nebude stapling posílat a tím je to pro něj vyřízené.
Tohle se zase snaží řešit rozšíření do certifikátů lidově zvané must-staple, které nutí webové servery, aby ten staple posílaly. Problém je, že klienti se zase spokojí s tím, že tam ta informace není. Prostě soft-fail v OCSP postihuje i stapling. Navíc dominantní Chrome nevaliduje OCSP už deset let vůbec.
Další problém je ve webových serverech, které často stapling neimplementují dobře. Selžou třeba při nedostupnosti responderu, třeba Apache je ochoten zahodit stále ještě validní odpověď, když dostane od responderu chybu nebo prázdnou odpověď. TLS do verze 1.2 včetně k tomu umí poslat jen jedno SCT na jeden TLS handshake, což u mezilehlých certifikátů nestačí. Tohle se naštěstí řeší v TLS 1.3 díky rozšíření MCSR.
Prostě myšlenka dobrá, ale má taky spoustu vlastních problémů.
Problém je i s revokací certifikátů pro podpisy. Ty je občas potřeba ověřovat k minulému času (třeba z razítka). K tomu je potřeba staré CRL, protože expirované certifikáty v současném CRL už nejsou. Obecně je to tak, že po odvolání se s nějakým zpožděním certifikát v nějakém vydání CRL objeví. Po čase zmizí, nejspíš po expiraci. Není ale vyloučeno, že zmizí dřív a že se zase objeví.
Pro nedůvěru stačí existence CRL s daným certifikátem a to ještě ve vztahu k času ověření.
Pro důvěru nestačí nic, protože nevíme, zda takové CRL existovalo, jen ho nemáme k dispozici.
Certifikát z CRL nemůže zmizet a zase se objevit (pokud se nebavíme o pozastavení platnosti certifikátu, ale to se při zpětném ověřování nebere v úvahu). Jednou revokovaný certifikát je revokovaný navždy, takže z CRL zmizí až teprve po konci své původní platnosti.
Pro důvěru stačí libovolný úplný CRL vydaný po okamžiku, ke kterému ověřujete podpis, až do okamžiku konce platnosti certifikátu.Problém by mohl nastat jedině u podpisu těsně před koncem platnosti certifikátu - pokud by byl v takovém okamžiku certifikát odvolán, musí se objevit alespoň na jednom plném CRL, i kdyby to bylo po konci platnosti certifikátu. Tam by se opravdu teoreticky mohlo stát, že propásnete CRL, ve kterém je ten revokovaný certifikát uveden.
Ovšem podepisovat něco certifikátem těsně před koncem jeho platnosti obecně není dobrý nápad, protože certifikát se bude ověřovat vzhledem k okamžiku, kdy už podpis prokazatelně existoval, tj. třeba k okamžiku, kdy dokument dorazil na podatelnu - a to už může být po platnosti certifikátu. Navíc při prvním ověřování podpisu se musí čekat na CRL (dříve byl dokonce ve vyhlášce nebo v metodickém pokynu požadavek na čekání celý maximální interval vydávání CRL, a certifikát, jemuž skončila platnost (ať přirozeně nebo revokací) mezi přijetím dokumentu a okamžikem ověření v CRL, je podezřelý a neměl by být automaticky považován za platný. Takže je pravděpodobné, že podpis, který by mohl být problematický při pozdějším ověřování, bude odmítnut hned při prvním ověření.
Instituce, které potřebují ověřovat podpisy zpětně, si zpravidla budují svůj vlastní seznam odvolaných certifikátů, ve kterém mají i certifikáty, které už na současném CRL nejsou. A obvykle si k tomu uchovávají i historické CRL.
> Velký balík dat pak převede do velmi efektivního Bloomova filtru. Ten z 300MB databáze certifikátů udělá malý souhrnný objekt o velikosti 1 MB.
Asi hloupá otázka - proč má tohle generovat tvůrce prohlížeče?
Nebylo by lepší, aby to pomocí Bloomova filtru převedla a publikovala každá CA? Prohlížeč by si jen stáhnul od všech CA tyto máme soubory.
A kdyby to mělo nějakou cache, tak nefunkčnost stažení by krátkodobě nevadila. Dlouhodobě by mohla znamenat třeba neplatnost všech certifikátu od dané CA - bez kontroly by jim prohlížeč nevěřil.
Tak jestlize to Firefox zvladne z celkovych 300MB pro vsechny CA stahnout na 1MB pro vsechny CA (jak se pise ve clanku), mohli by tohle delat primo CA.
Priklad: muj prohlizec bude verit 100 CA. Kazda CA timto mechanizmem vyda "malou verzi CRL". Kdyz se to zavede povinne, vsichni to udelaji. Jako uz i jine veci spojene s CA.
Ale nemusel bych krome 100 CA verit jeste "proxy" Mozilla/Google.
Jenže vtip toho zmenšení je v tom, že se to udělá pro všechny CA. Když to udělá každá CA zvlášť, bude mít soubor od každé z nich 1 MB, a když jich máte 100, bude to dohromady 100 MB. Což oproti 300 MB není žádná výhra, zejména když přítomnost certifikátu v téhle „zhuštěné“ databázi znamená, že je certifikát možná odvolaný. Abyste si byl jistý, musíte to stejně znovu ověřit na opravdové databázi. Což v tuto chvíli zajišťují autoři prohlížeče, ale kdybyste to chtěl delegovat zpět na CA, budete pro to zase potřebovat OCSP, a když ho CA nepodporuje, musel byste si od CA zase stáhnout ten kompletní CRL.
14. 9. 2022, 13:01 editováno autorem komentáře
Kedze ide o Bloom filter, tak pre konkretnu CA to nemusi mat 1M, moze to byt kludne primerane velke (standardom sa urci miera prenosti). Popripade to zazipovat, lebo standrna CA nebude mat vela revokacii SSL-kovych certifikatov. A zrazu tu mame parkB format pre kazdu CA. Navyse sa tych CA, ktore clovek realne potrebuje niesu stovky ale max mensie desiatky.
Jenže když soubor zmenšíte, zvýšíte tím pravděpodobnost false positive, takže se častěji budete muset dotazovat na skutečný stav certifikátu. Přičemž celé se to dělá proto, abyste tenhle počet dotazů snížil. Seznam odvolaných certifikátů potřebujete pro všechny certifikační autority, které máte zařazené jako důvěryhodné, plus jim podřízené autority. Asi nechcete čekat na stažení seznamu nebo síta odvolaných certifikátů teprve v okamžiku, když vám server předloží svůj certifikát – a to ani výjimečně.
Ach chybaju mi casy ked bol internet decntralizovany.
Znizzit velkost bloom filtra pre samotnu CA sa da bez straty presnosti na false positive, lebo obsahuje menej revokovanych certifikatov. Navyse v nom budu viac menej same nuly, takze pojde velmi dobre skomprimovat.
Zoznam revokovanych certiikatov je potrebny len pre autority, ktore realne porebujete napriklad navstivite web, kde vydali SSL certifikat.
Decentralizovaný internet je hezká věc, ale když máte tři požadavky –bezpečnost, rychlost a decentralizovanost – nemůžete mít všechny najednou.
Předpokládám, že ta velikost 1 MB je už po kompresi a očekává, že právě ta komprese způsobí, že součet velikostí pro jednotlivé autority bude větší, než jeden soubor pro všechny. Ale je pravda, že ten jeden soubor pro jednu autoritu nebude stejně velký, jako ten pro všechny CA, to jsem přehnal.
Ano, seznam CRL potřebujete jen pro certifikáty, které ověřujete. Zároveň ale nikdo nechce čekat na stažení CRL v okamžiku, kdy chce navštívit nějaký web.
Protože předřečník navrhoval, že se budou stahovat CRL jen od těch CA, co budou potřeba - což zní docela rozumně, protože sice trusted CA jsou stovky, ale tipuju, že weby, které navštěvuju, jich dohromady používají třeba deset; ostatní jsou třeba populární pro lokální služby v jiných částech světa nebo tak něco. Ale to pak vyžaduje, že při vstoupení na web používající nějakou takovou CA se to musí stáhnout on demand.
Většina certifikátů určitě bude od Let`s Encrypt. Jenže zajímavé weby budou mít exotičtější certifikáty - například kvalitnější placené od světových CA, třeba banky nebo velké instituce; nebo kvalitnější placené od lokálních CA spadajících pod místní jurisdikci, třeba v EU dle eIDASu, třeba veřejné instituce; nebo vlastní podřízenou CA jako velké firmy, třeba Google. A to nejsou zrovna weby, které by rády slyšely, že si uživatel na jejich načtení holt počká. Navíc by to byl další kamínek do soukolí placených certifikačních autorit: "certifikát od nás je sice dražší, ale zase se vám bude pomaleji načítat web"... A kdo by o tom rozhodoval, které autority budou mít v prohlížeči CRL už předstažený a na které se bude muset čekat?
Zkrátka technicky by to samozřejmě řešitelné bylo, ale prakticky by z toho bylo víc problémů než užitku.
Zaujimave, ze doteraz s tym problem nembol.
Tak si to zhrnme, tymto super riesnim zabijeme akykolvek trust ci dany certifikat bol revokovany, dame vsetku moc nad internetom jednej entite a prehladace sa budu zas spravat inak ako zvysok systemu. A to sa vyplati.
A neplte sem eidas, to len ukazuje, ze o tom moc neviete.
Zaujimave, ze doteraz s tym problem nembol.
Zkusím hádat – že by to bylo tím, že se to teď takhle nepoužívá? Protože prohlížeče používají buď OCSP nebo stahují CRL ke všem certifikátům, které mají uložené v úložišti důvěryhodných certifikátů.
tymto super riesnim
Které myslíte? To popsané v článku nebo to popsané Martiemn Vanclem?
To řešení popsané v článku nic nezabíjí, pořád máte možnost používat OCSP nebo CRL.
dame vsetku moc nad internetom jednej entite
Nesmysl. Každý prohlížeč si tu centrální část implementuje sám. A prohlížeči musíte důvěřovat tak jako tak.
prehladace sa budu zas spravat inak ako zvysok systemu
Což je ale problém toho zbytku systému. Když prohlížeč potřebuje nějakou funkcionalitu, kterou mu systém neposkytuje, co má dělat?
A neplte sem eidas, to len ukazuje, ze o tom moc neviete.
No tak se pochlubte, co jsem podle vás napsal o eIDASu špatně.
Já si teda ze školy matně pamatuju že velikost Bloomova filtru pro danou pravděpodobnost kolize roste lineárně s počtem prvků, a náhodná stránka co jsem vygooglil a Wikipedie si to myslí taky.
CRLite se dá v Mozille vypnout pomocí security.pki.crlite_mode=0 (Je to na url about:config) Kromě toho vám to možná bude ke spokojenosti fungovat i se současnou defaultní hodnotou 3. Chápu CRLite jako jakousi cache, která mimo jiné urychluje načítání stránek na začátku TLS.
Je jisté CRLite nezablokuje certifikát vydaný soukromou CA. (protože nebude v Bloomově filtru). Šlo by vyzkoušet, zda prohlížeč opravdu použije ostatní ověřovací mechanizmy, pokud určitá soukromá CA vůbec není v seznamu CA zahrnutých do daného CRLite. (To ovšem znamená během testu nechat běžet stránku s nějakým odvolaným certifikátem, že se zapnutým CRLite bude zablokována stejně jako s vypnutým.)
Jednotlivé Bloomovy filtry nejde slučovat do jednoho. Čim víc si o tom čtu, tím víc se mi současné řešení zdá rozumné.
Prohlížeč kontroluje, zda dostal potvrzení o zařazení do logu (SCT). Nikdy se sám přímo nedoptává logu, vždycky ho musí dostat buď v certifikátu nebo jako rozšíření v TLS handshake nebo v odpovědi OCSP responderu. Pokud vím, tak všechny autority vkládají SCT rovnou do certifikátu. Takhle to teď třeba vypadá na Rootu:
$ openssl x509 -noout -text -in root.cz.crt … CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 41:C8:CA:B1:DF:22:46:4A:10:C6:A1:3A:09:42:87:5E: 4E:31:8B:1B:03:EB:EB:4B:C7:68:F0:90:62:96:06:F6 Timestamp : Aug 27 08:01:14.939 2022 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:09:44:36:F5:4D:8F:15:B4:4F:4C:57:64: 84:96:AD:92:FB:D1:EE:A4:BA:E9:85:53:0A:E8:E4:63: 88:5F:E4:82:02:21:00:EB:67:3B:83:1D:41:03:95:F6: 17:99:26:B5:E0:A1:D5:F2:99:F3:30:55:FB:6F:52:4D: 4E:CB:58:1C:70:BC:1B Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 46:A5:55:EB:75:FA:91:20:30:B5:A2:89:69:F4:F3:7D: 11:2C:41:74:BE:FD:49:B8:85:AB:F2:FC:70:FE:6D:47 Timestamp : Aug 27 08:01:14.970 2022 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:7D:77:84:6D:F0:B2:CC:F1:1A:F7:52:CC: 7C:05:17:55:98:07:D5:21:56:13:D1:6B:CF:5E:B6:5B: E6:70:A8:1E:02:21:00:E0:BD:D7:19:5A:D9:63:86:7C: EB:3A:0F:77:96:A7:81:AC:91:04:E0:3F:3D:47:91:CF: 92:43:0D:8E:CB:14:14 …
Když prohlížeč platné potvrzení nedostane, skončí připojení chybou NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
.
Aha, díky, tak v tom případě by to mělo jít otestovat na https://no-sct.badssl.com/ - Firefox se mi připojil bez stěžování, Chromium taky, jen Chrome (oficiální googlí verze) si stěžovala.
Je to tak, podle všeho to vynucuje jen Chrome a Safari. Chromium podle dokumentace validuje, ale nevynucuje. Baličům se to nedoporučuje zapínat, protože není zajištěna častá aktualizace a kdyby došlo k nějaké zásadní změně mezi logy, mohlo by to rozbít uživatelům prohlížeč. To alespoň uvádí dokumentace.
Firefox je kapitola sama pro sebe, před pěti šesti lety se to v bugzille intenzivně řešilo, narazili na nějaké výkonnostní problémy a pak na nedostatečnou otestovanost kódu a nakonec to nějak vyšumělo. Firefox tedy SCT nevaliduje.
Ono to ale v praxi nevadí, protože Chrome a Safari dohromady pokrývají asi 75 % uživatelů a principem té validace je donutit autority vkládat všechny vystavené certifikáty do logů. Což se zjevně daří, protože pokud by to ty autority nedělaly, tři čtvrtiny uživatelů by přes ten certifikát neprošly. Výsledek je tedy zajištěn i bez Firefoxu.
14. 9. 2022, 10:25 editováno autorem komentáře
Nechápu, proč se vůbec nějaké certifikáty používají. Když v nich bývalo (EV) verifikované jméno firmy, tak to ještě dávalo smysl. Ale dnes, když certifikační autority ověřují totožnost pouze přes DNS, stačí dát fingerprint public klíče přímo do DNS (do TLSA záznamu). A nepotřebuju ani tu certifikační autoritu. A nemám problém s nedostupností OCSP, protože pokud se mi rozbije DNS, tak nefunguje stejně nic.
Když se na DNS bez DNSSEC spoléhají certifikační autority... Jediný rozdíl je v tom, že certifikační autority jsou k internetu snad připojeny relativně bezpečnou sítí (prohlížeč může být připojen přes něco, kde se podvržení DNS nedá vyloučit) a v lepším případě dělají před vystavením certifikátu validaci z více míst.
Nicméně je to opravdu postavené na hlavu. Technicky by DANE odvedlo stejnou službu, jako DV certifikáty. Údajně není zavedeno proto, že by to zpomalovalo úvodní navázání spojení - pak se ale řeší, že to zpomaluje OCSP nebo stahování velkých CRL. A když prohlížeče dokázaly (správně) prosadit používání TLS, mohly stejně tak prosadit používání DANE a DNSSEC. Podle mne jsou tam ve skutečnosti dva problémy - jednak by se tím oslabila pozice certifikačních autorit (kterou ale stejně oslabil Let's Encrypt), jednak se to celé vyřešilo na úrovni HTTP, takže prohlížeče a HTTP servery, což jsou party lidí, které spolu komunikují. Zatímco DANE by se muselo řešit s lidmi, kteří dělají DNS, a to je někdo jiný. (A to na všech úrovních - jak na úrovni standardů, na úrovni vývoje i na úrovni správců jednotlivých serverů).
Jestli to nebude tím, že OCSP ani CRL nemají s DNS nic společného... Zato když certifikační autorita ověřuje doménové jméno, dívá se do DNS na speciální TXT záznam, nebo si jméno přeloží pomocí DNS A/AAAA záznamu na webový server a hledá tam speciální soubor, nebo si přečte z DNS MX záznam a pošle tam e-mail s kódem. A to všechno dělá i tehdy, když daná doména není zabezpečena DNSSEC.