Vlákno názorů k článku
Pasivní metoda umožňuje získat soukromý RSA klíč SSH serveru
od Danny - No, obrana proti tomuto je celkem znama, zrovna...
-
DannyStříbrný podporovatelNo, 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.
-
Filip JirsákStříbrný podporovatelJsou 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í.
-
Filip JirsákStříbrný podporovatel
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ý…
-
Filip JirsákStříbrný podporovatel
Podepsaný důvěryhodným certifikátem ≠ pravý. Občas se někomu podaří oklamat certifikační autoritu, aby mu vydala certifikát, na který nemá nárok (když se to zjistí, řeší se to, a pokud se ukáže vážné pochybení na straně CA, odebere se ze seznamu důvěryhodných certifikátů). Takový certifikát je falešný. Kdyby nějaká certifikační autorita v EU někomu jinému (ne mému jmenovci) vydala certifikát na mé jméno, bude ten certifikát falešný. Protože tvrdí, že osvědčuje nějakou skutečnost, ta skutečnost tak ale není.
-
Filip JirsákStříbrný podporovatel
To je problem vasho zamestnavatela, on tvrdi ze je pravy.
To je případ drtivé většiny falešných věcí, že se jejich původce snaží přesvědčit ostatní, že jsou pravé. To z nich ale ještě pravé nedělá. -
DannyStříbrný podporovatel
Akorat ve firemnim prostredi vam to, cemu (ne)duverujete stanovi nejake politiky, nad kterymi koncovy uzivatel ovsem nema kontrolu. Aneb organizace stanovi, cemu se duveruje - a takto nainstalovanou CA vam ze seznamu samozrejme nic neodebere - to plati jen u verejnych CA. A takova korporatem (nasilne) nainstalovana CA si samozrejme muze vydavat co chce. A samozrejme se toho vyuziva pro ruzne security appliance, co se snazi o inspekci sifrovaneho provozu mezi koncovym uzivatelem a svetem okolo.
Plky o tom, jestli certifikat je/neni falesny jsou v technicke rovine irelevantni - anzto jediny zpusob, jak si klient ma moznosto overit pravost certifikatu je prave jen to, ze je podepsany nejakou CA, ktera je na seznamu duveryhodnych. A jak uz tu padlo, ten certifikat vam jen osvedcuje nejakou skutecnost - typicky soulad CN/SAN s hostname/emailem.
-
"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.
-
Filip JirsákStříbrný podporovatel
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.
