Názory k článku
Pasivní metoda umožňuje získat soukromý RSA klíč SSH serveru

OpenSSH and OpenSSL have included countermeasures against RSA fault attacks since 2001.

Díky, doplněno do zprávičky.

No, obrana proti tomuto je celkem znama, zrovna OpenSSL ji v sobe fakticky ma uz od roku 2001 (pricemz OpenSSH se OpenSSL bezne sestavuje)... aneb tady moc duvodu k panice neni :-) Trpi spise ostatni implementace SSH v cele treba se Zyxelem... a samozrejme to muze byt problem i jinde, kde se RSA pouziva (IPSEC, obecne vse co pouziva TLS) - ono utoky na postranni kanal u CRT-RSA se hodne resily uz v roce 2015... a uz tehda se zminovalo, ze i SSH muze byt za urcitych okolnosti zranitelne :-) V obecne rovine je obrana jednoducha - podpisy je treba vzdy radne overovat, akorat nekteri vyvojari software si obcas holt usnadni zivot a na nektere veci se vykaslou, protoze se jim zdaji jakoze uz zbytecny.

Tyhle veci nejsou zbytecny. casto jsou ale velice tezko realizovatelny. Uz jsem zazil ve dvou firmach ze spravci Linuxu odmitnuli importovat firemni CA certifikat do vsech Linux serveru, protoze by to pak museli kazdych 5 let aktualizovat. A zaroven nedali nikomu prava aby si to spravci aplikaci importovali sami.

Dalsi problem predstavuji bezpecnostni nastroje jako je Zscaller, ktere vam podvrhuji falesna IPcka, falesne certifikaty a falesne ssh klice. Pokud s tim musite zit delsi dobu, tak proste rezignujete a budete vsechno ignorovat. Jakakoliv snaha o to delat veci "spravne" je marna.

Ako to myslite 'falesne'? Su prave.

Jsou falešné. Třeba ten certifikát vystavil někdo, kdo nemá žádné právo jednat za danou doménu. Nebo falešný SSH klíč není klíč toho cílového serveru.

Zní to jako běžný korporátní MITM, obzvlášť, když je nedotažený. Certifikát šmírovadla nevnutí mezi důvěryhodné a prohlížeče se můžou zbláznit. Ony se ty "hodné" a zlé útoky docela blbě rozlišují.

IMO není větší bezpečnostní díra, než jeblý bezpečák. Stačí aby moc prudil a vycvičí zbytek firmy k tak kreativnímu obcházení bezpečnosti, až to pěkné není.

"Zní to jako běžný korporátní MITM"

Problem je, ze to nefunguje ani kdyz ten certifikat mezi temi "duveryhodnymi" je. Narazil sem na to pomerne nedavno, kdy interni web z "neznameho" duvodu nefungoval (respektive nefungovaly nektere jeho casti), a ... mohlo za to prave tohle.

No samozrejme som predpokladal spravne nastavenie a to je ze korporat vam nastavil doveryhodny certifikat a MITM proxy generuje tie podpisy. Takto to bezne funguje.

I když je ten certifikát CA zařazen mezi důvěryhodné a funguje to, pořád je ten DV certifikát falešný…

"odmitnuli importovat firemni CA"

Coz se neni moc cemu divit, protoze prakticky neexistuje zadny siroce podporovany mechanismus jak to delat automaticky a navic ti 1/2 zarizeni vynada, ze se jim ten cert z toho ci onoho duvodu nelibi, protoze neco nema, nebo naopak ma.

Resil sem to u jednoho zakaznika a vysledek je, ze sr... na to je nejlepsi postup. V opacnym pripade budes par mesicu resit nejake spolecnej prunik toho aby cert byl akceptovatelnej na alespon 80% instanci. Pak zjistis, ze je neakceptovatelny pro tebe, protoze to bude neco na tema "nejsilnejsi sifrovani je XOR" ...

Takovy krasny priklad na tema certifikaty. Starsi UPSky (APC) se sitovkama. Maximum co do toho dostanes je RSA 768 .... coz je problem, protoze ... vypinadlo v aktuelni verzi (od APC) odmita cokoli pod 1024 ... ale s http a posilanim hesel tak se to zcela spokoji ... at zije bezpeci.

Kdyby aspoň stačilo na každém zařízení ten certifikát dát na jedno místo. Ale ono je těch důvěryhodných úložišť kolikrát víc. Třeba když spouštíte Docker v Dockeru a do toho vnitřního potřebujete dostat důvěryhodnou autoritu (řešení je nedělat to). Nebo Node.js pod Windows má vlastní úložiště důvěryhodných certifikátů (protože si to s sebou táhne půlku linuxu), ke kterému lze pomocí proměnné prostředí doplnit vlastní certifikát. Jenže některé npm balíčky to ignorují, protože si s sebou přitáhnou další binárky, které berou důvěryhodné certifikáty bůhví odkud.
Ostatní soudím, že interní certifikační autority musí být zničeny.

> přirozeně se vyskytujících výpočetních chyb

Tusite nekdo, co to je? Prirozene se totiz na pocitacich vypocetni chyby nevyskytuji...

Zkuste si několikrát přečíst pár petabyte dat dokola a porovnat je...
Přesně proto jsou ty různé ECC, hashe bloků apod. aby se to nějak buď mitigovalo, nebo v nejhorším alespoň ve většině případů detekovalo.

No, ale RSA klice nejsou zadne petabyty. Pokud ten exploit zavisi na nahodnem zasahu kosmicke castice, tak se ten utocnik s nejvetsi pravdepodobnosti nedocka, pokud to zrovna neni server s tisici spojeni za vterinu.

A nebudou nějaký frekventovaný server preferovat i v tom, že je to tučnější cíl?
Pokud nechtějí krást data, ale něco provést klientům, tak budou cílit právě na servery s hromadou spojení.

To, že nějaký útok blbě funguje na servery, kam se stejně nebudou dobývat je dost mizerná útěcha.

"A nebudou nějaký frekventovaný server preferovat i v tom, že je to tučnější cíl?"

A neni jednodussi a predevsim levnejsi zaplatit kafe uklizecce?

Kosmické částice ne, ale co se týče toho, co mi občas přijde na ssh (kde je po cestě pár úseků vzduchem), tak nějakej ten error tam vidím v logu celkem často, řádově jednou za pár dní.

To je zvláštní, protože TCP/IP má vlastní checksumy, každopádně útok vyžaduje chybu při výpočtu, ne při přenosu (to by bylo hodně špatné, protože chybu při přenosu může MITM vyvolat na přání).

Při výpočtu TRSA se obvykle používá optimalizace založená na Čínské větě o zbytcích (zkráceně RSA-CRT). Při této optimalizaci se výpočet rozdělí na dvě jednodušší části, které se nakonec zase spojí. Může ale nastat případ, kdy jedna z těch částí vyjde špatně – je to správně spočítané, ale neodpovídá to tomu původnímu zadání. Tj. je to optimalizace, která někdy nedá správný výsledek, ale je podstatně rychlejší, než „poctivé“ řešení, které dává vždy správný výsledek.