Jak uživatel GitHubu certifikát pro GitHub u WoSignu získal (diskuse)

[ttt]

WoSign k certifikátům vydaným na doménu, u kterých byla ověřena jen poddoména:

Some certificates are revoked after getting report from subscriber, but some still valid, if any subscriber think it must be revoked and replaced new one, please contact us in the system, thanks.

[Meh]

Tak to byla opet sokujici novinka; certifikaty nefunguji.

[xkucf03]

Certifikáty fungují bezchybně – problém byl v procesu, jakým je tato CA vydávala.

To je jako kdybys nadával na nějaký lék – a přitom chyba byla v doktorovi, že ho předepisuje na něco jiného než má, nebo v lidech, že takovému „doktorovi“ věří.

[Lol Phirae]

Certifikáty samotné jistě fungují; infrastruktura (celá ta šaškárna kolem tisíců tzv. "důvěryhodných" CA) ovšem - zejména v oblasti DV certifikátů - notoricky NEFUNGUJE. Je naprosto zprofanovaná desítkami fatálních chyb a zcela mimo kontrolu uživatelů. Nezaručuje vůbec nic.

[Jooky (inactive)]

Bohuzial ma pravdu, v aktualnej podobe certifikaty nefunguju. Kazdy browser ma nekonecne mnozstvo CA autorit v sebe a z praktickeho hladiska sa nedaju odstranovat. Taketo problemy uz mali aj velke certifikacne autority a vysledok je, ze sa stym nic nespravilo. Prakticky staci, ze ktorakolvek autorita zlyha a cely system sa zruti.

System treba pretocit opacne. Cize nie, ze autorita "skontroluje" vlastnika a vyda mu certifikat, ale priebezne kontroluje, ci to co vidim ja, je to co by som mal vidiet.

Mechanizmus je pekne popisany tu -> BlackHat USA 2011: SSL And The Future Of Authenticity (doporucujem preskocit prvych cca 5 minut, cakaju az sa usadia ludia a nahravanie bolo uz pustene)

[pavlix]

Certifikáty skutečně po technické stránce fungují, ale problém není jenom v procesu této konkrétní jedné CA, ale v celém tom systému.

[Bedňa]

+1

[j]

Nikoli, certifikaty jsou naprosto nefunkcni koncept, kery bezpecnost naopak ohrozuje.

Protoze nemas zasnou moznsot jak se jich a) zbavit b) delegovat duveru. Tzn, pokud duverujez CA, duverujes ji vzdy a vsude, coz je asi tak stejny, jako kdyz by ti prisel automechanik operovat slepak. Sveril si mu svoji karu za 1/2M, tak mu prece veris, ne?

[ix]

Pokud web používá HSTS + HPKP, pak je HTTPS stejně bezpečné jako třeba SSH (model Trust On First Use) a žádná kompromitovaná certifikační autorita vás prakticky neohrozí.

[ix]

(teď už by to chtělo jen větší osvětu, aby HSTS + HPKP nasadily všechny HTTPS weby... na HSTS ještě občas člověk narazí, ale s HPKP je to bohužel bída, přitom nasadit to je jednoduché)

[Lol Phirae]

Bože to je zase pitomost. HSTS s diskutovaným problémem vůbec nesouvisí a pro HPKP se obvykle používá fingerprint nějaké intermediate CA.

[xm]

HPKP podporuje i otisky klíčů, nejen intermediate CA. Pak je to opravdu jako SSH. To že tam někdo cpe intermediate CA je jeho blbost.

HSTS s tím souvisí také, protože bez HSTS je HPKP k ničemu, pokud útočník prostě udělá SSLstrip útok.

[Lol Phirae]

1/ Kristova noho - podporuje != je použitelné. Nikdo nebude měnit stovky záznamů po každé aktualizaci certifikátu. A nikdo si nebude produkovat ty certifikáty do zásoby, aby se neodříznul od serveru, až ten certifikát expiruje. 2/ Ne, HSTS s diskutovaným tématem absolutně nijak nesouvisí. HSTS říká prohlížeči, že se má připojit jen a pouze přes šifrované připojení. Tečka. HSTS záznamem ve spojení s absencí důvěryhodného certifikátu akorát odříznes uživatele. Super myšlenka.

