Názory k článku Postřehy z bezpečnosti: všechny prohlížeče opět pokořeny

OK, takže někomu pošlu tajný link (Google Docs, fotky na různých CDN, …), on na něj klikne a půjde udělat MITM?

„Prohlížeč by se k takovému webu měl chovat tak, jako by k němu přistupoval přes HTTP.“

OK, tím se teoreticky řeší výtka směrem k cookies a same-origin policy. V praxi bych ale čekal nějaké implementační chyby. Už to je pro mě dostatečně závažný problém, abych byl proti při současném stavu, kdy se HTTPS s dobrým certifikátem (byť někdy s jinými chybami) nasazuje čím dál častěji. Zvlášť když je na obzoru Let’s encrypt…

Neřeší se tím ale přečtení tajné adresy (zmíněno výše, můj bod 1), náhlý downgrade (kliknu na přihlásit a najednou je to nešifrované, můj bod 2 a 3). Řeší se tím trochu mixování „dobrého“ a „špatného“ HTTPS, protože to spadne na mixed content, ale chtělo by to pak důraznější hlášku a podporu ve všech prohlížečích.

Dejme tomu, že všechny chyby v certifikátech tedy nějak co nejbezpečněji ignorujeme nebo přeměníme na mixed content, jak bylo výše. Dejme tomu, že varování na mixed content bude přiměřeně důraznější. Dejme tomu, že se podaří bez výjimek vyřešit zmíněné věci jako cross-origin policy, což sice není neřešitelné, ale při velikosti zdrojáků dnešních prohlížečů to rozhodně není práce na jedno odpoledne. A co tím získáme? Bude se 1 ‰ (?) stránek bez důvěryhodného certifikátu, kde někdo ale trvá na používání HTTPS, zobrazovat bez varovné hlášky. Za cenu možnosti náhlého downgrade spojení. Cool.

Jinak nemám nic proti zavedení neautentizovaného šifrování, pokud to pojede na „http://“. (Ostatně se o tom uvažovalo v souvislosti s HTTP/2.) Tam adresa žádné zabezpečení neslibuje a zmíněné problémy odpadají. Včetně zmíněných praktických implementačních problémů.

Ty tajné linky snad vedou na weby s HSTS (které explicitně říká, že se má použít HTTPS). Náhlý downgrade je dnes možný, pokud web nepoužívá HSTS – a ty tři hlášky v prohlížeči na tom nic nemění. Podle mne by naopak měl mít i uživatel možnost (v čistém prohlížeči, bez nějakých doplňků) označit nějakou doménu, že k ní chce přistupovat pouze přes HTTPS (třeba tím, že si přidá odkaz s https do oblíbených). Obrana proti náhlému downgradu spočívá v tom, že ho prohlížeč nedovolí bez souhlasu uživatele – a že ten souhlas bude vyžadovat skutečně jen v nutných případech.

Hlavně doufám, že mixed content a downgrade se brzy vyřeší protokolem HTTP/2.0 bez podpory nešifrované verze v prohlížečích a podporou DANE.

OK, pošlu ten link někomu, kdo na té cílové doméně ještě nebyl, takže nemá HSTS záznam. (Nehledě na to, že HSTS dnes ještě není samozřejmost.) Dnes je to OK – pokud link dojde v pořádku, není jak provést downgrade. (A pokud někdo může ten link po cestě měnit, máme větší problém, ale někde jinde…) Pokud bychom ale povolili zmíněné insecure HTTPS, už to OK nebude. To je IMHO mnohem větší problém než chybová hláška u pár webů, které trvají na HTTPS, ale ani dnes nemají platný certifikát.

Ano, HSTS na vyžádání uživatele by bylo pěkné, ale neřeší to tento problém. Zabezpečenou cestou dostanu link s „https://“ na web, který ještě neznám, tak mi někdo udělá downgrade. A navíc: zkuste to lidi naučit používat.

HTTP/2 možná bude motivovat k přechodu na HTTPS. Spíš než DANE IMHO uspěje Let’s encrypt, aspoň v dohledné době. Větší nasazení HTTPS možná povede k HTTPS by default a varování u plain HTTP, ale to je hudba budoucnosti.

