Od toho je přece stapling, aby se browser nemusel ptát OCSP serveru.
Proč nenapíšou rovnou, že OCSP je zátěž serverů navíc, když stejně musí každá CA povinně poskytovat CRL.
U certifikátů zadarmo se divím, že už OCSP nezařízli dávno.
Tyhle výmluvy na bezpečnost uživatelů...
Dokud jsem neměl veřejný certifikát, roboti ani nevěděli co dát do SNI.
Jenže stapling závisí na OCSP. Takže když chtějí vypnout OCSP, přestane fungovat i stapling.
OCSP v prohlížečích nikdy pořádně nefungovalo. Když se prohlížeč spokojí s tím, že OCSP nedostane, je to dost na houby.
Stapling je dnes nesmysl – byl to způsob, jak obejít nemožnost automatického vydávání certifikátů. Proč dávat do certifikátu informaci „platí do 30. 1. 2025“ a vedle toho posílat informaci „a CA extra potvrzuje, že platí aspoň do 7. 12. 2024“, když se může rovnou platnost do certifikátu nastavit na 7. 12. 2024. Z hlediska CA v tom není rozdíl, jenom místo podpisu OCSP podepíše certifikát.
Nevím, proč hned musíte Let's Encrypt bez důkazů obviňovat, že uvádějí nějaké zástupné důvody. Mně nepřipadá nijak nereálné, že nějaký stát začne po LE požadovat logy z OCSP.
Ano, OCSP response je v podstatě krátkodobý certifikát, že platí jiný certifikát. Kde funguje ACME, může být krátkodobý certifikát výhodnější.
Pro certifikáty s platností do 10 dnů se ani OCSP nevydává.
Zdá se mi mnohem reálnější, že stát bude vyžadovat logy z DNS. TTL neustále klesá, přehled o provozu přesnější.
OCSP můžu v browseru vypnout úplně, ale u DNS můžu jen změnit poskytovatele.
To je samozrejme blbost, ze se data z DNS nedaji pouzit - naopak se pouzivaji (a sbiraji) dnes celkem bezne, mnohdy jako soucast bezpecnostniho reseni dane (typicky koncove) infrastruktury. A staci k tomu mirror provozu na tcp/udp 53 na vhodnych mistech. Pojednava vam o tom treba i RFC 7258 - a problemy s "tradicnim" DNS dali prave proto vzniknout resenim typu DNS over HTTPS aka RFC 8484.
Tak napriklad v Litve maji od roku 2024 primo "DNS firewall", kdy ISP jsou primo povinni zaclenit DNS RPZ na svych resolverech. Soucasne zpet z tech resolveru posilaji ven urcene syslogy. Ze je o DNS "zajem" dokazuji treba i aktivity nasich uradu - jen nejsme tak daleko, a namisto publikace RPZ se seznam blokovanych domen siri jen v nejakem dokumentu. A ze o DNS ma zajem i EU je videt jak na dns4eu projektu... tak treba i na podobe NIS2 smernice a jeji provadecich smernicich - raceji si vsimnout, ze v textu se mluvi nejen o autoritativnich DNS, ale tez o rekurzorech...
Ja vam tu fakt nebudu delat detailni resersi toho, kde vsude se do DNS nejak zasahuje ci jak moc se kde monitoruje. Jestli vas to fakt tak moc zajima, tak si ji udelejte sam. Ja vim, ze se tyhle veci proste dejou a jejich intenzita se zvysuje. To sousto je snadne... takze se toho samozrejme na ruznych mistech chytaji.
To, ze vy se od sve vyvojarske konzole tvarite, ze se to nedeje jen opet dokazuje vase odtrzeni od reality ;-) No jo... to se tak programatorum obcas holt stava....
To je sice teoreticky pravda, ale mám čerstvou zkušenost z praxe. Nefungoval mi rekurzně Unbound - všechny požadavky skončili SERVFAIL. Po chvíli špekulování jsem zjistil, že problém je u ISP, který veškerou komunikaci přes port 53 někam přesměrovává.... Takže rekurze byla celkem úspěšně zmařena. Po upozornění to ISP opravil, prý to byla "chyba" a vše bylo přesměrováno na 8.8.8.8.
Po upozornění to ISP opravil, prý to byla "chyba" a vše bylo přesměrováno na 8.8.8.8
No, tohle jsem viděl v praxi taky. ISP se rozbil DNS server, tak to přesměroval na Google. A pak na to pro jistotu úplně zapomněl. :-) Chovalo se to opravdu úžasně, dotazy na domény s DNSSEC nefungovaly prakticky vůbec, bez DNSSEC tak nějak náhodně na několikátý pokus.
Příště, než budete psát, že je to nedomyšlené, zkuste se nad tím sám aspoň trochu zamyslet.
Neexistuje žádný centrální registr nedostupnosti CA. Takže pokud chcete počítat s nedostupností CA, je jediná možná implementace OCSP klienta – pošle dotaz, a když do určeného času nepřijde odpověď (protože CA je nedostupná), tváří se, jako by dostal OCSP odpověď potvrzující platnost certifikátu. Což je ovšem řešení dost k ničemu, protože pokud útočník dokáže přesměrovat HTTPS komunikaci na svůj server, kde má uniklý privátní klíč, s vysokou pravděpodobností dokáže také znemožnit odeslání OCSP požadavku, takže pak nepřijde žádná odpověď.
Je nesmysl nezvýšit bezpečnost jenom kvůli virtuální nedostupnosti CA. Zajímalo by mne, kdy jste zažil několikahodinový výpadek nějaké uznávané CA, když to tak řešíte. Navíc se případnému výpadku můžete velice snadno bránit – prostě budete používat dvě CA a když bude jedna nedostupná, prostě si necháte vystavit certifikát z té druhé. Pokud se používá současné schéma certifikát + OCSP, v případě výpadku CA máte smůlu, protože OCSP potřebujete právě od té jediné autority, od které máte certifikát.
To, že se historickým vývojem došlo k nějakému řešení, neznamená, že je to řešení optimální. A posílat dva různé časy podepsané stejnou autoritou nemá žádný smysl. (Kdybyste na tom trval, dá se to udělat i s certifikátem, bez OCSP – prostě by se do certifikátu přidal další atribut s časem, a prohlížeč by se podíval nejprve na ten kratší čas, a kdyby byl propadlý, podíval by se ještě na ten delší. Smysl to nedává, ale řešilo by to váš výpadek CA prakticky stejně, jako to řeší nepovinné OCSP.)
Zátěž Certificate transparency logu je to poslední, co by bylo potřeba řešit. Informace o návštěvnosti webu tím neunikají (na rozdíl od OCSP). Server si prostě pravidelně nechá vystavit certifikát, stejně jako si ho nechává pravidelně vystavovat teď /akorát v delším intervalu) a pravidelně si stahuje OCSP. Prostě by si jen od autority místo podepsaného OCSP stáhl podepsaný certifikát.
Nemohu teď najít, jak dlouho platí odpověď OCSP serveru, něco mi říká 15 minut, ale nevím, kde jsem tu odpověď vzal. Ale jelikož neřešíme status quo, ale různé hypotetické (a možná budoucí) světy, tyto doby nejsou vytesané do kamene.
Takže dejme tomu, že certifikát platí alespoň třeba týden a OCSP odpověď bude platit 15 minut. Prohlížeče budou vyžadovat OCSP stapling. Pro nový certifikát bude CA vyžadovat nové ověření, pro OCSP potvrzení bude CA stačit absence revokace. Nový certifikát půjde do CT logu (a všichni tak budou vědět, kdy server obnovuje certifikáty), OCSP požadavek půjde jen do CA. Takže výpadky serveru (pokud se zrovna netrefí na chvíli obnovy certifikátu) v CT logu zaznamenány nebudou. A pokud se OCSP odpověď bude získávat líně (tedy s prvním požadavkem ve chvíli, kdy server nemá odpověď v cache), neprojeví se to v CT logu.
Nikoli, ta doba se počítá ve dnech. LE má prý v certifikační politice, že platnost OCSP odpovědi musí být alespoň 8 hodin, fakticky je ale nastavuje na 7 dnů a nové potvrzení vydává po třech dnech.
Pro vydání nového certifikátu nemusí být potřeba nové ověření. Může to celé fungovat úplně stejně, jako dnes, jenom místo OCSP si server stáhne rovnou nový certifikát.
OSCP se pohrbiva hlavne proto, ze tam jsou rizika spojena s ochranou soukromi. Kvuli snizeni zateze se to fakt nedela.