Vlákno názorů k článku Co dál s WoSign? Odebrat důvěru už nestačí od Heron - Zároveň by to znamenalo krach zmíněných firem, které...

Tak on je spíš problém v tom jak ty CA vlastně fungují. Nejlepší ověření mé identity jsem zažil u CACert.org (což je autorita, která se nikdy nedostala do prohlížečů). Dva doklady totožnosti, face to face ověření člověkem, který o tom (technologii) dost věděl. Jak jsem psal, nikdy nebyla v prohlížečích, takže celkem naprd.

Druhé ještě relativně dobré ověření bylo u Postsignum, od které mám kvalifikovaný osobní crt. Na pobočce to dělala úřednice, co absolutně nevěděla která bije, ale tak alespoň ověřila občanku (snad). Relativně ok. Má to jen tu chybu, že CA není v prohlížečích, resp. už se to distribuuje ve Windows. Takže taky skoro k ničemu.

Potom tu jsou DV certifikáty, které dostanete od libovolné CA, pokud alespoň na chvíli máte pod kontrolou: email nebo dns záznamy nebo web na dané doméně. Ověření zcela nulové.

Do této kategorie vstoupila LE, kde stačí mít přístup k webu v době ověřování a crt je váš. Opět ověření nulové, ale na rozdíl od jiných CA za to nechtějí peníze.

No a asi největší šarádu jsem zažil u renew (po heartbleedu) jednoho drahého OV certifikátu, kdy "ověření" proběhlo tak, že na uvedené telefonní číslo zavolala operátorka možná z Indie, které jsem vůbec nerozuměl a ona vůbec nerozuměla mě. Nakonec stačilo říct jen město sídla firmy a certifikát byl můj. Nejdražší CRT, co jsem kdy měl v ruce, ověření zcela nulové (to, že vám někdo zavolá na telefonní číslo, které vy sami uvedete v dané žádosti, není ověření, to je parodie).

Problém je, že z hlediska uživatele není mezi DV a OV žádný rozdíl. EV má v adresním řádku uvedenou firmu, ale upřímně řečeno, jak dopředu víte, jestli dané stránky mají mít zelený adresní řádek nebo nemají? Nevíte. Takže mezi DV, OV a EV není žádný rozdíl. K DV se dostane kdokoliv. K OV ve správnou chvíli taky. EV jsem zatím nedělal.

Takže teoreticky PKI funguje skvěle. Důvěřujete CA, která vydává crt jen těm komu má. V praxi to funguje tak, že crt dostane po zaplacení kdokoliv. Takže CA v praxi jsou jen o tom, že od vás vybírají peníze za to, že máte jejich root crt v prohlížeči.

A to jsem se vůbec nedotkl pochybení ca. Prostě už jen to, jak to funguje v praxi (ca dá tomu, kdo zaplatí), je kompletně rozbité. A všem je to asi jedno.

Čím to nahradit, no ono by v první řadě stačilo, kdyby CA dělaly svou práci (tedy ověřování komu to vlastně dávají) a kdyby za každé pochybení byl někdo skutečně postihován včetně zneplatnění všech jejich root a inter crt. Jinými slovy tak, jak to má fungovat už teď.

Vždy je nutné nějakým způsobem si ověřit, zda se skutečně připojuji na server, kam chci. Tedy musím si jiným kanálem ověřit minimálně fingerprint crt (nebo ho rovnou získat celý a naimportovat si jej do klienta). V tomto mi PKI nijak nepomáhá, tam jen vím, že tento crt vydala tato autorita. Víc nevím. Server si tak jako tak musím ověřit nějak bokem. Pokud to bokem bude pomocí DANE z DNS (zabezpečeného přes DNSSEC), tak asi dobrý, jestli to stačí já nevím.

Ne, ssh klient se mě při prvním připojení zeptá, zda je to opravdu ten server, na který se chci připojit. A zobrazí fingerprint klíče toho serveru. Já jej ověřím a dám yes, pokud to sedí. Nebo jej dopředu dám do known_hosts. Tedy úplně stejně, jako se zachová webový klient, když jdu na nějaký https web s neznámým crt. Musím ověřit fingerprint a nebo si dát crt toho webu do důvěryhodných.

Navíc u ssh je to ověření oboustrané, protože na tom serveru musím mít svůj klíč, jinak se tam nepřihlásím. Na webu je bohužel přihlašování pomocí osobního certifikátu jen velmi výjimečné.

U ssh lze mít podepsané crt od ca, akorát se to moc nepoužívá. Takže chování těch věcí je vlastně úplně stejné, pouze s tím rozdílem, že na webu se víc používají crt od (důvěryhodných) ca, zatímco u ssh příliš ne. Ale lze to.

MTA taky dorucuje sifrovane, a je mu uprdele i to, ze vsechny ty klice sou davno expirovany.

Klíč expirovat nemůže, protože nemá date, ale pokud někdo akceptuje neplatný crt tak je to jeho problém. Opakuji problém, vydávat to za normální stav nebo snad výhodu nelze.

Vůbec celé to tvoje osmibodové desatero by se v podstatě dalo přeložit: "chci aby to fungovalo, kdysi jsem to nějak nastavil, už nevím jak, a už mě s tím neotravujte." Případně ještě hůř: "těším se na data všech těch klientů, kteří se připojí na můj mitm server a vůbec nic uživateli neřeknou".

je zcela v bezpeci, tak muze libovlna CA kterych ma v systemu desitky, vydat libovonej dalsi