Pokud uživatel na tom webu nikdy nebyl, stejně musí zkontrolovat, že je na správném webu a že používá zabezpečené připojení.

Pokud někdo odvozuje bezpečnost z toho, že někde vidí link začínající na https, dělá to špatně. Správně to má udělat tak, že ten link otevře v prohlížeči, a teprve pak kontroluje, zda je na zabezpečené stránce. Pro lidi je to snadné, nemusíte je učit zkoumat odkazy z e-mailů a odkazy z webu a odkazy odjinud – místo toho je naučíte, že bezpečný web má v adresním řádku zeleně zobrazenou informaci o zabezpečení.

Let's encrypt je hračka pro pár geeků, s bezpečností pro uživatele to nemá vůbec nic společného.

„Pokud uživatel na tom webu nikdy nebyl, stejně musí zkontrolovat, že je na správném webu a že používá zabezpečené připojení.“

1. To, že to vede na správný web, je otázka pro odesílatele linku. Pokud budu odtam obsah pouze konzumovat (číst), nemusím se starat až tak o to, kam to vede.
2. Touto cestou by to vypadalo asi tak, že prvně unikne tajná URL a až pak se to (v lepším případě) dozvím.

O Let’s encrypt sice koncoví uživatelé moc vědět nebudou, ale pokud to zvýší nasazení HTTPS, tak je troufalé říkat, že „s bezpečností pro uživatele to nemá vůbec nic společného.“.

Pokud se nestaráte o to, kam odkaz vede, je vám jedno, že se dostanete někam jinam. To s únikem tajné URL je pravda, ovšem je to zcela okrajový případ ve srovnání s tím, co škod napáchá, když jsou uživatelé vytrénováni, že pro zobrazení webu musí odklikat spoustu nesmyslných hlášek.

Nejde o to, zda o Let's encrypt budou nebo nebudou vědět koncoví uživatelé. Jde o to, že to bude používat pár nadšenců, kteří vědí, že mají web zase jen pro nadšence. Nikdo jiný to používat nebude, protože by skončil přesně v té situaci, že jeho uživatelé budou muset odklepávat spoustu hlášek o nedůvěryhodném certifikátu.

„Pokud se nestaráte o to, kam odkaz vede, je vám jedno, že se dostanete někam jinam.“

Scénář 1:
Franta mi pošle zabezpečeným kanálem prosbu, jestli bych mu zkontroloval jeho text na https://test-review.example.com/5mD3D4S9X0uuZSrysKgmQA . V této chvíli nepotřebuju vědět nic o tom, kdo spravuje test-review.example.com – ostatně mu žádná svoje data neposkytuju, ta mu poskytl Franta, který mu věří. Kliknu na odkaz, který mi Franta poslal zabezpečenou cestou a u kterého Franta explicitně chtěl, abych jej načetl přes HTTPS. Jenže někdo mi downgradne spojení. I pokud následně zkontroluju, zda jsem na správné adrese (ale podle Vás je blbost kontrolovat linky), dopadne to v nejlepším případě v tomto stylu: http://www.lamer.cz/quote/50132

Scénář 2:
Pepa si prohlíží fotoalbum na webu. Stránku jako takovou si načte zabezpečeně (její URL by mi nepomohla), ale fotky jsou uloženy na tajných adresách v CDN, kde downgradnu spojení a dostanu se k fotkám.

Kdo by takto fotoalbum navrhoval? Třeba Facebook…

Scénář 3:
Jdu na stránku výrobce tiskárny stáhnout třeba ovladače. Jdu na https://my-printer-vendor.example.com, najdu si ovladač ke své tiskárně, kliknu na odkaz. Jejda, on mi někdo downgradnul spojení a já si stáhl upravený ovladač s nějakým škodlivým kódem.

Ne, nemyslím, že by to byl okrajový problém. Naopak, nějaké ‰ webů, jejichž admin vyžaduje HTTPS, aniž by si pořídil důvěryhodný certifikát, je dnes okrajový problém. A s Let’s Encrypt bude ještě okrajovější.

