Názory k článku HTTPS by mělo být všude

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.

A jak by se Vám líbilo, když by Vám do veškerého http provozu Váš ISP injektoval reklamu? (Což už se dneska děje)

Ano, hodně nepoučených uživatelů odklikne i podvržené certifikáty, takže to bude na nic.
Je tady ale i skupina poučených uživatelů, kteří by rádi věděli, zda se připojují ke správnému serveru a že po cestě jim nikdo do obsahu nic nevkládá.
Váš názor je stejně nedokonalý, jako názor zrušit bezpečnostní pásy v autech, protože se vždy najde někdo, kdo je používat nebude.

Prosím, kdokoliv má možnost napsat další článek, kde shrne nevýhody. Zatím tu ale žádné reálné nepadly: jen že to je k ničemu, je to složité, drahé a celkově tak nějak vůbec problém. Jakou by mělo pro uživatele nevýhodu, kdyby měl Root zapnuté SSL?

Nebo jinak: Jakou má pro uživatele nevýhodu, když je web LinuxDays.cz za SSL? Zhoršuje mu to nějak situaci? Nebo mně jako správci toho serveru?

Problém hodně lidí je v tom, že si myslí, že pokud https nevyřeší všechny problémy světa, tak je celý špatně.

Ano, HTTPS není lékem na všechny problémy webu, ale řeší jich dost, takže má smysl ho nasadit.

Amen, amen, pravím vám.

Odpovědí na tuhle otázku je celý článek, pod kterým je tahle diskuse. Těch výhod je celá řada, mně stačí už jen to, že mi žádná místní Wi-Fi nepodstrčí do stranky svůj kód.

Znám aspoň tři bezpečnostní důvody, proč provozovat HTTPS místo HTTP:
1) http://j.mp/1FtQAEF
2) http://j.mp/1G2ciuB
3) http://j.mp/1FtR5yJ

Jaké znáte bezpečnostní důvody pro HTTP místo HTTPS?

Niekde bezpecnost nieje potrebná.

To muze vypustit z ust (klavesnice) tak akorat clovek, ktery znamych slabin sam aktivne zneuziva a stve ho, ze okoli mu hazi klacky pod nohy ;-)

Jsem na to stejně. Ale to není argument tam, kde to jde. HTTP nikdo nezakáže.

Nikdo netvrdí, že HTTPS vyřeší všechno.
Můžete být konkrétní, jaké problémy HTTPS přináší?
Zabezpečit komunikaci na 100% se nikdy nedá. Nikdo ale přece netvrdí, že HTTPS vyřeší všechny problémy světa. Nebo snad ano?
Máte pravdu, že bezpečnost není vždy potřebná. Ale když je, tak to není nic proti ničemu. Zvláště, když HTTPS neřeší jen bezpečnost, ale i integritu přenášených dat, zrychlení komunikace mezi klientem a serverem, atd.

Celé špatně je na tom to že se to někteří snaží protlačit úplně na vše a že prohlížeče budou buzerovat uživatele že ten jeho oblíbený blog o křečcích a morčatech není šifrovaný.

A je nějaký objektivní důvod, proč by blog o křečcích a morčatech nemohl používat HTTPS?
Nedávno jsem si zřizoval osobní web server www.flajshans.cz a získání cerifikátu a konfigurace HTTPS byla otázkou několika málo minut.
A vím, že návštěvníci mého webu jsou odolní proti těmito útokům, resp. injektáže do http provozu (ať už ze strany ISP nebo infikovaných routerů po cestě):
http://j.mp/1G2ciuB
http://j.mp/1FtR5yJ
http://j.mp/1FtQAEF
Já nevidím problém v tom, aby uživatelé byli varování při vstupu na http stránky, že to není bezpečné/zabez­pečené. HTTPS je další krok ke zvýšení bezpečnosti oproti HTTP.
Mě zřízení certifikátu (zadarmo) trvalo pár minut. A až bude rozchozeno letsencrypt.org, tak to bude ještě jednodušší. Tak proč se tomu bránit? Já nevidím jedinou bezpečnostní výhodu HTTP oproti HTTPS...

A kdo mi to zaplati? Kdo mi zaplati, ze to budu resit pro davno zapomenuty weby za ktery mam petistovku rocne? Trapi to ctenare krecku? trapi to provozovatele krecku? Netrapi. Tak proc jim to chcete direktivne vnucovat? Horsi je uz jen EU.