Možná by to chtělo komentovat něco, o čem máš aspoň mlhavé tušení, jak to funguje. Pro příště.

[xm]

Vypadá to, že tušení o čem mluvíte nemáte vy. V HPKP mohou být otisky klíčů, nikoliv jen samotných certifikátů. Certifikáty můžete měnit třeba každý den, ale nijak vás to netíží, protože soukromý klíč může být pořád stejný (a tedy otisk klíče v HPKP se nezmění). Pokud vám certifikát vyexpiruje, nic se neděje, ke stejnému klíči si vygenerujete nový. Třeba s Let's Encrypt je tohle děsně jednoduché a plně automatizovatelné.

Případně můžete mít určitou množinu soukromých klíčů a všechny jejich otisky napinnované v HPKP, takže můžete rotovat i klíče jako takové, pokud to z nějakého důvodu chcete. Minimálně jeden záložní otisk klíče musíte mít napinnovaný tak jako tak (kdyby došlo ke kompromitaci primárního klíče).

Je to plně použitelné (a jednoduché), na všech HTTPS serverech, které spravuji, mám takto HPKP zavedené.

A jinak kdyby vás náhodou napadlo, že rotovat certifikáty, ale mít stále stejný klíč, je rizikové, tak ani náhodou. Nežijeme už v počítačovém pravěku a TLS spojení dnes běžně používají PFS (Perfect Forward Secrecy).

[pavlix]

K čemu jsou otisky soukromých klíčů? Nebyly tím spíše myšleny veřejné?

[xm]

Eh, samozřejmě, špatně jsem se vyjádřil jestli to tak z toho vyplynulo

[xm]

A ještě doplnění k tomu HSTS. HSTS s diskutovaným tématem samozřejmě souvisí, protože se s HPKP doplňují. K čemu by vám bylo HPKP, kdyby útočník prostě jen provedl SSLstrip attack (a přesměroval vás tak na nešifrované HTTP)? Tomu právě brání HSTS.

Ale to už se opakuji

[Lol Phirae]

To nemá žádný smysl. Řešíme to, jak ověřit důvěryhodnost certifikátu. Souvislost s HSTS je absolutně nulová. A jo, opakuješ se a bohužel stále mimo mísu.

[xm]

Bezpečnost HTTPS je komplexní problém, důvěryhodnost certifikátu není jediná věc o kterou běží. Nevím proč se pořád zmínkám o HSTS tak urputně bráníte? S HPKP prostě souvisí, je založené na stejném principu (TOFU) a vzájemně se doplňují. Jedno bez druhého nemá prakticky smysl (pokud zavedete jen jedno, HTTPS bude stále vulnerable k MITM - buď vůči zkompromitované CA, nebo vůči SSLstrip útoku).

[Lol Phirae]

Nevím proč se pořád zmínkám o HSTS tak urputně bráníte?

Protože to nijak nesouvisí s tématem debaty. HSTS diskutovaný problém NIJAK neřeší.

[j]

Ne, to neresi vubec nic, ono problem neresi ani DANE, ale aspon ho redukuje. V pripade DANE se totiz problem zredujuje z tisicu CA na prave jednu. A kdyz nic jinyho, tak si cznic rozhodne nepodepise .net/.org/... => existuje tu jednoznacna delegace aspon per tld.

[xm]

To tedy řeší. Mám-li v browseru napinnované otisky klíčů webů kam chodím pravidelně, pak jsem proti MITM zkompromitovanou CA naprosto bezpečně chráněn. A útočník při pokusu o MITM se ihned prozradí (včetně toho jakou CA zneužil).

Pokud se jedná o web kam chodím jednou za uherák, či nějaký web který jsem nikdy předtím nenavštívil, pak mě pravda HPKP neochrání. Ale i tak se nesmírně zmenšuje window of opportunity k útoku a pro útočníka se zároveň nesmírně zvyšuje riziko prozrazení (čímž by přišel i o svoje falešné certifikáty / kompromitovanou CA).

