Vlákno názorů k článku HTTPS by mělo být všude od JohnDoe - http://prntscr.com/8jdujw - 1.381 s, 13% slower than HTTP

Ano, systém je nabořený, to ale neznamená, že by neměl smysl, kdyby fungoval správně.

Přesně to si myslím. Že je rozbité PKI neznamená, že celé HTTPS nebo obecně TLS nedává smysl.

Spíš: kdyby se správně používal. Systém je jen nástroj a funguje dobře*, přesně tak, jak má** – je na jeho uživatelích***, jak ho budou používat – jestli si mezi důvěryhodné CA dají i ty nedůvěryhodné, jestli neomezí platnost CA na určité (sub)domény (což X.509 podporuje), jestli odkliknou kdejaké okno, které na ně vyskočí, jestli si nastaví mizernou politiku a budou provádět lajdácké kontroly; nebo třeba jestli budou nesmyslně často měnit certifikát a znemožní tak uživatelům kontrolu.

*) neřešme teď slabé šifry nebo chybné implementace nebo dokonce malware
**) prakticky jedinou výtku, kterou k tomu mám je, že by mohl umožňovat přibalit více certifikátů (od více nezávislých CA – jako je tomu u GPG) k jednomu veřejnému klíči.
***) tím nemyslím jen koncové/běžné uživatele – uživatelem tohoto systému jsou všichni včetně správců serverů, CA a DNS a ISP, prostě všichni.

DANE ale nepřináší žádné zlepšení – je stejně „špatné“ jako ty DV certifikáty akorát z té „špatnosti“ dělá normu. Resp. ono není špatné ani jedno – prostě je to jen určitá úroveň zabezpečení/dů­věrnosti – někomu stačí, někomu ne – ten musí použít něco lepšího (EV, doplňky do prohlížeče, další nezávislou cestu k ověření certifikátu atd.).

Ad „Když je útočník schopen mi manipulovat se spojením, může za mě klidně potvrdit správu domény a získá si platný certifikát“

A stejně tak ti může nastavit DANE záznamy.

Ovšem pokud útočník může manipulovat jen* se spojením mezi uživatelem a serverem (a ne se spojením správce toho serveru), tak může přesměrovat DNS záznamy na jiné IP adresy nebo přesměrovat TCP spojení, ale není mu to nic platné, protože nebude mít důvěryhodný certifikát (muselo by dojít k dalším chybám a selháním – nicméně sama o sobě možnost manipulace se spojením žádné riziko nepředstavuje, maximálně DoS).

DANE prostě dává smysl jako doplněk** stávající infrastruktury, ne jako její náhrada.

Jde vlastně o jakousi druhou CA, která může také potvrdit pravost certifikátu a tím zvýšit úroveň zabezpečení. Pro úspěšný útok by pak muselo dojít k selhání dvou subjektů (správců CA a správců DNS). Ovšem pokud bychom se spoléhali jen na DANE, dojde naopak ke zhoršení, protože stačí, aby selhal jeden systém/subjekt – DNS – veškerá odpovědnost je pak na něm (dokonce ani není potřeba útočit na spojení a přesměrovávat TCP/IP – když už můžu manipulovat s DNS, tak si nastavím záznamy na svoje servery).

*) což bude velmi častý až nejčastější případ
**) nezávislý kanál pro ověření certifikátu resp. distribuci jeho otisku

Nikoliv, DNS záznamy nepozorovaně nezměníš, protože DANE záznamy jsou podepsané pomocí DNSSEC. Proto je to moje vlastní certifikační autorita, kterou mám v moci jen já a důvěryhodnou cestou distribuuji otisky jejich klíčů.

Ad „kterou mám v moci jen já“

To právě není pravda – pouze jsi ze správce dané TLD udělal CA a všechna odpovědnost je teď na něm.

Zatímco dříve byla odpovědnost rozložená mezi několik subjektů a pro úspěšný útok muselo dojít k selhání na více frontách – např. CA + DNS, nebo CA + ISP. Pokud dojde jen k jednomu selhání, tak se celkem nic neděje – buď se útok odvrátí tím, že se certifikát vyhodnotí jako nedůvěryhodný, nebo máš sice „důvěryhodný“ certifikát, ale je ti k ničemu, protože uživatelé se připojují na ten pravý server, ne na ten tvůj.

Pak je tu ještě možnost, že selže prohlížeč (e-mailový klient atd.) resp. počítač uživatele a pak je v háji všechno, takového uživatele nic nezachrání*. Kompromitovaný prohlížeč může komunikovat se serverem útočníka, ukazovat správné doménové názvy i platné certifikáty a uživatel si ničeho nevšimne. A v tom případě DANE taky nepomůže.

