Názory k článku Ondřej Filip, CZ.NIC: OpenID ještě nikdo nechytil za správný konec

Problém není jen v zaregistrování různých variant k doméně bez diakritiky, aby je někdo nezneužil, ale hlavně v tom, že díky použití UTF kódování lze vizuálně zaměnit znaky s naprosto jiným významem, což výrazně nahrává podvodným stránkám, které mohou získat i certifikát, a tak snadněji obelstít svou oběť. IDN je omyl a u nás nemá opodstatnění, respektive nevýhody převažují nad výhodami.
Co se týká OpenID, tak to bych uvítal hlavně u registrace do diskuzí, jejichž registrace je na některých serverech tak komplikovaná, že mi to za to ani nestojí.

Ano? A co zabrání zfixlovat suffix CZ, nebo jiný?

Proč myslíte, že Rusko nedostalo IDN doménu .PU, ale РФ? :)

Dobry den,
dekuji za dotazy. K tomu IDN muzu jen rict, ze udelat IDN varianty tak, aby byly zcela ekvivalentni s puvodnimi DNS zaznamy neni uplne jednoduche. V soucasne dobe se v IETF toto tema diskutuje. My prosazujeme umozneni CNAME i DNAME najednou, ale diskutuje se i o jinych navrzich. Mnohem urgentnejsi potrebu takoveho reseni maji predevsim lide z Cinskeho registru. Maji 2 domeny v cinskych znacich pro Cinu a potrebovali by, aby registrace v obou techto DNS stromech byly zcela ekvivalentni.
OpenID skluz nema, jede presne podle puvodnich planu. V puvodnim dokumentu byl uveden rijen 2010.

Ke startu OpenID to rozhodne nebude, ale je to zajimavy napad, jiste to zvazime.

Problém neanymního pobytu na internetu vidím v tom, že vše může být zálohováno na věčnost. Jenže lidé se mění. Takže vězte, že by mi opravdu bylo nepříjemné, kdyby na mě někdo vytáhl, co jsem dělal na internetu před 15 lety!
Nick se dá změnit. Reálné jméno obtížně.
A druhý problém je v tom, když se heslo prozradí. Když mám různá hesla do různých služeb, tak jsem docela v pohodě, ale když mám jediné heslo na všechno, tak jsem v neuvěřitelném průseru!

To je problém, který se řeší bezpečnostním tokenem.

>> Protože to nikdo ještě nevzal za ten konec, za který to bereme my.
To se mi líbilo, sebevědomí je potřeba! :)

Připravuje nic.cz automatickou kontrolu DNS záznamů? Kontrola by měla být pravidelná s tím, že v případě problémů by se poslalo upozornění technickým kontaktům domény. Tuto kontrolu provozuje např. švédský registrátor na http://dnscheck.iis.se/, bylo by to velmi vhodné i pro české domény.
Dle logů našeho validujícího nameserveru mají chybně implementovaný DNSSEC (tj. uživatelům jsou nedostupné) domény epizoda.cz, kad.cz, kinoteka.cz, filmacek.cz, rempo-eshop.cz, autosklo-perfekt.cz a další. Ve většině případů je DS záznam v zóně .cz, ale chybí klíč DNSKEY ve vlastní zóně.

Technicke kontroly se provadeji prubezne. V prumeru to vychazi, ze kazda domena je kontrolovana cca 1× za 3 mesice. Tyto kontroly maji pouze informativni charakter a muzete si nastavit jejich „hloubku“. Kontrola DNSSECu je soucasti techto testu.
Navic, abychom predesli pripadum, o kterych mluvite, tak v nejblizsi dobe bude implementovana do registru nova funkcionalita. Pokud dojde u domeny ke zmene NSSETu (nameserveru) bude KEYSET automaticky vymazan (tedy pokud nebude v te same operaci explicitne pridan). Takze lide, kteri o DNSSECu nic nevedi a migruji si sve domeny, by uz priste nemeli mit tento problem.

Jenom technický dotaz – jak si mohu nastavit hloubku kontrol?

Stejně jako všechny ostatní parametry nastavení – přes svého registrátora.

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… :-)