Role certifikačních autorit v boji proti phishingu a malwaru

V příspěvku na blogu otevřené certifikační autority Let's Encrypt (zprávička) je řešena role certifikačních autorit v boji proti phishingu a malwaru. Bude Let's Encrypt vydávat certifikáty také podvodným serverům a tím posilovat jejich důvěryhodnost? Dle Let's Encrypt nemůže certifikační autorita ručit za to, že servery nejsou zneužívány k nekalým činnostem. I kdyby se certifikát vydával až po důkladném prověření serveru, certifikační autorita nemůže zaručit, že po vydání certifikátu se na serveru stránky s phishingem nebo malwarem neobjeví. Mnoho lidí je ale přesvědčeno, že certifikační autorita by servery prověřovat měla. Let's Encrypt tedy bude, i když tím nesouhlasí, k prověření serverů využívat Google Safe Browsing API a odmítne vydat certifikáty serverům označeným jako podvodné.

30.10.2015 01:00 | Ladislav Hagara | Zajímavý článek

Komentáře

[Jardik]

Certifikat chcu, abych mel sifrovane spojeni, ktere mi nikdo nebude odposlouchavat a menit komunikaci, to jestli je na strankach kybl sra*ek je nedulezite.

[source]

Naprosto souhlasím. Mělo by se to prezentovat jako ochrana před odposlechem a ne jako na https vám nic nehrozí. Tohle podělali.

[j]

Jiste a sefl signed certifikatem se sifrovat neda ... presne ukazujes na naprostou imbecilitu vsech vyvojaru prohlizecu. Browser proste NESMI mit zadny "duveryhodny" autority, a NESMI mit zadny kecy. Kdyz vlezes na http, tak taky zadny pindy nema. Https je presne totez.

Teprve az se uzivatel rozhodne, ze na nejakym konkretnim webu mu o bezpecnost jde, tak si ulozi bud primo cert webu nebo treba v kombinaci s CA, ale autorizuje ji jen pro ten konkretni web. Pak terpve by mel prohlizec nadavat, kdyz se neco zmeni.

[xm]

HTTPS s certifikátem podepsaným "důvěryhodnou" CA sice neochrání proti nation-state útočníkovi (který si prostě u CA vynutí podpis svých falešných certifikátů), ale aspoň ochrání proti hromadě potenciálních útočníků když se člověk připojí k Internetu v nedůvěryhodné síti (rozuměj kdekoliv jinde než u něj doma - a i tam hrozí evil ISP).

A proti nation-state útočníkům tě už dnes ochrání HSTS v kombinaci s HPKP (prostě cerificate/public key pinning). To samozřejmě vyžaduje, aby webové stránky HSTS + HPKP měly nasazené, což bohužel ještě není tak časté (a samozřejmě znamená to model TOFU - Trust On First Use - podobně jako u SSH).

Nicméně klíče "důležitých" webů (zatím pokud vím Google, Tor, Cryptocat, Twitter a Dropbox) jsou napevno pinnované přímo v prohlížečích (jak Chrome/Chromium, tak Firefox), takže tam to máš zaručené.

[elenril]

Mě tady dost irituje, že jeden mnohem lepší bezpečnostní mechanismus, než všechny tyhle nesmysly s CA, už existuje -- DNSSEC+TLSA. Ale z nějakého důvodu na něj vývojáři prohlížečů kašlou (v Chrome byl příslušný feature request uzavřen s wontfix). Kdybych byl paranoik, tak bych si skoro myslel, že o skutečnou bezpečnost (tj. takovou nad kterou nemají oni kontrolu) nestojí.

[dumblob]

DNSSEC + TLSA v zadnem pripade nelze povazovat za bezpecnejsi nez CA ekosystem. DNSSEC + TLSA je totiz plne centralizovany a to samo o sobe je povazovano za nebezpecne. CA ekosystem umoznuje volitelne mnozstvi zcela nezavislych autorit a zavisi na koncovem uzivateli (nejcasteji napr. na vyvojarich weboveho prohlizece), ktere podcasti bude verit a ktere ne.