Co mi na současných certifikátech chybí je to, že CA může být jen jedna. Lepší by bylo, aby jich mohlo být i víc, jako je tomu u GPG (tam se jim sice neříká CA, ale v principu to CA jsou). Jde o to, aby pravost certifikátu potvrzovalo víc nezávislých subjektů, více nezávislými kanály. Některé z nich můžou být klasické komerční CA, jiné komunitní CA, jiné tvoji přátelé, kteří potvrdí, že vidí u dané domény stejný otisk certifikátu… a jedním z těch kanálů může být DANE, kam ten otisk vyvěsil správce serveru (a věříme správci TLD potažmo celému systému DNS, že to mohl udělat jen oprávněný správce serveru). A informace z těchto více zdrojů od více autorit se pak sečtou a dohromady vyhodnotí a z toho vyjde, jestli se dá tomu spojení věřit nebo ne.

DANE tedy vnímám pozitivně v tom, že může být tím dalším (a relativně nezávislým) kanálem, který potvrdí pravost certifikátu.

Právě těch více nezávislých zdrojů informace dává smysl a představuje zlepšení situace. Zatímco nahrazení jednoho zdroje jiným jedním zdrojem žádné zlepšení není (naopak to může být zhoršení, protože ta jediná autorita je „shodou okolností“ tentýž subjekt, který může zařídit i nasměrování spojení na servery útočníka)

*) leda HW tokeny, jednorázová hesla atd. prostě rozložit práci na víc zařízení, aby ta odpovědnost nebyla jen na jednom, a doufat, že neselžou všechna najednou (což se v případě počítače + „chytrého“ mobilu klidně stát může, ale pořád je to lepší než jen jedno zařízení)

Dozví se z kořenové zóny. DNSSEC není možné popřít, protože je podepsaná kořenová zóna. O tom rekurzor ví a bude ty podpisy vyžadovat. Jakákoliv další informace už musí být podepsaná, včetně informace o tom, že následující zóna podepsaná není. I to musí přijít důvěryhodnou cestou.

V opačném případě by fungoval downgrade attack a nedávalo by to smysl. V kořeni je napsáno, že o TLD .cz. se starají servery CZ.NIC a jejich klíč je X – tato celá informace je podepsaná. Takto to pokračuje dál až k výsledku nebo k informaci, že dále už se nepodepisuje – ale toto musí být taky zasláno v podepsané zprávě. Tedy není to možné podvrhnout ani zapřít, v obou případech bude výsledek nevalidní a podvržená informace se uživateli nepřeloží.

Zneužít něco takového je poměrně obtížné, musel by se simulovat a podepisovat celý falešný DNS strom a to by bylo vidět. Velmi rychle by se na použití něčeho takového přišlo a celý ten systém by se stal nedůvěryhodným. Určitě to není stejně běžná praxe jako transparentní proxy na Wi-Fi AP, která přidává vlastní obsah.

"Proto mi vadí, když se to tak čenobíle staví..."

Možná to jen černobíle vidíte. ;-)

Ad „Kdyz prohlizec drzi hubu na http, MUSI presne stejne drzet hubu na https. Naprosto nezajem jaky certifikat se pouziva nebo nepouziva. “

Přesně tak – tohle je naprosto dementní chování. U nešifrovaného spojení není uživatel nijak* upozorněn, že může být odposloucháván nebo že mu můžou být podstrčena jiná data, než jaká vystavil provozovatel serveru.Uživatel má pocit, že je vše v pořádku a žije v blažené nevědomosti.

Ovšem když přijde na stránku se samopodepsaným certifikátem, tak ho prohlížeč vyděsí šílenou hláškou a uživatel se nikam nedostane. Přitom to není o nic méně bezpečné, než ten první případ.

Prohlížeč by se k tomu měl chovat stejně. U samopodepsaných certifikátů je ta výhoda, že zabrání v činnosti pasivním odposlouchávačům (kteří jen poslouchají, ale nemění přenášená data).

Pouze v případě, že jde o server, který už uživatel navštívil a posílají se nějaká data z klienta, by to měl prohlížeč zastavit a varovat uživatele, pokud došlo ke změně certifikátu.

*) kdysi bylo v prohlížečích alespoň jednorázové varování při POSTu

Prohlizec bohuzel dnes sam nedokaze jednoduse odlisit, kdy je self-signed certifikat zamerne (z vule administratora) a vse je v poradku a kdy je skutecne podstrcen.

Tvurci webovych aplikaci samozrejme - pokud k tomu pristupuji seriozne - pouzivaji HTTPS uz davno. A uzivatele jsou samozrejme ujistovani, ze to je bezpecne a ze se nemusi bat. Pristupoval byste treba do banky pres HTTP? ;-) A jak byste chtel z pohledu bezneho uzivatele u HTTPS rozlisovat, ze mu muze byt podsouvan podvrzeny obsah? :-)

Samozrejme uzivatel ma moznost si chovani i u self-signed (nebo i corporata CA) zmenit, doplnit dany konkretni certifikat do seznamu tech, kterym veri. V cem je vlastne problem? Nekoho obtezuje tech par kliknuti? ;-)

Když se navrhuje bezpečnost, musí se navrhovat pořádně a ne s vědomím toho, že jsem tam nechal prostor pro man-in-the-middle útok, protože každý si může vymyslet svůj certifikát a na webu to projde. Taková věc nedává smysl, já bych takhle třeba SSH používat fakt nechtěl. Čili nějaký systém nezpochybnitelné důvěry v pravost klíčů potřebujeme. Jestli to bude certifikát, otisk v doméně nebo telepatický přenos je druhá věc. Ale nemůžeme na to rezignovat s tím, že to je uživateli buřt a nevadí to.

