Názory k článku OpenSSH ukončí podporu algoritmu ssh-rsa. Co přesně to znamená?

Díky za tip s UpdateHostKeys!

aktuální OpenSSH 8.3 z minulé středy má UpdateHostKeys zapnuté ve výchozím stavu

Dobrý den,
velké díky za poučný článek. Dovolím si trošku odbočit a doufat, že mi osvětlíte (ne)používání (EC)DSA v OpenSSH.

DSA i ECDSA využívají obtížnosti diskrétního logaritmu, liší se použitými grupami. V obou případech je k podpisu hashe H nutné vygenerovat náhodné k, z něhož se odvodí r (závisí pouze na k) a s (závisí na k a privátním klíči x), podpis tvoří dvojice (r, s). Pokud se jedno k použije na různé hashe H1 a H2, lze (v případě DSA i ECDSA) dopočítat k a z něj privátní klíč.

To se v praxi stalo u DSA i ECDSA. Řešením je 'Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)' definované v RFC 6979. Zjednodušeně řečeno, namísto náhodného k vezmu "k = hash_function(x, H)" - to mi zajistí, že pro jeden podepisovaný hash H daným klíčem x nedostanu různá k.

A teď ta otázka: proč to u DSA vadí (vyhozena z OpenSSH) a pro ECDSA ne (dál se používá)?

Zajímavý dotaz. Byť odpověď přesně neznám, domnívám se, že při vypínání DSA mohla hrát roli i fixní délka klíče pouze 1024 bitů.

Taky neumím odpovědět "proč se používá", ale na mnoha místech se doporučuje nepoužívat, není k tomu důvod.

Another important disadvantage of DSA and ECDSA is that it uses randomness for each signature. If the random numbers are not the best quality, then it is possible to recover the secret key.
https://stribika.github.io/2015/01/04/secure-secure-shell.html

https://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys/46781#46781
https://fahrplan.events.ccc.de/congress/2010/Fahrplan/attachments/1780_27c3_console_hacking_2010.pdf

DSA používalo jako hash SHA-1, což není bezpečné. ECDSA od začátku používá SHA-2.

DSA taky bylo zavedeno jako náhrada RSA zatíženého patenty, ty však už vypršely...

Asi rada k nicemu, ale doporucuji si zaplatit analyzu nebo kryptoanalitika a pak jeste analyzu kodu konkretni implementace.
Na podobny problem jsem narazil asi měsíc zpátky kdy mi nikdo nebyl schopen zdůvodnit a kolega analytik je na dovolené.
Dost dobře je možné že zdroje kopírují jednu lež mezi sebou.

Dobre napsany program vydrzi vic jak 20 let. To je vic jak americky prezident v urade a vic jak zivotnost tehdy v americe ilegalniho, dnes smesne jednoducheho kryptovani. Potiz je v tom, ze mame nekolik set aktivnich instalacich nasich systemu, ktere jedou na linuxu priblizne z roku 2005. Tedy 15 let stareho. Samozrejme nove instalace bezi na novejsich systemech, ale bohuzel musime podporovat i ty stare. Jednoduse na tech 10+ letych masinach by se novy linux uz ani nerozbehnul.
Jediny zpusob jak se na tyhle systemy dostat je ssh s optionama nastavenyma za hranici bezpecnosti. Ale co muzeme delat? Nic. Znamena to jenom to, ze nase pracovni stanice musime udrzovat natolik stare, aby se dokazaly spojit s 15 let starymi systemy. Takze kvuli tomu, ze nekdo chce, abychom pracovali bezpecneji, budeme pracovat podstatne nebezpecneji. Trochu to pripomina zakaz dieselu, aby se pak ukazalo, ze znecistuji mene, nez ty nadupane naturbovane motory, co se dnes cpou do cehokoliv.

> Dobre napsany program vydrzi vic jak 20 let.

No nevím… SHA-2 je mladší než 20 let, takže před 20 lety efektivně neexistoval bezpečný hash. Samozřejmě se můžeme tvářit, že tento typ kolize se nedá použít k praktickému útoku… snad.

> Jednoduse na tech 10+ letych masinach by se novy linux uz ani nerozbehnul.

To je něco s 8 MB RAM, nebo jak se to stane? A tam je openssh a ne dropbear nebo podobná jiná implementace?

> Jediny zpusob jak se na tyhle systemy dostat je ssh s optionama nastavenyma za hranici bezpecnosti.

Ano, ale co jiného jako měli vývojáři openssh dělat? Nechat to zapnuté všem? Nebo to vyhodit úplně?

> Znamena to jenom to, ze nase pracovni stanice musime udrzovat natolik stare, aby se dokazaly spojit s 15 let starymi systemy.

