Vlákno názorů k článku Ondřej Filip, CZ.NIC: OpenID ještě nikdo nechytil za správný konec od VS - Rád bych se zeptal na jednu věc související...

Rád bych se zeptal na jednu věc související s DNSSEC. Existuje možnost do DNS uložit např. veřejný klíč k SSH serveru, lze uvažovat i o certifikátu pro SSL resp. možnosti takto „nahradit“ důvěru v certifikační autority důvěrou v podpis kořenové zóny. Tyto možnosti byly diskutovány už u předchozích článků na téma DNSSEC.
Jsou známé nedostatky současného modelu využívání SSL, kdy aplikace typu webový prohlížec implicitně důvěřují množství certifikačních autorit, kde o některých lze mít pochybnosti. Pro realizaci MITM útoku stačí získat certifikát pro danou doménu od libovlné implicitně důvěryhodné CA. Uvážíme-li, že MITM útok bude veden např. státními orgány v rámci „využívání operativní techniky“, není taková představa zcela nereálná.
Lze využít DNNSEC takovým způsobem, že důvěryhodnost zjištěných DNS záznamů bude pro koncové zařízení (s vlastním rekurzivním resolverem) nezpochybnitelná, leda že by na změně spolupracoval správce TLD nebo kořenové zóny?
Jinými slovy, dnes útočníkovi na SSL spojení stačí opatřit si certifikát pro danou doménu od kterékoliv „běžně důvěryhodné“ CA. Majitel dané domény nemá šanci takový útok zjistit. Dává DNSSEC, označovaná někdy jako globální PKI, v tomto směru lepší možnosti? Z vlastní úvahy mi vyplývá, že ano, a že pro analogii naznačeného útoku by byla třeba aktivní spolupráce držitele klíče, jímž byla podepsána doména, nebo správce TLD, což ovšem může držitel domény detekovat jako změnu veřejného klíče v registru.
Poskytnutí klíčů ke kořenové zóně státním orgánům např. ve jménu boje proti terorismu je vzhledem k velmi pěkně popsané proceduře předpokládám nereálné. A to je dobře.

RR záznam pojmenovaný SSHFP definuje RFC4255[1], pro vytvoření samotného obsahu záznamu můžete použít sshfp[2][3] v Linuxu. Nicméně jeho použití musíte v OpenSSH zapnout.
Pro TLS:
Zrovna dneska v noci byl konečně na IETF založen mailinglist, o který jsem žádal: KEYASSURE [4]. Na BoF (Bird of Feather) na IETF v Maastrichtu bylo asi 50 lidí, kteří se o toto téma zajímali a přibližně půlka se přihlásila, že by chtěla být v tomto směru aktivní.
TLSFP + DNSSEC budou umožňovat dvě věci (zjednodušeně):
1. Použít self-signed certifikát
2. Použít libovolný certifikát (např. EV) a říci, že musí být použit pouze ten.
Jinak již vznikl první internetový draft (I-D)[5], které bude základem práce pro KEYASSURE. Více pak je (a teprve bude) v archivu konference.
O.S.
P.S.: Mimochodem podobný standard existuje pro IPSec[6].
Odkazy:
1. http://tools.ietf.org/html/rfc4255
2. http://www.xelerance.com/software/sshfp/
3. http://packages.debian.org/sshfp
4. https://www.ietf.org/mailman/listinfo/keyassure
5. http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-00.txt
6. http://tools.ietf.org/html/rfc4025

Výborně. Děkuji za podrobné vysvětlení.
2. Použít libovolný certifikát (např. EV) a říci, že musí být použit pouze ten.
Dejme tomu, že na tohle vznikne nějaké rozšíření do Firefoxu, a které než se to vyřeší systémově, bude samo posílat DNS dotazy.
A mě právě zajímá, jestli exituje možnost, aby nějaký útočník s přístupem k routeru skrze který jde TCP spojení, tuto informaci „musí být použit pouze ten“ byl schopen odfiltrovat, aniž by se to poznalo. Resp. co by musel udělat a kam jinam by musel mít přístup. Stejně jako když se dnes někomu podaří nechat si vystavit důvěryhodný certifikát pro cizí doménu, může ho použít aniž by si uživatel něčeho všiml.

Pokud se u podepsané domény zeptáte na CERT (nebo TLSFP), tak musíte dostat podepsanou odpověď (NSEC/NSEC3), jinak se musíte chovat, že došlo k podvržení (stav bogus).
Jinak Adam Langley z Google už má funkční kód experimentálního prototypu v Google Chrome. Je to sice takový trochu bastl kvůli tomu, že balí celý DNSSEC chain do rozšíření v certifikátů, takže to vlastně nemá s DNS nic moc společného (kromě společného klíče), ale jako startovací experimentální metoda by to mohlo fungovat.
Cílem KEYASSURE (snad vznikne IETF WG) bude specifikovat finální protokol, resp. spíše sadu finálních protokolů. Je tam pořád spousta nedořešených věcí (hlavně zabezpečení last mile).
Jinak pokud Vás to zajímá, tak se do mailing listu přihlašte… :-)