Nedělejte z toho drama. Já jsem si zřizoval SSL od www.startssl.com pro svůj web www.flajshans.cz. Bylo to zdarma a stálo mě to 5 minut času včetně nastavení web serveru. Nevím jestli trápí čtenáře křečků to, že po http streamu jim tam může infikovaný router na cestě ze serveru k čtenáři injektovat do stránky škodlivý kód, ale mě jako provozovatele trápí to, aby čtenář dostal do webového prohlížeče tu samou stránku, kterou servíruji z web serveru.
A nikdo to nebudete direktivně vynucovat, prohlížeče nezapomenou HTTP. Jen při vstupu na HTTP stránky budou uživatele informovat, že to není tak bezpečné jako HTTPS (a mají pravdu).

No a tohle pravě řeší Let's Encrypt, kde nemusím nic vyplňovat, studovat a konfigurovat. Na VPS spustím jeden příkaz nebo to za mě vyřeší provozovatel mého web hostingu. Automaticky budu mít k dispozici HTTPS.

Resi? Skutecne je spravne pouzity pritomny cas?

Ano, oni to řeší dost intenzivně :-). A start je slíben na listopad, což je za humny.

Ano, to už se vážně čtenářům křečkům stalo. A injektáž HTTP provozu začíná být běžnou praxí. Viz
http://j.mp/1FtQAEF
http://j.mp/1G2ciuB
http://j.mp/1FtR5yJ

Stačí?

Ano, za pět minut jsem schopen z nich vydolovat certifikát. Je faktem, že už jsem tam zaregistrován a tuny podmínek se čtou jen registraci. Takže ano, při první registraci strávíte 20 minut registrací a pak už vydávání certifikátu jde samo. A že jim dáváte osobní údaje? No a co? Když kupujete něco na netu, tak jako doručovací adresu zadáváte nějakou falešnou nebo snad žádnou?
No a před koncem vypršení mi přijde mail, kliknu na odkaz, vygeneruji si během chvíle nový certifikát. A to je problém?

Kdo mi to zaplati? Chvile je to snad pro jednu domenu. Vite kolik je treba 100x chvile?

100x chvíle je jeden script

Tak to nedělejte. Buď je to mrtvej web, který bude dožívat na HTTP nebo je to normální web, který se neustále v čase vyvíjí a tam už se dá HTTPS začlenit v rámci normální evoluce.

a kdo ten nepotrebny nesmysl (v kontextu toho webu) zaplati? Jo to byly krasny casy kdyz jsem si mohl dovolit byt idealista a snilek.

Pokud je to mrtvej web, do kterého nechcete už vrážet ani čas, ani peníze, tak ho necháte žít na http. Pouze uživatelům při vstupu na tento web se zobrazí navíc hláška, že http není tak bezpečný jako https.
Pokud je to normální web, který se s časem vyvíjí, tak je to otázka několika málo minut času, kdy můžete mít jak hotový certifikát, tak nakonfigurován web server. Žádné drama se nekoná.

Naopak, jakou by to melo pro me vyhodu?

Rozdil je kdyz je to volny trh - zalezi jak se zakaznik s poskytovatelem domluvi nebo kdyz to nekdo nekomu vnucuje. Kdyz to spravce toho serveru chce tak prosim.

Však taky nikdo provozovatele webu nikdo nutit do HTTPS nebude. Jen při vstupu na HTTP upozorní browser uživatele, že HTTP není tak bezpečný jako HTTPS a že stránky nemusí odpovídat tomu, co poslal provozovatel webu do netu. Je to jen uvedení faktů na pravou míru.

Váš problém je v tom, že přisuzujete HTTPS schopnost spasit veškerou bezpečnost internetu. To ale nikdo netvrdí.
Z Vašeho pohledu je tedy lepší nenasadit HTTPS, kde jsou nějaké hypotetické (a zatím ne moc reálně zneužitelné) problémy a místo toho provozovat HTTP, který může číst/modifikovat kterýkoliv jouda, co sedí se mnou na wifi v kavárně?

Už několik autorit z důvěryhodných zmizelo, například DigiNotar, nebo CNNIC.

Osobně mi z uživatelského pohledu mnohem víc vyhovuje PKI než PGP. Když mi přijde podepsaný e-mail S/MIME od neznámého člověka, můžu certifikáty prozkoumat a případně i pročíst certifikační politiky a získat tak nějakou představu. Pokud mi přijde podepsaný e-mail pomocí PGP od neznámého člověka s klíčem který je podepsaný dvaceti dalšími lidmi, které vůbec neznám, nevím vůbec nic a nemám se čeho chytit.

2)-4) nastesti lze resit nezavisle na zavadeni https (netvrdim, ze snadno)