No to je samozřejmě známý problém a právě proto je nutné všechny CA, které se dopustili takto závažného pochybení, z těch prohlížečů vykopnout. Ale tento problém se rozhodně nevyřeší tak, že prohlížeč bude úplně všechno ignorovat, jak neustále dokola opakuješ.

Zepta se te poprvy a naposled, pricemz ten fingerpint je svazanej se zcela konkretni adresou/IP.

Stejně jako prohlížeč se mě zeptá jednou na pro něj dosud neznámý crt. A když si jej přidám, tak už se víc neptá. Na druhou část už jsem odpovídal. To, že prohlížeč neobsahuje možnost s tím pracovat trochu víc (třeba připnout konkrétní crt na konkrétní adresu je chyba, ale existují pluginy nebo třeba HPKP).

Prihlasovani do toho netahej, kdyz sshcku reknes ze se pripojit muze kdokoli bez hesla, tak se proste pripoji, ale sifrovat se bude.

Přihlašování do toho tahám, protože to považuju za nedílnou součást toho připojení. To, že to jde vykastrovat na věci nic nemění.

A uzivatel o bezpecnost nestoji

Zajímavé. O kousek níž se strachuješ o lidi z OKD nebo z firem, které krachnou, ale současně bys je nechal jít (třeba) do bankovnictví prostřednictvím klienta, který vůbec nic neřeší, takže snifování provozu nebo mitm se stává hračkou i pro mentálně postižené script kiddies.

Všichni si asi uvědomují, že současný stav rozhodně není ideální, ale je stále řádově mnohem lepší, než tvůj slavný prohlížeč, který na jakoukoliv bezpečnost z vysoka kašle a kde by bylo získání přístup k zajímavým datům toho uživatele hračkou.

A ne, vykonutim "nekterych" CA se nevyresi vubec nic. Protoze celej koncept CA je od pocatku zcela vadnej. A jasne, je udrzovanej v chodu a to vyhradne proto, aby si ofce myslely, jak sou v bezpeci, pricemz jak statni tak soukromy smiraci si vesele a v klidu muzou smirovat koho chteji. Staci mit pristup k libovolny "duveryhodny" CA.

Jenže to je věc, která se dá dost snadno odhalit. Stačí používat pluginy jako cert partol a když se z ničeho nic na konkrétním webu změní crt (ale je stále platný), tak na to uživatele upozorní. A kdyby se ty vládní agentury mohly dostat k soukromému klíči na tom serveru (aby se nezměnil pár klíčů), tak už rovnou mají přístup k těm datům a nemusí dělat útok na spojení. Nehledě na to, že se dá vždy použít end to end šifrování ale tak se opět řeší tentýž problém, jak předat klíč druhé straně.

"A kdyby se ty vládní agentury mohly dostat k soukromému klíči na tom serveru (aby se nezměnil pár klíčů), tak už rovnou mají přístup k těm datům a nemusí dělat útok na spojení. "

To neplatí, pokud máme PFS. Pak je nutné udělat MITM (v čemž ale útočníkovi nezabráníme).

To neplatí, pokud máme PFS.

No ale když už ses na tom webserveru, máš přístup k aplikaci a jejím datům, tak už tě PFS nezajímá.

To dost záleži:

* Možná ziskali plný přístup, možná jen read only, možná jen část dat (jako u heartbleed) a možná šlo o starší data (vyřazený disk).
* Ne všechna přenášená data se musejí na serveru ukládat.
* Bonus: Ne vždy jde útočníkovi o čtení těch dat. Někdy je chce upravit. To se mu například s read-only přístupem takto přímo nepovede.

Ok, dobře. Já jsem to myslel tak

... k soukromému klíči na tom serveru (aby se nezměnil pár klíčů), tak už rovnou mají přístup k těm datům a nemusí dělat útok na spojení.

že se skutečně dostanou na ten server a získají ten soukromý klíč, tedy se dostanou minimálně na úroveň práv toho webserveru a typicky i té běžící aplikace (soukromý klíč je ale stejně na disku přístupný jen pro roota, který nastartuje proces webserveru a dropne mu práva - a když už má někdo roota ...). Jasně, situace může být mnohem složitější, to je pravda.

Jenže sdílení privátních klíčů mezi servery je považováno za bad practice. A zrovna v případě Google to má u uživatele snadné řešení – stačí si zapinovat jejich mezilehlou autoritu, ze které jsou všechny ty serverové certifikáty odvozeny.

ze si provozovatel DNS samo muze do DNS dat co chce

DNS není centrální systém ale distribuovaný. Svou zónu si můžeš provozovat na svých NS, podepsat si ji svým klíčem (kterej pošleš do upstreamu a sdělíš jim, že tvoje zóna je podepsaná atd. prostě dnssec).

Takže provozovatel toho webu a provozovatel NS té zóny může být stejná osoba (právnická / fyzická). A jestli jí nedůvěřuješ, tak bys nejspíš vůbec neměl na ten web chodit.

Kdyz se tvuj registrator rozhodne, ze si tvoji domenu presmeruje jinam, tak stim taky nic neudelas. Tvoje vlastni DNS tomu nijak nezabranej.

Technicky tomu sice nezabrání, ale všichni budou přesně vědět, kdo to udělal. Což mu sice nemusí zabránit to udělat, ale současně kdyby to udělal, tak se může stát, že už s ním nikdo jiný nebude chtít spolupracovat.

Což je poměrně velký rozdíl oproti stavu bez dnssec, kdy si záznamy může po cestě ke klientovi změnit každý router a jen těžko se dopátrá, kdo za to může. S DNSSEC je to naprosto jasné.