Souhlasím, že není dobré obtěžovat uživatele zbytečnými varováními. Odeslání formuláře nešifrovanou cestou je dobrým příkladem zbytečného varování.* Naproti tomu ale neplatný certifikát je celkem odůvodněné varování a je jen otázka, jakou má mít podobu.

„Nikdo jiný to [Let’s Encrypt] používat nebude, protože by skončil přesně v té situaci, že jeho uživatelé budou muset odklepávat spoustu hlášek o nedůvěryhodném certifikátu.“

To je dobrá úvaha, ale na základě nesprávných předpokladů – Let’s Encrypt bude crossignuto s Identrustem a budou usilovat o pozici kořenové CA. Hádám, že minimálně ve Firefoxu se jim to povede velmi brzy.

*) Pokud vyplním formulář na HTTP, data mi může odeslat někam JS automaticky, a to, že se to odešle na jinou stránku přes HTTP je už detail. Smysl by mělo maximálně varovat před odesláním formuláře na zabezpečené stránce na nezabezpečenou stránku – v podobném duchu jako mixed content.

Scénář 1 - není problém ten odkaz otevřít tak, aby se vynutilo bezpečné spojení. Scénář 2 a scénář 3 - není rozdíl mezi současným stavem a tím, co jsem popisoval.

Neplatný certifikát na webu, jehož bezpečnost mne vůbec nezajímá, není odůvodněné varování.

Hádám, že minimálně ve Firefoxu se jim to povede velmi brzy.
Vždyť o tom celou dobu píšu. Bude to pro pár nadšenců, kteří vědí, že na jejich web chodí jen pár lidí s jediným správným prohlížečem.

Scénář 1: Jak?

Scénář 2: Teď to neprojde, dokonce uživatel nejspíš ani nedostane možnost odklepnout nezabezpečené spojení, prohlížeč to odmítne.

Scénář 3: Teď by prohlížeč varoval před nezabezpečeným spojením. Navíc, pokud má server HSTS a navštívil jsem jej v minulosti nebo je na HSTS preload listu, pak uživatel ani nemůže odklepnout varování.

„Neplatný certifikát na webu, jehož bezpečnost mne vůbec nezajímá, není odůvodněné varování.“ — Jak ale prohlížeč zjistí, že jeho bezpečnost mě vůbec nezajímá?

„Bude to pro pár nadšenců, kteří vědí, že na jejich web chodí jen pár lidí s jediným správným prohlížečem.“ — Myslím, že IdenTrust není zrovna málo akceptovaná certifikační autorita. Jako bonus se to nejspíš rozšíří do Firefoxu jako kořenová CA (a možná i do dalších prohlížečů, ale to už je dost spekulace).

Scénář 1: Třeba tak, že v prohlížeči vyberu "Otevřít bezpečně"?

Scénář 2: Pokud jsem na zabezpečeném webu, má prohlížeč hlídat bezpečnost. Tedy přibližně stejně, jako dnes (akorát by prohlížeč místo přidávání dalších a dalších potvrzovacích oken uživatele informoval, v čem je problém).

Scénář 3: Pokud jsem na zabezpečeném webu, má prohlížeč hlídat bezpečnost. Takže by varoval před nezabezpečeným spojením.

Jak ale prohlížeč zjistí, že jeho bezpečnost mě vůbec nezajímá?
Například tak, že žádným způsobem nedostal ani od uživatele ani od autora webu pokyn, že by se měl bezpečností zabývat.

Myslím, že IdenTrust není zrovna málo akceptovaná certifikační autorita.
Akorát že má na kořenovém certifikátu nastavený počet mezilehlých autorit na 1. To máme kořenovou autoritu LE. Pod ní bude certifikát podřízené autority LE (mají to tak v návrhu certifikační politiky), čímž je vyčerpána kořenovým certifikátem IdenTrustu povolená délka certifikační cesty. Takže na koncové certifikáty už jaksi nezbývá místo. Takže zbývá druhá možnost:

Jako bonus se to nejspíš rozšíří do Firefoxu jako kořenová CA
Tedy ne jako bonus, ale jako základ, protože přes IdenTrust to ověřit nepůjde (pokud IdenTrust nevydá kvůli LE nový certifikát s prodlouženou certifikační cestou). Ale to máme pořád ten jeden jediný prohlížeč. Spekulace, že se certifikát dostane i do jiných prohlížečů, je opravdu jen spekulace - protože kvůli způsobu vydávání budou mít spoustu falešných certifikátů, neočekávám velkou ochotu zařazovat jejich certifikát na seznam důvěryhodných autorit.

„Otevřít bezpečně“ — to s uživatelskou přívětivostí nemá nic společného a IMHO je to nejlepší způsob, jak HTTPS dostat pryč.

„Pokud jsem na zabezpečeném webu, má prohlížeč hlídat bezpečnost.“ — Takže pokud ten web bude odkazovat mimo (třeba na nějakou úplně nesouvisející stránku) na insecure HTTPS, tak by už měl prohlížeč varovat?

„Pod ní bude certifikát podřízené autority LE (mají to tak v návrhu certifikační politiky), čímž je vyčerpána kořenovým certifikátem IdenTrustu povolená délka certifikační cesty.“ — Zajímal by mě zdroj. IMHO pro intermediate tady není moc důvodů, pokud budou vydávat jeden typ certifikátu. A pokud ne, možná si nechají podepsat rovnou tu intermediate, jinak by to nemělo moc smysl…

„Otevřít bezpečně“ — to s uživatelskou přívětivostí nemá nic společného
Vzhledem k tomu, že byste to používal jenom vy při otvírání tajných odkazů z nových a nových webů, tak to nijak nevadí.

Takže pokud ten web bude odkazovat mimo (třeba na nějakou úplně nesouvisející stránku) na insecure HTTPS, tak by už měl prohlížeč varovat?
Ne.

"mají to tak v návrhu certifikační politiky" - zdrojem je návrh certifikační politiky LE.

co když takový pokyn dostal od autora odkazu?
Takový pokyn má ignorovat, autor odkazu do toho nemá co mluvit. Ostatně, https jako samostatný protokol už má své dny sečtené.

Pokud by prohlížeč neměl varovat při přechodu na úplně nesouvisející stránku, ale ne při přechodu na související stránku, jak by pak mezi nimi rozlišil?

K Let’s Encrypt: díky za info, uvidíme, jak to nakonec vyřeší.

„Takový pokyn má ignorovat, autor odkazu do toho nemá co mluvit.“ — Cool, takže budu Lojzovi posílat link na https://documents.example.com/FciXdHSkQFYXPNP1rcUmww a k tomu instrukce, jak má kliknout pravým tlačítkem a zvolit „Otevřít bezpečně“. Pak zjistím, že Lojza má jiný prohlížeč, který to má jinak, třeba na mobilu. Nebo to dostane do nějaké IM aplikace, která to nebude umět prohlížeči předat.

Pokud by prohlížeč neměl varovat při přechodu na úplně nesouvisející stránku, ale ne při přechodu na související stránku, jak by pak mezi nimi rozlišil?
Stejně jako dnes, podle domény nebo třeba podle certifikátu, když je na HTTPS.

OK, takže pokud budu na https://my.vendor/ a tam bude link třeba na https://downloads.my.vendor/drivers.deb, tak se u downloads.my.vendor nemá kontrolovat certifikát?

Pokud budu na jednom webu, který bude odkazovat někam ven, tak vždy mám používat volbu „Otevřít bezpečně“, aby se mi neignorovaly certifikáty?

Tam jsem trochu směřoval.

Nebo třeba https://www.writely.com/ (ponechme stranou, že dnes již nemají platný certifikát) bude přesměrovávat na https://drive.google.com/ .

Dnes uživatel nemá žádným způsobem zaručeno, že když klikne na odkaz na zabezpečené stránce, dostane se opět na zabezpečenou stránku. Dnes by uživatel vlastně správně měl neustále kontrolovat adresní řádek, že je stále ještě na zabezpečeném webu. Samozřejmě by bylo lepší, kdyby uživatel mohl příslušnou záložku uzamknout v zabezpečeném režimu a pak by to za něj kontroloval prohlížeč. Vedle anonymního režimu by prohlížeč mohl mít i bezpečný režim. S tím, že třeba weby uložené v záložkách s https a weby s HSTS by prohlížeč do bezpečného režimu přepínaly automaticky.

