Nejzajímavější na tom myslím je věc, která ve zprávičce není uvedena: Cloudflare je aktivní propagátor Certificate Transparency, provozují jeden z uznávaných CT logů, provozují službu CT monitor – a stejně je na ty certifikáty musel upozornit někdo jiný.
Kolem lepší práce s CT se pak logicky točí většina nápravných opatření.
Kdyz se z jedne strany zkracuje platnost certifikatu a soucasne se tlaci zabezpeceni transportni vrstvy pokud mozno vsude (a netvrdim, ze je to spatne)narusta vcelku logicky objem dat, ktere je nutne analyzovat...
Ze to neni trivialni dokazuje mj. i obycejne crt.sh, ktere proste cas od casu nezvlada ani odpovedet na polozeny (jednoduchy) dotaz.
Holt ty teorie kolem "lepsi prace" se sice snadno rikaji, ale jejich nasazeni v realnem svete neni tak trivialni, jak se pri psani podobnych komentaru muze jevit.
Tezi, ze Cloudflare CT vubec nerozumi jste tu vyslovil vy sam, dokonce jste vyse zpochybnil jejich analyticke schopnosti - kdyz jste v uvodnim komentari rypal do toho, ze je musel upozornit nekdo treti.
Akorat ze sam nemate v rukavu lepsi reseni. Vlastne muzeme smele konstatovat, ze vy sam byste nedokazal nakodovat to, co zvladli u Cloudflare... pan programator :-)
Majitel serveru nemá jak zjistit podvodný certifikát a málokdo aktivně CT logy prochází (což se teď změní). Zde to bylo zjištěno jen díky tomu, že Fina ty (vlastně podvodné) certifikáty dala do CT logu. Jinak by na to mohl přijít jedině DoH/DoT klient (v prohlížeči nebo Windows, ale nikde to není implicitně zapnuté) nebo pozorný správce DNS resolveru, který používá forward na 1.1.1.1. Ještě by na to mohl přijít provozovatel nějakého DNS řešení na ochranu klientů. Možnost odhalení by se snížila, kdyby ten útok byl cílený na omezený počet obětí.
Zde byli teoreticky postiženi jen klienti Windows, protože má CA Fina v úložišti a Windows 11 umožňují DoH v nastavení ručně zapnout. Reálný útok to ale zatím podle všech zjištění nebyl. Šlo snad údajně o nějaké interní opatření, které však mělo být podle pravidel proti jejich vlastnímu DNS resolveru a ne proti veřejnému resolveru Cloudflare.
Majitel serveru může zjistit podvodný certifikát právě z CT logů. Fina ty certifikáty dala do CT logu proto, protože podmínkou pro to, aby autorita byla vedena na některém seznamu důvěryhodných autorit, je to, že uveřejňuje certifikáty v CT logu. Nešlo o interní opatření, ale o testy vydávání certifikátů ze strany CA Fina. Akorát ty testy prováděli na produkci s produkčním nastavením a produkčním privátním klíčem.
Ano.
Upřímně ten systém, kdy nějaké třetí strany ověřují kdo doménu drží... mi přijde divný design. Podpis od daného registru mi dává smysl, protože na něm to visí tak jako tak (CA prostě zase dělají obyčejné DNS dotazy). To že vydávání certifikátů přes CA nemá dobré bezpečnostní vlastnosti se záplatuje viditelností v CT logách, ale zase je to takové polovičaté a složité.
Nezabránilo. Jednak šlo o vystavení certifikátu, to DANE nijak neřeší. Jednak šlo o certifikát vystavený na IP adresu – DANE řeší přidání certifikátu do DNS, u IP adresy ale nemáte kam do DNS ten certifikát přidat. (Teda pokud byste nechtěl kvůli jednotkám případů upravovat standard, aby se DANE záznamy daly přidávat k reverzním DNS záznamům.)
Důvody, proč se to děje, jsou různé, a různé důvody mají různá řešení. Každopádně dneska nejjednodušší, co se dá dělat, je sledovat Certificate Transparency logy, zda nebyl nějaký certifikát vydán neoprávněně. Cloudflare řeší, proč to u nich selhalo a co udělají jinak, aby jim tohle příště fungovalo – zejména když monitoring CT nabízejí i jako službu pro ostatní (a neselhala ta služba, selhalo její použití).
A byl vlastně ten certifikát vůbec podvodný?
Ono 1.1.1.1 bylo(=pořád je) dost rozšířené v enterprise, viz https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/213535-wlc-virtual-ip-address-1-1-1-1.html
Byl, protože jediným skutečným vlastníkem 1.1.1.1 je Cloudflare, který vytvoření takového certifikátu neautorizoval. Nicméně to (s největší pravděpodobností) nebyl podvod ve smyslu, že by chtěl někdo někoho oklamat. Akorát prostě certifikační autorita při svém testování nešťastně používala IP adresu, která může vypadat jako testovací, ale má skutečného vlastníka.
Nikoliv, vlastnikem 1.1.1.0/24 je APNIC Research and Development, ktery jej Cloudflare jen propujcil. Kdyz uz chcete mit nazor, aspon si overujte fakta ;-)
inetnum: 1.1.1.0 - 1.1.1.255 netname: APNIC-LABS descr: APNIC and Cloudflare DNS Resolver project descr: Routed globally by AS13335/Cloudflare descr: Research prefix for APNIC Labs org: ORG-ARAD1-AP organisation: ORG-ARAD1-AP org-name: APNIC Research and Development org-type: LIR country: AU