Vlákno názorů k článku
Let’s Encrypt ukončí podporu OCSP postupně do poloviny roku 2025 od Marvin - Od toho je přece stapling, aby se browser...

Třeba by se vaše obsese opravovat věci, které jsou správně, dala léčit. Pokud podle vás státy celkem běžně mirorují provoz na tcp/udp 53, jistě nebude problém napsat, které státy to tak dělají. No a že je to celkem k ničemu, když se to dá obejít třeba pomocí DoH, jste si vysvětlil sám.

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...

Znamenám si, že od teď „celkem běžně“ znamená jeden stát na světě.

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....

Ať počítám, jak počítám, počet argumentů ve vašem komentáři mi vychází stále stejně: 0.

To plati i o vas, takze jsme si kvit :-)

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.

Což ovšem platí jedině v případě, že OCSP odpověď nevyžadujete. No a když jí nevyžadujete, je to celé tak trochu k ničemu.

Máte to nedomyšlené - samozřejmě je to tak, že OCSP se validuje, jediná výjimka je při nedostupnositi CA (když klient dostane chybu od CA ve chvíli kdy server nepošle OCSP stapling).

Uvažujeme-li útočníka na poslední míli (což je asi celkem typická situace u MITM), tak ten klidně zablokuje přístup k CA.

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.