Navíc prohlížeče mají dneska pinnované klíče k hromadě významných webů už ve výchozí instalaci (viz např. Chromium / Chrome a Mozilla), takže na těchto webech potenciální útočník vždycky pohoří a prozradí se (weby jako Google, Twitter, Tor, Dropbox, atd.). Takhle už Google objevil třeba falešné certifikáty od DigiNotaru.

[j]

Tvole ty ses totalni tatar ...

Vubec netusis o cem je rec, ale zvanis porad dokola ty svoje vyblitky. V browseru si muzes mit co chces, klice se na webech bezne menej, a to i velmi casto. A ty vis naprosto kulovy a nikdy vedet nemuzes, jestli tu zmenu proved nekdo kdo je k tomu opravnenej nebo ne.

Pokud bys chtel bezpecnost, tak by sis musel obstarat cert trebas osobne od provozovatele, a ten by musel pravidelne predem zverejnovat klic novej, aby sis ho moh aktualizovat. A to pomijim samo to, ze je deravej srv a nekdo si vystavi svuj cert.

Google objevil leda prd, ten tak maximalne smiruje vsechny a vsude, proto vymyslel uzasnou "technologii", poslete nam certy od vseho kam lezete, at pekne vime co kde delate ...

Tatar jako ty pak samo nemuze pochopit takovou trivku, jako ze ti proste znemoznim se zeptat na cokoli kolem platnosti klice, pokud uz na tebe delam MITM, tak mam tu linku pod kontrolou. A co udela browser kdyz se mu nepovede overit pripadnej revoke? Mno pekne tise drzi hubu.

[xm]

Podle způsobu vyjadřování bych na Tatara tipoval spíš vás

O čem je řeč zjevně netušíte vy. Pokud používám HPKP, mám na serveru zapinnovaný otisk klíče a ten se nemění. Mění se certifikáty, ale to vás netrápí, protože jsou vystaveny ke stejnému klíči a tedy jeho otisk (který máte zapinnovaný) zůstává stále stejný i když se certifikát změnil.

To že mi MITM útočník zabrání zeptat se na cokoliv kolem platnosti certifikátu mě netrápí, protože pokud mám už zapinnovaný otisk klíče, browser rovnou vyhodí velké varování a nikam dál vás nepustí. To je prostě model TOFU (Trust On First Use), stejně jako u SSH. Neochrání vás to při návštěvě webu který jste nikdy předtím nenavštívil, ale zcela bezpečně vás to ochrání při návštěvě webů které navštěvujete pravidelně, třeba právě toho GitHubu.

Zbytek nemá cenu komentovat, to je jak mluvit s šíleným konspiračně-teoretickým magorem, který si stále jen dokola opakuje svojí mantru. Prohlížeč má otisky klíčů důležitých webů zapinnované (preloaded) už přímo v základní instalaci (jak Chromium/Chrome, tak Firefox). Nikam se nic neposílá aby se to ověřovalo.

[pavlix]

Jak přesně to řeší běžné provozní události jako jsou právě změny těch provozních klíčů?

[xm]

Otisky záložních klíčů (které drží člověk nejlépe offline) se rovnou pinnují spolu s primárním klíčem. Pinnovat můžete kolik otisků klíčů najednou chcete, to nijak omezené není, ale minimum by mělo být právě 2 (primární klíč plus záložní klíč, použitelný pokud by došlo ke kompromitaci toho primárního). Bez záložních klíčů by jste si v případě kompromitace primárního klíče web totálně odřízl (lidé co už ho navštívili by se na něj nedostali dokud by nevypršela platnost HPKP hlavičky).

Nebo jak to myslíte?

[Josef Kufner]

Pak je ještě otázka, jak tohle podporují systémové knihovny v Androidu. Třeba takový Davdroid pro synchronizaci kalendáře přes CalDAV. Nebo IMAP klienti. Tam je ten problém s důvěryhodností certifikátu stejný.

[oracle]

Hagar Němec být?

[Kooala]

Spis bych to videl tak, ze se shledl v nejakem pohadkari. Zni to ve stylu: "Jak hloupy Honza ke stesti prisel." Mne se to docela libi, jen tak dal.