Názory k článku DNSSEC jako bezpečné uložiště SSH klíčů

Tak jsem to I-D napsal, jako bonus jsem přidal i rodinu SHA-2 algoritmů pro fingerprinty... ještě musím vymyslet, jestli to pustím jako individual submission nebo to proženu skrz DNSEXT WG, ale to je spíš na AD.

Škoda, že se to neudělalo rovnou v rámci RFC 5656.

Takže...

I-D je tady: https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/draft-os-ietf-sshfp-ecdsa-sha2-00.txt

(a tady: http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.txt)

Ale v tom gitu budu dělat opravy, jak se to na mě sesype ze SAAG WG...

Pokud byste si to chtěli vyzkoušet, tak patch oproti Debianímu OpenSSH z unstable je tady:

https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/ssh-sshfp-ecdsa.patch

(V redmine jsou nahoře linky na Download...)

Ani ve snu by mě nenapadlo, jakou může jeden článek vyvolat vlnu!

Díky, doufám, že to projde až do zdárného cíle!

Já akorát vždycky přemýšlím, jak více zpřístupnit IETF lidem. Čistě technicky není rozdíl mezi tím, kdybyste úplně stejný text, který v podstatě vznikl poslepováním kusů jiných RFC dohromady, napsal vy, a tím, když jsem ho napsal já (pominu-li fakt, že už mám trochu překonanou vstupní bariéru, takže vím, jaké RFC poslepovat dohromady a koho se zeptat, co s tím pak dál).

Bohužel mám pocit, že spousta lidí (a neberte si to nijak osobně) si IETF představuje jako Zavazadlo ze Zeměplochy... občas z něj něco divného vypadne, ale když do něj strčíte ruku, tak o ni přijdete :). A to je velká škoda.

O.

Díky, opraveno. On to stejně bude ještě číst RFC Editor ;).

Je treba poznamenat, ze tahle technologie castecne vezme userum zodpovednost za kontrolu klicu, ktera doted probihala "decentralizovane" a prenese ji na cetralizovanou instituci, ktera bude moct fingerprinty podvrhovat kdyz na to prijde...

reseni je samozrejme klice kontrolovat i nadale a hlavne nadale zobrazovat varovani pri zmene klice i v pripade, ze tuhle zmenu posvetil DNSSEC!

DNSSEC s IPv6 nesouvisí, takže tady bych problém neviděl. K oststnímu jste uvedl příliš málo informací, než aby vám někdo mohl pomoci. Založte nové téma na fóru, popište co máte jak nastaveno a jak se projevuje, že to nefunguje.

PS: Nezačaly problémy v srpnu 2010? Pak by to mohlo souviset s rotací KSK klíče a zavedením NSEC3 v zóně CZ.

Putty, pokud vím, SSHFP záznamy neověřuje, takže je zcela ze hry. Pokud klient nebude připojen k validujícímu resolveru, SSH nebude otisku v DNS důvěřovat a dotáže se uživatele.

Pokud je však klient připojen k vzdálenému validujícímu resolveru a toto připojení není zabezpečeno IPSECem ani jinak, pak ano, útočník může obsah SSHFP záznamu v DNS odpovědi pozměnit a SSH, potažmo stub resolver, to nepozná. Chcete-li takovémuto falešnému pocitu bezpečí zabránit, rozběhejte validující resolver na localhostu, je to snadné. Nebo nastavte volbu SSH VerifyHostKeyDNS na ask, ssh se pak bude ptát vždy.

Nedělá. Kdyby to dělal, musel by se v něm někde nastavovat trust anchor. A nic takového v něm nastavit nejde.

Jinak podle mě by to spíš měl dělat stub resolver v glibc.

Stub resolver to nemusí dělat nutně, pokud máte bezpečnou "poslední míli" k validujícimu resolveru, kterému důvěřujete.

Bohužel v dnešní době neexistuje API, které by vám bylo schopné takovou informaci dát. Pracuje se na tom, ale bude to nějakou chvíli trvat. A pokud budeme usilovat o standardizaci v rámci POSIXu, tak ještě delší chvíli.

... je asi nejčastější řešení a zároveň vůbec to nejhorší. S tim souhlasim.
Da se pouzit ssh-keygen -R jmeno_hosta a je po problemu. Nemusim se rucne hrabat v known_hosts

Dnes jsem zjistil, ze Active24 jiz umoznuje zavest DNS zaznamy SSHFP. Dik za clanek. Nastavuji u svych serveru. O pripadne zkusenosti se podelim :-)