Nakonec podotknu, ze silne zalezi na implementaci techto porovnavanych mechanismu a k dnesnimu datu bych si vsak troufnul odhadnout, ze DNSSEC + TLSA by bylo aktualne skutecne bezpecnejsim resenim nez ten momentalne porouchany ekosystem CA.

[pavlix]

DNSSEC+TLSA rovněž umožňuje nezávislé autority, jenom se o tom tolik nemluví.

[dumblob]

Hm, diky. Ja jsem zpovidal pana Ondreje Sureho pred cca dvema roky a tehda z toho vyplynula prave ta centralizace v praxi. Neni nekde vice informaci o implementacich decentralizovane casti (at jiz jenom SW ci primo testovaci nasazeni v provozu)? Docela by me to zajimalo.

[pavlix]

Hm, diky. Ja jsem zpovidal pana Ondreje Sureho pred cca dvema roky a tehda z toho vyplynula prave ta centralizace v praxi.

Taky jsem s tím lidi z CZ.NIC konfrontoval, ale oni si jedou tu linii, na kterou jsou zaměřeni, tedy na globální hierarchii vázanou na hlavní klíče root domény. Nicméně co jsem se bavil s jinýmy, ač jsem zatím neměl důvod to přímo vyzkoušet, lze pro libovolný podstrom nakonfigurovat jiné klíče. Pokud by byl o takovéto použití zájem, jistě není do budoucna problém diferencovat úroveň důvěry na základě toho, od kterého master klíče je odvozena.

[dumblob]

Nicméně co jsem se bavil s jinýmy, ač jsem zatím neměl důvod to přímo vyzkoušet, lze pro libovolný podstrom nakonfigurovat jiné klíče.

Az takhle jednoduche to je? No, to se mi zacina libit. Kde najdu ty "jiné", se kterymi bych se mohl pobavit jak to vyzkouset na vlastnich DNS serverech?

[pavlix]

Třeba...

[elenril]

Tahle argumentace se mi vůbec nezdá. V každém případě musí člověk někomu věřit. U TLSA věřím především registrátorovi a správci příslušné TLD (root se podvrhává celkem těžko). U současného systému CA musím věřit desítkám "autorit" z všemožných pochybných míst, a každá může podepsat úplně cokoliv. Takže TLSA mi vychází jako výrazně lepší.

[j]

Zarucene mas leda starou backoru. Viz nedavna akce na tema klice od googla. A ze se na to prislo? No kdyz budu utok provadet vyhradne na konkretni cile, tak se na to neprijde.

[xm]

Pokud budeš MITM útok provádět na stránky, které podporují key pinning (buď podporují HPKP nebo jsou pinované přímo napevno v prohlížeči, jako třeba servery Google), tak se na to samozřejmě přijde ať je ten útok sebecílenější.

Prostě tvůj cíl má už fingerprinty uložené v prohlížeči a když na něj uděláš MITM, prohlížeč zařve a nepustí ho dál.

Jediný případ kdy by ti ten útok mohl vyjít je v případě HPKP pokud bys zachytil první komunikaci daného člověka s daným serverem (stejně jako třeba u SSH). V případě napevno pinovaných otisků v prohlížeči ti ale ani tahle malá šance nevyjde.

[Bedňa]

Tak oni vlastne chceli upozorniť na to že CA nieje antivirus.

[eghuro]

Ten "ťuťu-ňuňu" pseudo-ochranářský princip se mi nelíbí. Certifikáty mají být transportní ochrana, nikoliv ochrana před "problémem mezi židlí a klávesnicí". Navíc, proč zrovna Google safe-browsing?

[chrono]

Navíc, proč zrovna Google safe-browsing?

Kto okrem nich poskytuje také API?

[Ruža Becelin]

