Názory k článku Let's Encrypt začíná validovat žádosti o certifikáty z různých míst
-
Filip JirsákStříbrný podporovatelNež zahušťovat validační body tak, aby validace vždy šla i přes peering, bylo by podle mne užitečnější umět omezit použité validační metody – draft-ietf-acme-caa-04. Pokud bych mohl omezit metodu na
dns-01a měl na doméně DNSSEC, možnosti útočníků tím dost omezím. -
Ondřej CaletkaZlatý podporovatelIdeálně samozřejmě obojí. Možnost použití CAA omezení pro uvědomělé a hustou síť validačních bodů pro všechny ostatní, kterým stačí, že to nějak funguje a kterých bude vždycky většina.
-
To je sice pravda, ale v praxi pokulhává. Jednotlivci i malé firmy nemají správu DNS pevně v rukou. Velká část (možná i početně převážná) to má tak: "Kde máte DNS?", "Já nevím.", "Kdo vám zařizoval doménu?", "Předpředminulý ajťák, musím se podívat, jak se jmenoval. Nebo to zařizovala ta firma, co nám dodávala stránky?".
Hrnout ověření víc a víc k DNS smysl dává, ale samo o sobě to nepřinese velkou změnu ve faktickém stavu. V první fázi to vyvolá zděšení a tlak na držitele domén, aby si to dali do pořádku. A tak budou dávat "do pořádku" něco, co léta funguje a neměli a nemají žádnou přirozenou potřebu to dělat. Další slabinou, kterou nikdo neřeší, je zabezpečení samotných služeb zajišťujících registraci domén a správu DNS. Přitom na zabezpečení a auditování těchto služeb by se dal vyvinout tlak nejjednodušeji: chceš být registrátorem, podrob se pravidlům bezpečnosti. To se ale zatím neděje, nebo ne dostatečně.
Celá filozofie DV certifikátů je pochybná. Na místo OV certifikátů, které sice něco stály, ale probíhalo aspoň nějaké opravdové ověření, máme tu certifikáty ověřené sice dokonale, ale v řetězci úkonů, na jehož počátku je díra velká jak vrata.
Zahušťovat validační body proto dává smysl - nepřinese to moc komplikací a výsledek bude o něco lepší. Přechod výhradně na dns-01 by bezpečnost nezvýšil nijak výrazně v praxi. Naopak by způsobil problémy při ověřování certifikátů pro delegované systémy. V tu chvíli by musel držitel domény nejen delegovat systém (FQDN) na jiného provozovatele, ale ještě vyřešit delegování mechanismu ověření dns-01.
-
Filip JirsákStříbrný podporovatel
Zapomněl jste na to, že celý web je na DNS závislý.
O bezpečnost DNS se provozovatel webu musí stejně postarat, bez ohledu na certifikáty. DV certifikáty z principu nejde udělat bezpečnější, než je DNS. OV/EV certifikáty sice bezpečnější udělat lze, ale pořád to bude tak, že při ovládnutí DNS zóny nebudete moci vystavit falešný web s OV/EV certifikátem, ale můžete vystavit falešný web s DV certifikátem nebo web prostě vypnout. Pochybuju o tom, že by vlastníky OV/EV certifikátů vypnutí jejich webů nijak netrápilo. Nehledě na to, že dnes v běžném prohlížeči nejde odlišit ani EV certifikát, takže k vytvoření falešného webu DV certifikát stačí.
Certifikační autorita na zabezpečení DNS nemá žádný vliv – nanejvýš může validovat DNSSEC. To, aby měl bezpečné DNS, si musí každý provozovatel webu pohlídat sám – což je přesně to, po čem voláte v diskusích o webových prohlížečích.
Já jsem popisoval zlepšení ve smyslu „kdo chce lepší zabezpečení, má možnost“. Vy argumentujete tím, že když si to nezabezpečí lépe všichni, nemá smysl dávat tu možnost nikomu. Když si někdo nezabezpečí svůj blogísek, nebudeme přece dávat nástroj na lepší zabezpečení nikomu, ani bance. Já vám to neberu, je to váš názor, ale nepovažuju takový přístup za rozumný.
Celá filozofie DV certifikátů je pochybná.
S tím souhlasím, DV certifikáty by vůbec neměly existovat, jenom duplikují informace, které už jsou v DNS. Nicméně věrohodné ověření domény potřebujete i pro OV a EV serverové certifikáty. A dokud tu DV certifikáty jsou, měli bychom se snažit zabezpečit i ty.výsledek bude o něco lepší
Řešíte problém únosu DNS zóny, a tento problém zahuštění validačních bodů nijak neřeší.Přechod výhradně na dns-01
To je ovšem čistě váš výmysl, já jsem o přechodu výhradně nadns-01nic nepsal.V tu chvíli by musel držitel domény nejen delegovat systém (FQDN) na jiného provozovatele, ale ještě vyřešit delegování mechanismu ověření dns-01.
Jo, přidat k jednomu CNAME záznamu ještě druhý CNAME záznam bude nepřekonatelný problém. -
Filip JirsákStříbrný podporovatel
Validace serverových certifikátů bude na DNS závislá vždy. Buď je dnes DNS nejslabším článkem, pak by útočníci už dnes útočili přes DNS a zároveň by se hledala opatření. Nebo DNS není nejslabším článkem, pak je potřeba řešit přednostně ta slabší místa. Nemá smysl naříkat nad tím, že až vyřešíte ta nejslabší místa, stane se nejslabším místem DNS – vždycky bude nějaké nejslabší místo a to je pak potřeba řešit.
-
Ve skutečnosti nemáme žádné údaje o tom, jestli existují pokusy získat certifikát prostřednictvím slabin v DNS správě, přesto to můžeme považovat za riziko a odhadovat jeho závažnost. Stejně tak můžeme odhadovat, jestli se nějakým opatřením zvýší buďto závažnost nebo urgentnost rizika.
Ve Vašem návrhu se nezvyšuje závažnost (ta zůstává neměnná), ale urgentnost se pravděpodobně zvýší. Dál lze odhadovat (předpokládat), že po překročení určité hranice začne být toto riziko plošně zneužívané. To způsobí další problémy v praxi.
Neříkám, že se nic nemá dělat, to mě nechápete správně. Říkám, že k takovým změnám, jako navrhujete, je potřeba zvážit i ty důsledky v praxi a případně zvolit jinou cestu, jak se postupně přiblížit k cíli.
Vykosit celou oblast tím, že namalujeme na papír, jak by to mělo být správně a vynutíme to, to umí každý.
-
Filip JirsákStříbrný podporovatel
Takže když nevíte, jestli existují snahy zneužívat slabiny ve správě DNS, budete se tvářit, že snahy neexistují a že se nemáme snažit tu správu více zabezpečit, protože tím bychom na ty slabiny upozornili. Zajímavá teorie. A neměl byste tedy především vy o těch slabinách mlčet? Tím přece také potenciálním útočníkům ukazujete cestu.
Já si myslím, že je potřeba především mít k dispozici ty nástroje pro zabezpečení. Pokud je pak někdo nepoužije, je to jeho problém. Nesouhlasím s vaším přístupem, že radši nebudeme bezpečnější nástroje vytvářet, protože tím bychom na nedostatky v zabezpečení upozornili. Security through obscurity totiž nefunguje. A až to útočníci začnou zneužívat, bude pozdě na to nějaké nástroje teprve začít vytvářet. Vy se chcete bránit neschopným útočníkům, kteří nevědí, na co mají útočit, já se chci bránit těm schopným – obrana proti nim totiž zahrnuje i obranu proti těm neschopným.
-
@Filip Jirsák:
Tlačíte to do extrému. Tlačit na zlepšení není totéž, jako bez ohledu na stav věcí to vynutit. Je potřeba jít oběma cestami. Na jedné straně zlepšovat stav a zvyšovat využitelnost ideální cesty, ale na druhé straně poskytovat nástroje, které situaci zlepšují i tam, kde stav ideální (ještě) není. Ideální auto je s ABS, ESR, airbagy a dalšími pomocníky. Přesto není myslitelné zakázat provoz všech i starších aut, které to nesplňují - maximálně se může zavést direktiva, že nová auta už musí být vybavená. Proč? Protože je bezohledné chtít, aby si ti, co za auto zaplatili, museli jen tak vyměnit za nové, je potřeba na ně brát ohled.
-
Filip JirsákStříbrný podporovatel
Miroslav Šilhavý: Píšete sice hezky, ale zcela mimo kontext této diskuse. O žádném vynucování totiž nebyla řeč.
-
Je rozdíl, jestli "autorita toleruje výpadek jednoho ze vzdálených validačních uzlů" nebo jestli toleruje i jednu nekonzistentní odpověď neodpovídající požadavku o certifikát. To z textu není jasné. Pokud je tolerován opravdu jen výpadek, nikoli nekonzistence, pak je to odolnější proti MiM a útočník by jednak musel napíchnout kabel, kterým chodí spojení od N -1 serverů a ještě by musel blokovat jedno spojení. Na druhou stranu by hrozilo DoS vymýšlením falešných odpovědí na jedné trase. Předpokládám, že tolerování výpadku je okamžité zatímco nekonzístence by mohla znamenat prodloužení procesu ověřování.
Podle kapitoly "Replay Protection" v RFC 8555 se zdá, že na vícero ověřování mysleli důkladně. Kdo z nás má kapacitu si číst celý dokument.
19. 2. 2020, 17:10 editováno autorem komentáře