Ve skutečnosti je velmi jednoduché nainstalovat starší ssh do /opt, udělat si alias "nossh" (not so secure shell) a připojovat se pomocí nossh stroj. Pak se musíte strachovat jenom o díře, která by umožnila RCE na klientovi, což je u SSH spíš nepravděpodobné, ale i kdyby, tak ho můžete mít v kontejneru.

Znamena to jenom to, ze nase pracovni stanice musime udrzovat natolik stare, aby se dokazaly spojit s 15 let starymi systemy.
Nemusíte tak udržovat celé pracovní stanice. Stačí vám k tomu jeden program, přinejhorším jeden virtuální počítač nebi kontejner.

Takze kvuli tomu, ze nekdo chce, abychom pracovali bezpecneji, budeme pracovat podstatne nebezpecneji.
Proč by kvůli vašim problémům měli trpět všichni ostatní?

@Josef Pavlik

Podle mě tu lajete na to, že jste propásli roky, kdy byl jasně patrný posun vpřed. Musí to být asi hodně zapeklitá situace, jestli ty instalace nezvládnou ani aktualizaci, ani začlenit do sítě stroj, přes který by se udělala brána do nezabezpečené části, ani (asi) nejsou zvirtualizované, když by nic novějšího neunesly.

Nicméně, vždy můžete z openssh vyjít a udělat si vlastní fork starší verze a backportovat nové poznatky z bezpečnosti po svém. Třeba to ocení ještě pár dalších lidí. Jestli se to vyplatí, je na Vás.

> Dobre napsany program vydrzi vic jak 20 let.

Prosím, můžete se předvést…

> Potiz je v tom, ze mame nekolik set aktivnich instalacich nasich systemu, ktere jedou na linuxu priblizne z roku 2005. Tedy 15 let stareho.

Tedy spoustu let bez bezpečnostních záplat? Samozřejmě záleží na prostředí a modelu útočníka, ale možná byste u takovýchto vykopávek už moc nepokazil telnetem. Ne protože by telnet byl bezpečný, ale protože si nedělám o iluzi celkové bezpečnosti těchto vykopávek…

> nekdo chce, abychom pracovali bezpecneji

Někdo chce vyvíjet SSH pro situace, které mu dávají smysl. Jak jsem psal výše, bezpečnostní přínos SSH je u takové vykopávky sporný. Pokud ale přesto máte nějaký dost specifický use-case, OpenSSH je opensource. Nic vám nebrání udržovat starou verzi, případně někoho k tomuto účelu najmout nebo založit crowdfundingovou kampaň.

Je to mimo téma (od vás), ale diesely se stanou čistými, když zavedeme ještě špinavější motory? A takhle jste to myslel i s tím OpenSSH?

Jinak pro pristup na legacy systemy jde pouzit https://packages.debian.org/buster/openssh-client-ssh1 ... kdyz uz je to potreba; kvuli tomu fakt neni potreba mit stary SW na pracovni stanici.

A navzdory dlouhemu textu nikde nepadla byt jen napatrna zminka o nastrojich, co usnadni kontrolu spravneho nastaveni sshd pro 21.stoleti... ;) Protoze samozrejme i distribucni defaulty... stoji za pendrek.

Tak nastrelim aspon jeden... https://github.com/jtesta/ssh-audit ...

Díky, ten nástroj jsem neznal.

V každém případě nesouhlasím s tvrzením, že distribuční defaulty stojí za pendrek. Jejich používáním rozhodně žádné reálné riziko nehrozí, aspoň jsem nečetl o žádném případě, kdy by distribuční default vedl ke zneužití SSH. Možná snad jen s výjimkou výchozího hesla Raspbianu, ale to se těžko dá hodnotit jako zranitelnost SSH.

Tak ano, o moznem backdooru v NIST P-krivkach se "pouze" teoreticky diskutuje :-) Ale treba ani 2048-bitovy DH modulus uz taky neni "optimalni", stejne tak jako SHA1 v KEX, MAC<128b, obecne encrypt&mac algoritmy... zaver mas dobre, kryptografie se vyviji... a zalezi, jak moc paranoidni jses :-) Neni duvod pouzivat z dnesniho pohledu uz slabe algoritmy...

Protiargument "vite o nejakem realistickem utoku" jsme slychali treba i s MD5 nebo SHA1. Nejprve bylo podobne chlacholeni, ze utok vlastne neni realisticky - a pak... po nejakem case... nasledovala panika a davove silenstvi... treba v podobe vypinani podpory rsa-sha v ssh az ve chvili, kdy se staly utoky na SHA1 prakticke :-) Presne podle hesla - cekalo se, aby se pak mohlo spechat...