Bla bla bla, myslime to s vami dobre, bl bla ale my musime, bla bla bla Google Unsafe Search API...

Tak to jo...

[Ovrscout]

heh, prvni verze webu před přidělením certifikátu bude samozřejmně bez virů a ošklivého obsahu. Takže bez revokace certifikátů je to celé pro kočku. Nicméně, ta myšlenka není úplně špatná. Představa že by bance nebo novinovému serveru zrušili certifikát protože jim tam někdo šoupnul nějaké svinstvo je docela zábavná :D to by byl fofr s opravama.

[Conscript89]

Takovi nebudou pouzivat Let's encrypt. Proste je to dvoji metr.

[trekker.dk]

Mnoho lidí je ale přesvědčeno, že certifikační autorita by servery prověřovat měla. Let's Encrypt tedy bude, i když tím nesouhlasí, k prověření serverů využívat Google Safe Browsing API

Jo to si dovedu představit, jak to asi proběhlo:

Let's Encrypt: Nechceme prověřovat servery.
Nejmenovaný tvůrce webového prohlížeče: Fajn, nedáme Váš kořenový certifikát do [nejmenovaný prohlížeč]
Let's Enctypt: (uvědomí si, že tím celý projekt jde do prdele) Tak jo, budeme prověřovat servery

Zajímavé je, že ostatní certifikační autority prověřování nedělají a není to problém. Akorát tady někdo prostě vycítil, že může využít svojí síly a zatlačit. Škoda, že v LE kejvli a nevytáhli to na světlo.

[johniez]

No, ale treba u startcomu mi zamitli certifikat s cislici 4 v nazvu domeny, protoze by mohlo dojit k zamene za "a" (napr.: c4j -> caj). Takze sice neproveruji, ale zase uplatnuji jina pravidla.

[Slavko]

Na dosiahnutie pocitu bezpečnosti na Internete je potrebné bránu (gateway) obložiť vložkami Always!

[pavele]

Nějak to https pořád nechápu:

1. Budou se dávat certifikáty úplně všem a pak to bude sloužit na to, aby nebyla vidět moje komunikace s protistranou.

Kam ty certifikáty budu dávat, do databáze, nebo bude můj prohlížeč kontaktovat nějakou třetí stranu, kde si stáhne příslušný certifikát?

2. Chci mít ověřeno, že internetová stránka patří bance a ne někomu, kdo se za ni vydává. V bance mi dají certifikát nebo jej vystaví na netu a já si jej importuju do prohlížeče.

3. Nebo to má fungovat na principu "Sebereme jim certifikát, aby se uživatelé nedostali na závadné stránky"?

4. Z jakého důvodu bych měl mít(mám) v prohlížeči certifikáty firem/společností, které neznám a kteří si pouze zaplatily za tyto certifikáty?

[johniez]

Pro zacatek: https://cs.wikipedia.org/wiki/HTTPS

[Bedňa]

"CA" je len autorita ktorá potvrdí že máš platný kľúč na šifrovanie, nič viac nič menej. Nieje to antivírus, antispam, bezpečnosť je stále na tebe a ani zmena vlády to nezmení, stále si to musíš overiť sám.

[pavele]

A ten(ty) platný(é) klíč(e) je(jsou) napevno v mém webovém prohlížeči a mění se podle verze prohlížeče a podle toho, co určí výrobce prohlížeče?

Tak proto je to bezpečné, že výrobce prohlížeče natvrdo zadrátuje ty klíče do svého softwaru?

[Bedňa]

Tvorcovia prehliadačov, môžu, alebo nemusia danú CA uznať, je to len o tom. Takže sa môže stať, že budeš upozornený o nedôveryhodnom certifikáte.

Kľúč nič okrem šifrovania nerieši. Takže keď budeš chcieť mať istotu že lezieš do banky vyťukaj si abcbanka.cz a nelez tam cez odkazy napríklad z emailu.