Prohlížeč to nezaručuje, ale autor webu to zaručit může. (Aspoň pokud si to okno/panel otevřel sám.*) Bude-li web nějak rozumně navržen, nebude to tedy až takový problém.

Naoroti tomu u každého odkazu klikat pravým tlačítkem a volit „Otevřít bezpečně“ už je o poznání horší.

*) http://lcamtuf.coredump.cx/switch/

Jak ale zjistíte, že to autor webu zaručuje? Pokud to nedokážete zjistit, je taková záruka na nic a musí si to ohlídat sám uživatel. Taky by mne zajímal nějaký web, kde tohle je opravdu zaručeno. Banky z internetového bankovnictví běžně odkazují na nápovědu, dokumenty nebo stránky banky nezabezpečeně. Google má ve vyhledávání, v GMailu, na Disku nebo G+ odkazy od uživatelů, které nemá pod kontrolou. Mohl byste dát odkaz na nějaký web, který opravdu ručí za to, že všechny odkazy z něj vedoucí jsou bezpečné?

„Jak ale zjistíte, že to autor webu zaručuje?“ — Těžko. Ještě hůř se bude zjišťovat, jak mají zabezpečenou databázi apod. Na druhou stranu, pokud už se tomu autor webu věnoval, mělo by být pro uživatele co nejpřímočařejší používat web bezpečně.

„Banky z internetového bankovnictví běžně odkazují na nápovědu, dokumenty nebo stránky banky nezabezpečeně.“
Což ale neznamená, že je to dobře. A ne všechny banky to takto mají. Například AirBank to zřejmě nedělá, celý web jede na HTTPS a má HSTS. Těm už jen chybí zapsání do HSTS preload listu. U Fio o HSTS prý uvažují, tak snad to bude brzy.

„Google má ve vyhledávání, v GMailu, na Disku nebo G+ odkazy od uživatelů, které nemá pod kontrolou.“

Je docela rozdíl mezi následujícími scénáři:
a) kliknu na tlačítko přihlásit
b) kliknu na odkaz evidentně v rámci aplikace, který po mě bude chtít znovu zadat heslo
c) kliknu na odkaz evidentně v rámci aplikace, který ale bude obsahovat nějaké tajemství
d) kliknu na odkaz evidentně mimo aplikaci (v mailu, v IM, v Google Drive, v Google Search)

V případech a) a b) by teoreticky mohl uživatel na přihlašovací stránce znovu zkontrolovat, kde se nachází, je ale lepší, když to není nezbytné, protože si nedělám iluzi, že to mnoho lidí udělá. Zvlášť v případě b) (narážím na Aukro, kde to opravdu není dobře udělané) se může stát, že to po uživateli bude chtít heslo znovu často, uživatel ztratí pozornost a nezkontroluje adresu.

V případě c) už kontrola, zda jsem na správném webu, nepomůže – problém je už únik samotné adresy.

V případě d) to ale evidentně není zodpovědnost aplikace samotné. To je jako byste dostal výhružný dopis, otevřel si jej v GMailu a za ten dopis žaloval Google…

Mimochodem, kontrolovat, zda jsem na správné adrese, je trošku problematické. Představte si, že jste se v ~2005 zaregistroval na https://writely.com. Někdy v ~2006 si jdete upravit svůj dokument a jste přesměrován na https://docs.google.com/ . Co se stalo?
a) Google koupil Writely, od teď je Writely pod ním.
b) Někdo narušil spojení a přesměroval jej na https://docs.google.com.
Ta druhá varianta by s dnešním bezpečnostním modelem, pokud je web writely.com správně udělaný, neměla nastat. S tím, co navrhujete, by nastat mohla. Jak byste zjistil, co se vlastně stalo?

