Vlákno názorů k článku Stalo se: Česká pošta neradila správně od admin. - Upřímně řečeno přestože České Poště bych v každém...
-
Upřímně řečeno přestože České Poště bych v každém případě měl co vytknout, případ s certifikáty je klasickou ukázkou průšvihu celého systému s distribuovanými Trusted CA.
Podle mne je NAOPAK průser to, že vůbec někdo distribuuje s prohlížečem nějaké CA kterým pak pan Peterka slepě důvěřuje. Pokud bych se to pokusil parafrázovat jako on s pravou/falešnou poštovní doručovatelkou, pak bych řekl, že on sice nechce důvěřovat ženské stojící před ním, ale slepě důvěřuje tomu, že číslo jejího průkazu nalezl na jedné stránce v kroužkovém bloku, který dostal při koupi počítače. To, že by mu někdo mohl do toho bloku něco podstrčit , když s někým komunikuje a mění si lístky v kroužkáči mezi sebou už úplně ignoruje.
Krátce to srhnu - přednastavené CA zcela zásadně snižují bezpečenost kvalifikovaných podpisů čehokoliv. Správný postup by měl být
- vymazat všechny "důvěryhodné" CA z kompu
- nainstalovat si tam POUZE ty CA kterým OPRAVDU důvěřujete a přes hash si je důkladně ověřit z více stran
- nepracovat s vypnutým UAC ve Vistě nebo se nehlásit jako administrátor v XP pro běžnou práci
Tohle není problém ČP ale problém s důvěryhodností CA obecně. -
No vtip je v tom, že SSL komunikace jaksi nerozlišuje dva časté stavy - jeden, kdy by šlo DOOPRAVDY o důvěryhodnou šifrovanou komunikaci s důvěryhodným serverem a druhý, kde jde především o šifrované spojení a na stoprocentní identitě druhé strany není kladen až tak velký důkaz (což je dnes většina spojení). Servery bývají obvykle podepsané self-signed certifikáty nebo vlastními CA. Problém je, že mezi tím není pro BFU vlastně žádný rozdíl, takže takové ty "tanečky" prohlížeče, že nelze ověřit stránku a že nedoporučuje pokračovat a pod. je BFU (a nejen BFU - viz anketa dole pod článkem) zvyklý bez problému a bez rozmyslu odklikat a pokud je šifrovaně spojen se stránkou podepsanou důvěryhodným certifikátem obvykle vůbec nepřemýšlí o tom, co se vlastně děje a co to znamená....instalace potřebného root CA je pro něj jen a jen odstraněním zbytečných tří kliků navíc pro přístup ke nějaké stránce...
Pokud by bylo chování prohlížeče odlišné pro tyto dva případy, nebylo by obvykle potřeba instalovat než pár opravdu důležitých root CA a BFU by se teto postup lehce naučili a to že server není ověřen správným certifilátem by brali na vědomí a možná by (alespoň někteří) pochopili o co jde a na co si mají dát pozor.
Ono při tom obrovském množství předinstalovaných trusted CA je třeba vzít na vědomí různou "politiku" daných firem a že ne všude jsou v ověřování fyzické identity opravdu důslední a že není problém získat někde důvěryhodný certifikát pro podporu pishingového útoku, což by se při nainstalování pouze potřebných root CA prakticky nemohlo stát. -
Ano v podstatě s Vámi souhlasím. Jedině snad nemohu souhlasit s tím že "Šifrované spojení, kdy na druhé straně může být kdokoliv, je prakticky to samé, jako nešifrované spojení" (předpokládám, že máte na mysli například self-signed certifikáty). To není to samé, pokud přistupuji k nějakému webu šifrovaně a stejně jako u nešifrovaného spojení prostě věřím, že nejsem v tuto chvíli podváděn, pak má šifrování smysl v tom, že po cestě nikdo tuto komunikaci neodposlechne. Samozřejmě to nezabrání útoku typu "man in the middle" ale odposlechu paketů určitě.
-
No pořád hovoříme o tom samém. Šifrování self-signed nebo neověřeným certifikátem zabrání odposlechu paketů, ale nezabrání útoku s MiD. Ovšem pokud vezmu do úvahy například složitost odposlechu nezabezpečené wi-fi třeba někde na letišti nebo v kavárně a složitost v tomto prostředí vybudovat infrastrukturu pro útok typu MiD vychází mi holý odposlech opravdu mnohokráte jednodušší a především není žádný způsob jak bych ho odhalil. MiD mohu při troše štěstí a pozornosti odhalit. Máte samozřejmě pravdu, že digest auth to řeší, ovšem ukažte mi kolik reálných aplikací na webu tuto autentifikaci používá.....takže já osobně i v "holém" šifrování vidím posun oproti nešifrovanéhu spojení.
-
Jan Angelovič (neregistrovaný)Souhlasím, ale jen bych upozornil, že některé z těchto certifikátů jsou potřebné pro správnou funkci Windows.
odkaz -
Filip Jirsák (neregistrovaný)Pasivnímu odposlechu to zabrání. Ale už to nezabrání mému sousedovi na stejném WiFi segmentu poslat mi DNS odpověď dřív, než správný DNS server, přesměrovat druhý konec na jeho počítač – a pak už může spojení klidně odposlouchávat (a nejen to). Když se mu podaří HTTPS spojení hned od začátku přesměrovat na sebe (třeba na routeru), opět si může dělat, co chce. Takže to šifrování je užitečné opravdu jen v případě, kdy útočník nemůže nic jiného než poslouchat. No a na takové frikulíny stačí i obyčejná HTTP Digest autentizace, aby se nedostali k mému heslu do diskusního fóra. Cokoli důvěrnějšího stejně musím chránit lépe.
-
Filip Jirsák (neregistrovaný)Ano, mluvíme o tom samém. Ale já nemám ve zvyku spoléhat na to, že útočník je nemehlo a nezvládne nic jiného než odposlech. Mám data, která nepotřebuji nijak chránit, a pak ta, která chránit potřebuju. Do kategorie „data chráněná před nemehlem ale nechráněná před trochu schopnějším útočníkem“ v mém případě spadá přesně 0 bajtů. A nějak si nedovedu představit, k čemu by někomu bylo dobré tuhle kategorii zavádět. Ale i kdyby to někdo chtěl rozlišovat – ve zmíněném návrhu by pořád stačilo podívat se na protokol. HTTP by znamenalo spojení odposlouchávané po cestě i na konci, HTTPS bez ověřeného certifikátu spojení odposlouchávané pouze na konci :-)
-
Filip Jirsák (neregistrovaný)Z hlediska bezpečnosti v tom ale není rozdíl. Šifrované spojení, kdy na druhé straně může být kdokoliv, je prakticky to samé, jako nešifrované spojení. Pouze je nepatrně nižší šance útoku.
Problém je spíš v tom, že v současné době je rozhodnutí o HTTPS jen na straně serveru, klient rozhodnutí prakticky ovlivnit nemůže. Takže když se provozovatel webu rozhodne, že uživatele přesměruje na HTTPS, prohlížeč to chápe tak, že spojení musí být bezpečné, a klient s tím nic nenadělá. Takže prohlížeč provleče uživatele martyriem odklikávání věrohodnosti certifikátu (přičemž mu prohlížeč certifikát ani nezobrazí)…
Rozumnější by bylo, kdyby prohlížeč bral, že HTTPS je stejně nebezpečné jako HTTP a neotravoval s certifikáty. Teprve kdyby certifikát byl podepsán důvěryhodnou CA nebo si jej uživatel ručně přidal k důvěryhodným, prohlížeč by dané spojení považoval za zabezpečené HTTPS spojení, a třeba podbarvil adresní řádek. Uživatelé by se museli odnaučit, že když je v adresním řádku https://, je to bezpečné spojení – ale který z BFU dnes tohle ví. Naopak by věděli, že když je řádek zeleně podbarven, je to bezpečné spojení (takhle to asi dnes vnímají, pokud vůbec).
Ostatně by to bylo od prohlížeče férovější – dnes vás prohlížeč donutí ty certifikáty odklikat, i když jim třeba nevěříte (ale pro zobrazení jedné veřejné HTML stránky nebo třeba prohlédnutí zdrojáku ze SVN mne opravdu nemusí trápit, že se stáhne nezabezpečeným spojením), a prohlížeč si těmi otravnými dotazy jenom dělá alibi.