ad 2) Stále jsem nepochopil, jak vydáním dalšího veřejného certifikátu (který bude naprosto shodný (snad kromě času podpisu)) na tu samou žádost CSR ze strany serveru mohu číst komunikaci klient-server, kde server disponuje privátním klíčem, který samozřejmě nevydal CA. Můžete být konkrétní?
ad 3) Takže když já nebo jakýkoliv čínský hacker zajde za Thawte, StartSSL, atd. a řekne jim, že chce vydat EV cerifikát pro google.com, tak jim ho vydají?
ad 4) HTTPS neřeší bezpečnost ze strany třípísmenných organizací. Nehledě na to, že nestačí jen získat falešný certifikát, musíte umět zfalšovat DNS dotaz (řeší v blízké budoucnosti DNSSEC) a přesměrovat provoz na straně klienta (pro realizaci MITM). Pokud jste v hledáčku "třípísmenné organizace", jednodušší a levnější je vás vzít pod waterboarding a všechno jim vyblejete.

Ad 1) Ano, běžně toto certifikační autority dělají. :-) Ony si totiž ani nemusí generovat další certifikát. Na to by jim stačil ten samý certifikát, který vydali. Proč generovat další certifikát, že...
Ad 2) Máte důkazy nebo aspoň důvěryhodné náznaky, že se tak děje? Co se týče mě, není nic těžkého říct... Prostě mi ho nevydají. Ani Vám.
Ad 3) Máte nějaké důkazy nebo aspoň proof of concept, že by šlo plošně a automatizovaně PKI obcházet? Proč o tom nikdo nehovoří (krom Vás)? Že by ostatní topili v kyselině a na Vás zapomněli?
Teď už tady chybí jen chemtrails a (ne)přístání amíků na měsíci. :-)

Já to vzdávám... Vracím se k HTTP a jdu bombardovat svoje banky, eshopy, atd., že HTTP je bezpečnější než HTTPS a ať koukaj hned HTTPS vypnout...

Jeden z nás neumí pochopit čtený text. Já nikde v článku nemohu najít, že nasazením HTTPS bude vše čisté a krásné. Já v něm vidím to, že nasazením https se zlepšuje bezpečnost a nevidím tam ani, že spoléhat se jen na https je skvělý nápad.

Od zacatku to nikdo nezpochybnuje pro takove sluzby. Zpochybnovan je prinos u ethernet meridel, blogu o kreccich, beznem zpravodajstvi apod.

HTTPS má přínos všude, kde to technicky nasadit lze. Klidně i u ethernet měřidel (pokud to umožňují), blogu o křečcích či běžném zpravodajství.
Jak jsem psal v několika postech, kde jsem uváděl odkazy, injektáž http provozu je dnes již běžná (jednoduchá a hlavně levná) záležitost, takže když se připojím z mobilu na měřák teploty v baráku přes https, tak budu mít jistotu, že nějakej vtipálek u ISP mi do stránky nevloží reklamu, která mi třeba zboří strojové zpracování stránky na mé straně nebo si ze mě nevystřelí a nebude manipulovat s vysílanou teplotou v baráku.

Google mění certifikáty často, protože to dělá jeho CDN. Na každém node je nainstalovaný jiný certifikát a při každém požadavku je uživatel pomocí DNS odpovědi nasměrován jinam. Proto také komunikuje s jiným node a dostane jiný cert. To je známá věc. Ovšem všechny ty certifikáty jsou vystavené jednou společnou autoritou: Google Internet Authority G2.

Takže musíš věřit Google místo abys věřil Google? Kde je rozdíl? Obojí (certifikát i autoritu) spravuje jedna firma.

Že se točí pořád několik node je logické, rozhoduje se podle IP adresy tazatele a nějakých dalších podobných parametrů. Jinými slovy těžko tvoje IP adresa jednou dostane odpověď z Irska a podruhé z USA, pokud tedy vše v Irsku funguje. Ale jak říkáš, otázka je, jak velký je ten node, může jít taky o nějaký cluster.

"S HTTPS se snižuje riziko odposlechu, ale pro 3písmenkové organizace, kteréžto mají (o tom nepochybuju) přístup k CA, o nic moc složitější než HTTP."

Jaktože to není o nic složitější? U nešifrovaného protokolu se "podívám a vidím" a klient o tom ani neví.

To, že má někdo přístup k CA vůbec neznamená, že má k disposici soukromý klíč.

Takže pokud udělá MITM útok, tak nutně použije jiný veřejný klíč (který nechá podepsat se stejnými údaji jako původní crt, ale veřejná část klíče bude jiná). A tam je to snadno detekovatelné.

"Jak se o tom klient dozví ? To už se tu právě řešilo, kdo kontroluje fyzické klíče ? To je nereálný. Navíc, prohlížeš mlčí při změne klíče, když je to korektní změna. Tož opět by dotyčný musel místo systému CA důvěřovat konkrétímu kliči (certifikátu). A o tom to celé je."

Dozví se o tom každý klient, který se o tom chce dozvědět. Nástroje na to jsou. To je obrovský rozdíl oproti nešifrovanému spojení, kde klient neví nic.