Já jsem tu několikrát tvrdil, že PKI model má své slabiny, netvrdím, že je dokonalý. Ale zásadní rozdíl mezi internetem a fyzickým světem je to, že zatímco ve fyzickém světě můžu zajít do své banky a znám svého řezníka, v případě připojení na PayPal mám dost smůlu a asi tam po obědě nemůžu skočit ověřit klíče. A pokud navštěvují takových systémů sto, je to dost zásadní problém. Opakuji znovu: bylo by fajn, kdyby někdo přišel s něčím lepším. Zatím nic lepšího není.

"Prohlizec bohuzel dnes sam nedokaze jednoduse odlisit, kdy je self-signed certifikat zamerne (z vule administratora) a vse je v poradku a kdy je skutecne podstrcen."

Dokáže velmi jednoduše. Prostě jej má v seznamu důvěryhodných certifikátů, kam jej uživatel nainstaluje ve chvíli, kdy se ujistí, že ten veřejný klíč skutečně sedí s veřejným klíčem serveru, kam se chtěl připojit.

To, že to uživatelé nedělají a odklikávají něco v rozporu se zásady bezpečnosti, je věc jiná.

Pricetny admin prosly certifikat vymeni, zvlast kdyz je upozornen.. :-) No jo, chtit po adminovi, aby delal svou praci, to je opruz :D

Nehrabu se v krabicich, kterym nerozumim. A u tech, kterym rozumim to problem fakt neni, i kdyz jsou 10+ let stare.

Ze to nekde muze byt zbastlene je klidne mozne - ale to jsou hracky v cenove kategorii takove, ze je muzete obmenovat stejne casto jako treba telefony s tim, jak se technologie vyviji - zpravidla se tim i usetri na provoznich nakladech. A u civilizovanych zarizeni je seriova konzole vyvedena ven :-)

"Ovšem když přijde na stránku se samopodepsaným certifikátem, tak ho prohlížeč vyděsí šílenou hláškou a uživatel se nikam nedostane. Přitom to není o nic méně bezpečné, než ten první případ."

Tak tohle je dárek z minulosti, kdy se rozlišovalo mezi obyč stránkou a "důležitější" s https*. Prohlížeč celkem správně musí upozornit na případ, kdy stránka má být zabezpečená, ale není možné ověřit crt.

Kdyby to prohlížeč nedělal, tak klidně můžeš podstrčit selfsigned crt nějaké banky, prohlížeč by uživateli neřekl ani slovo a data by proudila přes mitm proxy útočníka. Tohle asi nechceme.

*) Přičemž tento koncept je naprosto mimo mísu. Nelze rozhodnout, které informace jsou více důležité a které méně. Navíc se to mění v čase, zažil jsem projekty, které začínaly jako jednoduchá stránka, ze které postupně vyrostl informační systém a nikdo si nevšiml, že by bylo taky potřeba to nějak chránit.

Ad „Prohlížeč celkem správně musí upozornit na případ, kdy stránka má být zabezpečená, ale není možné ověřit crt.“

Tohle je právě ta pointa. Kdy má být zabezpečená?

Pokud jsem na ní už někdy v minulosti byl a certifikát se od té doby změnil, je upozornění na místě. A dvojnásob v případě, pokud u ní má prohlížeč uložené cookies a chystá se je odeslat nebo pokud to není GET, ale POST, kterým se odesílají nějaká data z mého počítače (což může být i heslo do té banky nebo k e-mailu).

Ale pokud jsem na té stránce poprvé a navíc nehrozí, že by došlo k vyzrazení důvěrných dat (cookies/POST), tak není důvod uživatele strašit a obtěžovat – stačí signalizace nějakou ikonkou v adresním řádku (je to podobné jako obyčejné HTTP, resp. o kousek lepší, bezpečnější).

"Kdy má být zabezpečená?"

Tehdy, kdy je schéma https.

"Ale pokud jsem na té stránce poprvé a navíc nehrozí, že by došlo k vyzrazení důvěrných dat (cookies/POST)"

Cookies/POST přece nejsou jediné informace putující od klienta k serveru. Už třeba jen seznam GET může být v některých případech zdrojem cenných dat. Určitě nechci, aby si to mohla po cestě číst MITM proxy s nějakým (mému prohlížeči) neznámým crt.

To, že je nějaká aplikace interní a neveřejná, vůbec neznamená, že by neměla DNS záznam. Naopak těch interních aplikací, ke kterým se přistupuje přes IP adresu, nebude mnoho. A navíc už dnes asi budete velmi těžko shánět certifikát na IP adresu od nějaké uznávané certifikační autority.

Těžko soudit bez kontextu, ale discovery můžeš dělat hodně rozdílnými metodami, není to zdaleka jen DNS vs hosts vs IP.

Hodně firem/organizací má vlastní interní domény, které nejdou zvenku (z Internetu) přeložit, Stejně tak mají vlastní CA.