Názory k článku Důvěryhodné HTTPS certifikáty na řádce pomocí nástroje mkcert
-
Ja som si generoval certifikaty na SSL testovanie cez make-ssl-cert z balika ssl-cert opisany aj tu v alternative k bodu 2: https://wiki.debian.org/Self-Signed_Certificate
-
Trochu prihrejem vlastnu polievocku. Tu su bash scripty https://file.io/2Swou8LQj8bB ktore mozete pouzit na vygenerovanie relativne subtilnej CA:
ca-01-GenerateCertificateAuhority.sh
ca-02-GenerateIntermediateAuhority.sh
ca-03-GenerateServerCertificate.sh
ca-04-GenerateKubeSecret.sh
ca-config.propertiesNajprv treba upravit ca-config.properties. Vnutri sa pouziva openssl takze ak sa vam nieco nepaci mozete si to plne prisposobit. Vyhodou je 'realnejsia' CA s intermediate certifikatom.
-
bylo by dobré říct také druhou stránku věci, útoků na vývojářské stroje, kde vývojář používá vlastní CA, který má ale položený volně na disku a je možné efektivně ho použít k MitM útokům, přibývá velice rychle.
Obvykle člověk pracuje pod jediným OS účtem, kde má vše, zajistit, že nějaký program si to proskenuje a stáhne co potřebuje zase není tak velký problém pro útočníky, spouštíme si na počítačích kde co.
-
on nemusí mít žádný přístup, jemu stačí, když ti dokáže spustit u tebe kód, tj. třeba můžeš instalovat balíček z pip/npm, který je napadený nebo využije nějakou další díru v prohlížeči a načte lokální soubory.
Třeba tenhle mkcert, pokud tomu nevěnuješ pozornost a postupuješ podle jejich návodu nebo i tohoto článku, privátní k CA ti skončí v ~/.local složce pod tvým uživatelem a není šifrovaný.
Ano, přesně tenhle přístup je na začátku napadení, podceňování rizika, pak útočník postupně získává přístup k tvým účtům a tam se objevují některé napadené balíčky, kterým logicky důvěřuješ a pěkně se to šíří.
-
Tak ještě jednou, aby to bylo jasné. Když u tebe spustí nějaký kód, tak tohle je celkem nesmyslný útok. To už si rovnou může přidat např. SSH klíč, spustit keylogger nebo něco podobného a dělat si co chce a nemusí se obtěžovat s nesmyslem CA a MITM.
Nejedná se o žádné podcenění rizika, protože tohle totiž není žádné riziko ani problém, ale až důsledek. Opravdoví problém je, že útočník na stroji spustí svůj kód. -
navštívením webové stránky se ti na počítači spustí cizí kód. Instalováním jakkéhokoliv balíčku z npm/pip a dalších se ti na počítači spoustí cizí kód. Jak to děláš, že cizí kód u sebe nespouštíš? Jak jsi si jistý, že jsi nespustil nic, co má pod kontrolou útočník?
Proto mají být ssh klíče šifrované.
Spuštěný kód pod tvým uživatelem ti třeba nedovolí změnit obsah zobrazené stránky či s ní snadno manipulovat. Přidání proxy serverů a využití instalovaného CA to dovolí snadno.
Podceňuješ riziko. Tyhle útoky běží a jsou aktuální.
-
Já žádné riziko nepodceňuji, jenom říkám, že je to důsledek jiného rizika. Je to samé jako říct, že za vás může útočník vystupovat, když spustíte škodlivý kód. Ano může a je to mnohem větší problém, než MITM. Ale pořád to riziko je právě ve spuštění škodlivého kódu, zbytek je až důsledek. Zaměřovat se na následky a prohlašovat, jak je ten důsledek obrovský problém, ale nic neřeší.
Navíc i když má útočník CA, které napadený důvěřuje, tak ho ještě musí donutit se připojit někam co ovládá tj. např. jak zmiňuješ nastavením proxy serveru. Pak ale nestačí jenom "proskenování"/stažení CA, ale musí mít útočník možnost zápisu. Pak už má mnohem lepší možnosti útoku např. snadný alias na sudo. Čímž nechci tenhle útok nijak zlehčovat, ale mnohem jednoduší je donutit napadeného přidat útočníkovu CA (např. nějakým aliasem), protože lidí co se jim válí důvěryhodná nezabezpečená CA jen tak na disku asi moc nebude.
-
Nechápeš pointu. Když se někomu u tebe podaří spustit cizí kód, tak má daleko více lepších možností, než ti dělat MitM. Ano, udělat to v případě nešifrovaného CA certu může, ale daleko efektivnější bude třeba přidat nějaký kód do .profile, .bashrc a podobných souborů nebo ukrást data k nějakému projektu v nešifrovaném $HOME.
Navíc tím, že tady ty certifikáty většinou používáš jenom ty, tak ani nemůže použít MitM na nikoho dalšího (většinou nikdo další nemá tvou CA na testování v důvěryhodných).
15. 2. 2024, 11:03 editováno autorem komentáře
-
opět je to nesmyslná racionalizace, ty útoky jsou, probíhají a útočníci na to cílí. Útočník může mít nějaké záměry, třeba získat přístup do služeb, kam se přihlašuješ, nechce být viděn a nechce dělat persistentní změny na disku (či v profilu), což se dá snadno detekovat. Ten CA mu dává moc podvrhnout ti skoro jakoukoliv stránku a nabourat komunikaci. Ve spojení s jiným útokem to může být dost fatální.
Spustit kód nemusí být doslova, může zneužít nějakou zranitelnost nějakého nástroje a přes něj si je schopný přečíst nějaká data (např. log4j zranitelnosti), nemusí mít vyloženě možnost si spustit libovolnou binárku.
Čím dál více infiiltrací do nějaké infrastruktury je přes napadené vývojáře a jejich osobní počítače. Někdy ten řetězec je poměrně dlouhý a jednotlivé kroky nemusí dávat smysl.
Mít pro uživatele CA privátní klíč pod svým účtem v čitelné podobě je prostě nebezpečné. Ten CA se instaluje do systémového uložiště a platí pro všechny uživatele, tj. vč. běžících služeb.
-
Ne opravdu mít pouze CA nestačí a nedává útočníkovi žádnou moc. Potřebuje ještě něco. Útočník buď musí donutit napadaného přijít na jeho server a nebo potřebuje udělat nějakou změnu, která, aby přežila minimálně restart, musí být perzistentní.
A ano čím dál víc infiltrací probíhá pomocí CA, ale je potřeba dodat, že se spíš jedná o firemní CA než nějaké vývojářské CA.
-
Osobně to řeším tak, že mám vybrané vývojové subdomény nasměrované na server, kde jsou součástí pravidelné obnovy pomocí Let's Encrypt.
Tytéž domény mám pak u sebe přes /etc/hosts nasměrované na localhost.
Pak jen stačí rsyncnout adresář s certifikáty ze serveru do lokálního adresáře, a můžu vyvíjet lokálně přes https:// -
Pokud si můžete dovolit ověřit certifikát LetsEncryptem třeba přes dns01 nebo http01 , tak máte velmi pěkné řešení.
Podobnou věc používáme pro wildcard certifikáty pro interní zóny pomocí acme-dns a dns01. Není potřeba ani držet ten HTTP server, stačí DNS záznamy.
Viz: https://www.root.cz/clanky/nastroj-acme-dns-pohodlne-ziskavani-certifikatu-pomoci-dns/
Nicméně nevýhoda certifikátů od LetsEncypt je, že v Certificate Transparency Logu je veřejný záznam o tom, že někdo vygeneroval certifikát, což nemusí být vždy žádoucí.
Pokud chci certifikáty pro nějakou neexistující TLD, tak LetsEncrypt použít nejde. Pokud ale LE použít lze, rozhodně bych se ho držel, souhlasím.
-
Jen tě s dovolením doplním. Zveřejnění v logu Certificate Transparency je vlastnost všech veřejných certifikačních autorit. Podle tvého komentáře by to mohlo vypadat, že to je jen vlastnost Let's Encrypt, ale tak to není. Pokud prostě chcete mít neveřejný certifikát, musíte si ho ukuchtit u sebe doma bez zapojení některé z veřejných autorit. Všechny veřejné autority dnes všechny vystavené certifikáty zveřejňují.
-
-
ano, ten log je naprosto skvělý nástroj, jak získat povědomí o struktuře nějaké organizace. Bohužel to asi ještě hodně vývojářů neví a dá se tak najít velké množství vývojových verzí různých webů, které nemají vyřešené zabezpečení, používají generické přístupové údaje nebo mají zapnuté ladící panely se spoustu zajímavých informací vč. třeba hesel do databáze (takhle jsem se třeba dostal do administrace stránek našeho nového pana prezidenta).
-
Filip JirsákStříbrný podporovatelJak píše Petr, Certificate Transparency log je povinný pro všechny veřejné certifikační autority, které jsou uznávané ve webových prohlížečích.
Stejně tak by neměla žádná uznávaná certifikační autorita vydat certifikát na jméno z neexistující TLD. Certifikační autorita ručí svým podpisem za to, že certifikát vydává oprávněnému vlastníkovi daného doménového jména. U neexistujícího TLD je problém, jak CA dokážete, že tu doménu používáte jen vy a nikdo jiný.