Pokud by to tedy 3 písmenková agentura změnila, tak by bylo triviální to zjistit. Tak hloupí zase nejsou.

"Třeba u nás jedna firma měla problém..."

Toto je krásná ukázka funkce evoluce. Firma to dělala blbě, poškodila sama sebe, tak si to musela zlepšit.

"Jen opakuju, nebrojím proti šifrování, jen nemám rád systém CA jako takový. Proto mi vadí, když se HTTPS vydává za spásu bezpečnosti a soukromí."

Já také nemám systém CA nějak v lásce a rád bych byl za DANA, ale v tomto případě vidím problém v tom, že v https hledáte něco, co nikdo neříká. https tady je jako lepší alternativa http, se všemi svými výhodami a nevýhodami.

Navíc, je to pouze transportní kanál. Nikdo nikomu nebrání šifrovat ještě data samotná v tomto kanálu. A běžně se to dělá.

Já stále nechápu, kde furt čtete, že s HTTPS je všechno zabezpečené?!?

Je fakt srandovní, jak odpůrci HTTPS tvrdí, že HTTPS nezaručuje 100% bezpečnost a že je tedy špatné, když nikdo z příznivců toto netvrdí!

Článek pojednává o tom, že s HTTPS se zvyšuje bezpečnost oproti HTTP, ale rozhodně netvrdí, že řeší 100% bezpečnost internetu. To je tak těžké pochopit čtený text?

Zřejmě to, že na rozdíl od AES na ten Blowfish+Serpent nemáš HW akcelerátor ;-).

Nevím, navíc pochybuji, že by to ten software uměl hned použít. I AES-NI se přidával do programů a OS postupně.

Přesně od té doby, kdy je podmínkou pro provoz HTTP/2. Článek to vysvětluje.

Vypravej nam jeste chvili o hysterii ;)

Za prvé: Protokol HTTP/2 podporuje i nešifrovanou variantu, takže vaše první věta je nepravdivá.

Za druhé: Tvůrci prohlížečů moc dobře vědí, proč HTTP/2 nepodporují v nešifrované variantě. A ve skutečnosti za tím není ani tak snaha šifrovat všechno za každou cenu, jako spíš pragmatičnost.

Spousta uživatelů je totiž stále za proxy servery, které HTTP/2 nerozumí, přičemž nelze zaručit, že by takový proxy server byl buď detekovatelný a komunikující strany by tak zůstaly u HTTP/1, nebo naopak plně transparentní, takže by HTTP/2 obsah procházel beze změn. Důsledkem by pak bylo, že někteří uživatelé by měli problém načítat obsah z HTTP/2 serverů, což by tlačilo na poskytovatele obsahu HTTP/2 nezavádět (stejná situace nastala před lety u IPv6). Požadavek šifrování u HTTP/2 tak zejména zaručuje integritu přenášených dat mezi serverem a prohlížečem bez ohledu na mezilehlé proxy servery.

Od té doby, kdy je šifrování nutnou podmínkou pro možnost použití pokročilejšího protokolu.

Broskvovina to není a každý si to může zkusit pomocí odkazu, který je v článku uveden.

Ja vam poradim, co uz od zakladu delate ve svem prikladu spatne - kdyz uz chcete srovnavat. V tom prvnim testu zcela vynechavate sitovy stack :-) A to nejsem hnidopich a nechci videt, jak mate nastavene to SSH, pro objektivni srovnani dopadu sifrovani nevhodnou konfiguraci lze ten "test" znacne zpomalit ;-)

Pokud nechápete rozdíl mezi obecným tvrzením „Šifrování zrychluje“ a konkrétním tvrzením: „Šifrování webu má také pozitivní dopad na rychlost jeho načítání.“, pak vám asi bohužel není pomoci.

A jinak zkuste SSH s HPN patchem. Klasické OpenSSH není optimální pro přenos objemných dat. :P

Ach, hned první věta říká: "PRISM is a clandestine[1] surveillance program under which the United States National Security Agency (NSA) collects internet communications from at least nine major US internet companies."

Jsem nevěděl, že celý Internet je 9 amerických ISP... :-)

Jak říká Wikipedie: [citation needed]. Google, Facebook, Twitter i třeba Dropbox nebo Amazon mají servery v Evropě a mnoho dalších firem taky. Český provoz jde velmi často jen přes NIX.CZ nebo jiný místní peeringový uzel, lidé z NIXu tvrdí, že české firmy k přes ně odbaví průměrně okolo 70 % provozu, někdy i víc. Jaký by byl důvod to „historicky“ posílat přes Ameriku, když se data dají vyměnit tady? Technicky pro to žádný důvod neexistuje, je to naopak drahý složitý a pomalý způsob.