Pokud má prohlížeč zajišťovat bezpečnost tajných odkazů, musí informaci o nutném zabezpečení nějak spolehlivě získat, a to dřív, než ten odkaz navštíví. Takže jedině z DNS (protože ten odkaz klidně může uživatel odněkud opsat, takže prohlížeč nic jiného než odkaz nemá). A jsme zpátky u DANE.

Nebo tím, že je na začátku odkazu uvedeno „https://“.

(Jinak nic proti DANE jako takovému, jen to není nutná podmínka…)

Prohlížeč často neví, co je „na začátku“, protože uživatel zadává adresu bez protokolu. Dále – jak píšu celou dobu – neplatí, že odkaz s https znamená požadavek na zabezpečené spojení. A za třetí, standard HTTP/2.0 je hotový a čeká na publikaci jako RFC – a tento standard napravuje chybu, že šifrovaná verze existovala jako samostatný protokol, takže nyní může být i komunikace protokolem http zabezpečená.

„Prohlížeč často neví, co je „na začátku“, protože uživatel zadává adresu bez protokolu.“

To je sice pravda, ale o tomto IMHO spor není. Myslím, že jsme se shodli, že:
1. Pokud zadám adresu bez „https://“, pak prohlížeč má zkusit HTTP, ledaže by měl odněkud (HSTS, HSTS preload list, případně DANE) jinou informaci.
2. Pokud zadám adresu s „https://“, pak prohlížeč má rovnou zkusit HTTPS, protože jsem to po něm chtěl.

Psal jsem o situaci, kdy člověk klikne na odkaz. Potom prohlížeč ví, jaký se má použít protokol, protože je to (v případě relativní cesty implicitně) uvedeno v tom odkazu.

„neplatí, že odkaz s https znamená požadavek na zabezpečené spojení“ — A co jiného by to znamenalo?

„[HTTP/2] napravuje chybu, že šifrovaná verze existovala jako samostatný protokol, takže nyní může být i komunikace protokolem http zabezpečená.“
Cool, co to ale pro tuto diskuzi znamená?

Když je v odkazu protokol uveden, nevypovídá to skoro nic o tom, jaký protokol chce uživatel použít. On se tam ten protokol v drtivé většině případů dostane tak, že ho někdo zkopíruje z adresního řádku, takže tam je zrovna ten, který náhodou uživatel použil. Představte si třeba odkazy tady v diskusích. Já z nich vždy protokol i hostname odstraňuju, aby uživatel zůstal na tom serveru a protokolu, kde je. Myslím, že to tak moc lidí nedělá a že většinou zkopírují celý odkaz. Takže když tady budu procházet diskuse a klikat na odkazy, budu se náhodně přepínat mezi http a https. Vy v tom budete hledat záměr a zjišťovat, proč jsem na tuhle diskusi šel přes https a na tamtu přes http, já v tom nic složitého nehledám, protože vím, že je to prostě náhoda. Respektive původně je to chyba v návrhu, protože vlastnost nezabezpečené/za­bezpečené spojení jsou atributy v rámci protokolu.

Pro tuto diskusi to znamená, že rozlišování http/https v URL je omyl, který bude s novou verzí opraven. Takže nemá smysl z náhodné přítomnosti či nepřítomnosti protokolu https v URL dělat nějaké závěry.

Pokud je v odkazu uveden protokol HTTPS, dá se očekávat, že ten, kdo tam ten odkaz poslal, neměl problémy se na ten web dostat. Co byste downgradem na HTTP potom získal?

Ano, někdy je protokol, kam vede odkaz, dílem náhody, ale rozhodně ne vždy. Já například do adresy důsledně přidávám „https://“, pokud to jde, tzn. pokud koncový web HTTPS nějak rozumně podporuje.

Ono by bylo fajn mít HTTPS všude, kde to server rozumně podporuje, akorát není obecný spolehlivý způsob, jak to zjistit, tak prohlížeče většinou defaultně zkoušení HTTP, na kterém je případně přesměrování. Pokud už odkaz obsahuje informaci, že to koncový server podporuje, proč toho nevyužít?

