Vlákno názorů k článku
Let's Encrypt zpřístupnil šestidenní certifikáty všem, můžou být vystaveny na IP adresu od rpajik - Přitom by stačilo, aby browsery a další sw...

Přitom by stačilo, aby browsery a další sw začali podporovat DANE a celej tenhle cirkus se zkracováním platnosti certifikátů by se mohl ukončit. Technicky by nebyl problém mít na serveru certifikát klidně 10let. Při kompromitaci smáznu záznam z DNS a deploynu nový cert. Je to funkční a rychlý. Jenže to by certifikační autority přišly o svoje prašulky a tak raději dál pojedeme na tom mrtvém koni a budeme všechny přesvědčovat, že je to tak správně a že to jinak nejde.

Spíš to není o prašulích pro certifikační autority, ale o mnohem složitějším podstrkávání "důvěryhodného" certifikátu od třípísmenkových organizací :-)

Jak se to v době Certificate Transparency dělá?

CT nezaručuje, že každý certifikát, ke kterému je SCT se také objeví v transparency logu. Browser ověřuje jen ten podpis, do toho logu na jednotlivý klíče nekouká. Nejde to zneužít plošně, protože by si toho všimlo něco nezávislého, ale cíleně klidně a vesele.

17. 1. 2026, 14:32 editováno autorem komentáře

Myslel jsem, že tam je nějaká Merkel tree/"blockchain" struktura, že od certifikátu musí vést cesta k hlavičce bloku, a jak se tam jednou blok přidá, tak už musí vždycky historie navazovat (tj. už by pak bylo potřeba "alternativní CT" podstrkávat navždy). Ale netuším, jaké to má třeba UX - jak se reportuje, když prohlížeč zjistí "uh zjistil jsem, že CT nenavazuje, poprvé se to stalo před 14 dny, a už asi ani nemám seznam certifikátů, aby šlo zjistit, který to způsobil".

Takže musí spolupracovat certifikační autorita a ještě několik CT logů, kam daná autorita certifikáty posílá. A falešný certifikát pak použijete k cílenému útoku – na koho? K jakému útoku?

Dříve, když lidé něčemu nerozuměli, tak se k tomu nevyjadřovali a případně se dovzdělali. Dneska šíří konspirační teorie, chlubí se tím a mají pocit, jací jsou kingové.

Jako dobrý, ale typicky (pokud to není nějaké všeobecně známé WTF jako plochá země) je lepší napsat/odkázat, jak je to doopravdy - lidé, kteří třeba té technologii tolik nerozumí, se tak dovzdělají a bude se jasněji skvět světlo pravdy.

Dezinformátoři a konspirátoři právě spoléhají na to, že je mohem snazší generovat nové a nové lži, než je vyvracet. Navíc konspirace o tom, jak třípísmenkové agentury ovládají celý svět, je podle mne stejně známá komnspirace, jako plochá Země.

Jenže to by museli v první řadě všichni umět DNSSEC. V CZ je to díky snaze CZ.NIC docela běžná věc, ale jinde je to rarita.

I tak by ale možnost měla existovat. Buď důvěryhodná autorita, nebo DANE + DNSSEC. Alespoň by vzniknul větší tlak na všeobecnou podporu DNSSEC.

Jenže co uděláte ve chvíli, kdy se vaše banka rozhodne pro variantu DANE, ale váš místní operátor bude kazit DNSSEC a vy se k ověřeným klíčům nedostanete? Jak vysvětlíte uživatelům, že je to lepší varianta, protože banka měla na výběr?

Tak ale na přechod to jako banka/isp/eshop dám samozřejmě podobojí, jak platnou path, tak TLSA record na public key pro EE, a nemusím vysvětlovat nic.
Pokud při obnově certifikátu neměníte i key, tak se tlsa nemění, aspoň jestli to chápu správně.

Tak předně ... pokud by měl každý na výběr, tak je samozřejmě jeho odpověnost co si zvolí a se všemi důsledky co to má. Lze očekávat, že by to bylo podobné jako dnes ... kdy se masivně používají CA jako Let's encrypt, ale banky a další weby kde je potřeba, aby to fungovalo volí komerční certifikační autoritu, protože si nemohou dovolit že se jim kvůli nějaké chybě neobnoví včas certifikát. Když LE začínal, tak nasazeních těchto certů mělo lehce punkový nádech a dnes je to absolutní mainstream. Podobný scénář by byl nejspíš i v případě DANE.