„Pro tuto diskusi to znamená, že rozlišování http/https v URL je omyl, který bude s novou verzí opraven.“ — Myslím, že HTTP/2 nabízí něco poněkud jiného:
1. Zabývá se šifrováním již v návrhu samotného protokolu a tomu uzpůsobuje například kompresi hlaviček, aby se předešlo útokům typu CRIME/BREACH.
2. Na „http://“ bude zřejmě možné provozovat TLS skrze opportunistic encryption. Nejspíš to bude ale akorát obrana proti pasivnímu odposlechu, nic víc. Těžko to zabrání MITM.

dá se očekávat, že ten, kdo tam ten odkaz poslal, neměl problémy se na ten web dostat
Nevidím jediný důvod, proč by něco takového mělo platit. Navíc to, že se na web bez problémů dostal jeden člověk, neříká, že se tam bez problémů dostane někdo jiný.

Pokud už odkaz obsahuje informaci, že to koncový server podporuje, proč toho nevyužít?
Nikdy jsem netvrdil, že se toho využít nemá. Celou dobu tvrdím jenom to, že nutit uživateli zabývat se certifikátem, když žádnou bezpečnost nechce, je chyba a je to školení uživatelů k tomu, že se mají chovat na webu nebezpečně.

HTTP/2 počítá s tím, že je to jeden protokol na jednom defaultním portu, který uvnitř může být šifrován - tak jako jiné protokoly jako SMTP, IMAP nebo DNS (ten není šifrován, ale jen podepsán). Původně se uvažovalo, že v HTTP/2 bude šifrování povinné, nakonec se standard zmírnil - ale alespoň některé prohlížeče nebudou nešifrovanou variantu HTTP/2 podporovat. Šifrování HTTP/2 bude normálně používat certifikáty, tak jako HTTPS, takže to MITM bude bránit úplně stejně.

„Navíc to, že se na web bez problémů dostal jeden člověk, neříká, že se tam bez problémů dostane někdo jiný.“
Pravděpodobně to nebude self-signed.

Zadruhé, ještě jsem se nedozvěděl, jak má prohlížeč rozlišit mezi pohybem v rámci webu a pohybem mezi weby. U pohybu v rámci webu se lze důvodně domnívat, že pokud uživatel jednou zadal adresu s „https://“, tak na ní bude chtít i zůstat.

„HTTP/2 počítá s tím, že je to jeden protokol na jednom defaultním portu, který uvnitř může být šifrován“
To, jestli se bude používat na šifrované spojení stejný protokol jako na nešifrované, už je ten technický detail, který nemá skoro nic společného s reálným zabezpečením. (Maximálně tu bude o něco málo lepší průchodnost přes firewally.)

„Šifrování HTTP/2 bude normálně používat certifikáty, tak jako HTTPS, takže to MITM bude bránit úplně stejně.“
Na stole byla i varianta s oportunistickým šifrováním, která z principu bránit MITMu nemůže. A řekl bych, že korektně šifrovaná a autentizovaná varianta HTTP/2 bude mít stále v adrese „https://“, takže pro tuto diskuzi to bude irelevantní.

To, že se na web dostal jeden uživatel bez problémů, nevypovídá vůbec nic o tom, že tam není self-signed certifikát. Navíc je úplně jedno, zda jde o self-signed certifikát nebo certifikát neznámé autority, prohlížeč mezi tím nerozlišuje a nemůže rozlišovat.

Pohyb v rámci webu a mezi weby se rozliší velice snadno podle doménového jména. A zrovna tohle mají prohlížeče docela propracované, protože na tom závisí značná část zabezpečení.

S tím portem jsem to napsal špatně, defaultní porty pro nešifrované a šifrované spojení budou stále různé.

Prohlížeče chtějí u HTTP/2 podporovat jenom šifrovanou variantu. Většina odkazů na internetu vede na http. Když si dáte tyhle dvě informace dohromady, plynou z toho jenom dva možné závěry: buď prohlížeče budou navěky podporovat HTTP/1.1 a budou to muset podporovat i servery, přestože by všichni rádi už dávno přešli na šifrované HTTP/2. Nebo prohlížeče využijí možnost ignorovat uvedený protokol, pokud mají informaci, že cílový server podporuje HTTP/2. Ideální bude, když budou všechny potřebné informace v DNS - tedy překlad jména na adresu a port, verze podporovaného protokolu HTTP a certifikát.

„To, že se na web dostal jeden uživatel bez problémů, nevypovídá vůbec nic o tom, že tam není self-signed certifikát.“
Jak se dostanu bez problémů na web, který má self-signed certifikát?

„Navíc je úplně jedno, zda jde o self-signed certifikát nebo certifikát neznámé autority, prohlížeč mezi tím nerozlišuje a nemůže rozlišovat.“
Pokud jde o certifikát neznámé autority, která je podporována v jiném prohlížeči, pak jsme se od problému odhadem tak 1 ‰ webů dostali k problému tak 0,1 ‰ webů.

„Pohyb v rámci webu a mezi weby se rozliší velice snadno podle doménového jména. A zrovna tohle mají prohlížeče docela propracované, protože na tom závisí značná část zabezpečení.“
Takže když mě https://maps.google.com přesměruje na https://www.google.com/maps nebo dokonce https://www.google.com/maps přesměruje na https://www.google.cz/maps, tak už to není pohyb v rámci jednoho webu a má se ignorovat HTTPS? Analogicky writely.com/doc­s.google.com/dri­ve.google.com, nebudu to opakovat.

„Nebo prohlížeče využijí možnost ignorovat uvedený protokol, pokud mají informaci, že cílový server podporuje HTTP/2.“
Proč by to dělaly a hlavně pro bezpečnost podstatná otázka: Jak by to zjistily?

Na web, který má certifikát autority, která je předinstalována v jednom prohlížeči a v jiném ne, nebo který má self-signed certifikát, se bez problémů dostanete tak, že máte v prohlížeči nainstalován certifikát té autority, příslušný self-signed certifikát, nebo používáte prohlížeč, který netrénuje uživatele v automatickém odklikávání všech hlášek.

tak už to není pohyb v rámci jednoho webu
Nastudujte si, co je to same-origin policy. V oblasti bezpečnosti webových prohlížečů je to dost podstatný prvek.

Proč by to dělaly
Aby mohly použít protokol HTTP/2.

Jak by to zjistily?
Například tak, jak jsem napsal ve svém komentáři.

„máte v prohlížeči nainstalován certifikát té autority, příslušný self-signed certifikát, nebo používáte prohlížeč, který netrénuje uživatele v automatickém odklikávání všech hlášek.“
IMHO to je dost vzácná situace, jak jsem psal.

Pokud máte web a chcete uživatelům znemožnit odklikávání hlášek o chybném certifikátu, doporučuji použít HSTS a ideálně se ještě nechat zapsat do HSTS preload listu. Já to už u jednoho webu takto udělal. Zkuste si třeba ve Firefoxu nebo Chrome jít na http://badcert.typingrevolution.com/ .

„Nastudujte si, co je to same-origin policy.“
O SOP bych si dovolil něco vědět. Poukazoval jsem ale na to, že pojem „stejný web“ může mít jiný význam v SOP a jiný význam v chápání uživatele.

„Aby mohly použít protokol HTTP/2.“
Je ignorace této informace snad podmínka pro HTTP/2? Zdroj?

„Například tak, jak jsem napsal ve svém komentáři.“
Pokud myslíte z DNS, pak pokud budeme mít DNSSEC, pak můžeme všude nasadit HTTPS a čisté HTTP může být deprecated. Nepotřebovali bychom vůbec CA a prohlížeč by mohl vědět najisto, zda na drátě sedí útočník. Ale dokud CA potřebujeme, mají hlášky o neověřeném certifikátu svůj význam. Zatím jeho úlohu částečně přebírá zmíněné HSTS a HSTS preload list. (Umí minimálně Firefox a Chrome, má to umět i nové IE.)

„Například tak, že žádným způsobem nedostal ani od uživatele ani od autora webu pokyn, že by se měl bezpečností zabývat.“ — a co když takový pokyn dostal od autora odkazu?