Už dnes je DNSSEC (minimálně v .CZ) hodně rozšířen a pokud se to někte rozbije (a je jedno jestli na autoritativním či rekurzivním DNS serveru), tak je to problém. V tom druhém případě je možné validaci samozřejmě vypnout, což jako workaround dnes zafunguje ale ve scénáři s DANE už ne. Alespoň by to donutilo všechny co to používají tu nasadit správně a hlavně hlídat že to funguje. Což se dnes očividně moc neděje.

Proc muj operator? Validovat muze (a mel by) koncovy klient. To, ze na to implementace kaslou neni chybou navrhu protokolu. Jasne, podlehame tomu jak funguje treba klasicke glibc... a do toho radi hejtime systemd-resolved (byt tam je to nedotazene - ale to je ta cesta). Kazdopadne DNSSEC sam o sobe je navrzen tak, ze muze fungovat az na urovni klienta. Pokud mi to operator bude mrsit a banka mi nebude fungovat, je to legitimni duvod jej plisnit za nefungujici sluzbu...

V obecne rovine je ale take plisnit samotne tvurce DNS software.... kdy nam nekteri dlouho bojkotovali treba i DoT. Ono holt kdyz vsichni honi QPS, tak "blbosti" typu TLS v transportu ten vykon tahnou dolu, zejo. A mimochodem takove RFC 9276 je tou honbou za QPS explicitne postizene. A nekterym tem parametrum z toho RFC "neveri" ani samotny CZNIC, viz treba i to co maji na .cz (salt=16 namisto 0) ;-)

Ve finale i diry kolem samotneho DNS flikujeme vsude okolo... a akceptujeme diry v samotnem DNS, pocinaje prave tou "zvykovou" absenci TLS... nebo i to, ze klient sam nevaliduje, co mu prijde.

Problem s DANE je, ze prohlizec nevaliduje DNSSEC, jen hloupe spoleha na externi server... Pokud na vas nekdo udela MITM, tak muze udelat MITM i na vasi komunikaci s resolverem a je to game over. Aby to fungovalo, tak by musel mit prohlizec rekurzivni resolver validujici DNSSEC, coz je nesmysl. Takze by musel vzniknout nejaky system, kdy prohlizec dostane od externiho rekurzivniho resolveru cely retez DNSSEC zaznamu od korenove autority az po hostname serveru a musel by si sam spravovat/rotovat korenove klice. Nic takoveho prolhizece momentalne neumi.

Podobna situace je treba u SSHFP zaznamu. Pridal jsem si do svoji domeny SSHFP zaznam, povolil si to v openssh a zdesil se, ze to bez problemu prijme klic i kdyz vubec nepouzivam DNSSEC. Tyhle technologie jsou hrozne nedotazene, takze jsem to ihned zas zakazal.

19. 1. 2026, 09:10 editováno autorem komentáře

A tak nemusi to nutne delat prohlizec, muze se to delat na urovni operacniho systemu. A pak se zadny game-over nekona. Extrerni resolver fakt neni prvni misto, kde muze probehnout validace, to je jen reseni z kategorie "usnadnime si to". Ze to neni dotazene neni chyba technologie, ale ciste problem prakticke implementace na tech koncovych bodech.

Prohlížeče docela tlačí DoH, přičemž snad všechny často používané DoH servery podporují DNSSEC. Aby si každá aplikace dělala vlastní validaci nedává smysl, ideálně by to měl dělat resolver v systému (pak nehrozí napadení síťové komunikace).

Pokud ti nekdo udela mitm na dns, tak je nejakej certifikat nejaky pseudoautority to uplne posledni, co je na tom k reseni.

Veris ty IP kterou ti dns vrati, tak proc bys neveril tomu klici ktery ti vrati, je to exaktne totez.

DNSSEC je kravininum, ktery internet leda rozbiji. Browser ani zadna dalsi aplikace nema a nesmi mit vlastni resolver, ma pouzivat systemovy volani. Pokud neveris vlastnimu systemu, proc bys mel verit nejaky aplikaci??? ...

Pokud ti nekdo udela mitm na dns, tak je nejakej certifikat nejaky pseudoautority to uplne posledni, co je na tom k reseni.
Pokud vám někdo udělá MitM na DNS, tak certifikát je ta jediná věc, která vás ochrání před tím, abyste jeho útoku podlehl.

Veris ty IP kterou ti dns vrati, tak proc bys neveril tomu klici ktery ti vrati, je to exaktne totez.
Protože ten klíč má u sebe certifikát, který můžete ověřit. A když není v pořádku, tak můžete komunikaci ukončit.

DNSSEC je kravininum, ktery internet leda rozbiji.
Už jsem si v diskusích na Rootu všiml, že vy máte rozbité úplně všechno. Zvláštní je, že se to děje jenom vám.