Root přešel na HTTPS

Souhlasím, ale to je bohužel vše, co můžu dělat.

Samozřejmě, tohle platí. Stejně ale nemá smysl spěchat. Já mám ale třeba Roota přidaného v Chrome ručně do HSTS preload seznamů. Takže u mě je HTTPS povinné. Viz chrome://net-internals/#hsts

Když už ale dokážu přijímat HTTPS spojení s důvěryhodným certifikátem, většinou není důvod pro cestu zpět. Ten by byl v případě, kdy se ukáže, že HTTPS z nějakého důvodu nelze použít.

Máme v prohlížeči uložené HSTS (jinak nemáme problém). Prohlížeč se tedy již někdy se serverem spojil bez odkliknutí nedůvěryhodného certifikátu. Předpokládám, že nemáme HPKP a nepoužíváme preload ani includeSubdomains (to je už vyšší level). Dá se celkem rozumně předpokládat, že i teď budeme mít nějaký platný certifikát (přinejhorším od jiné autority, kdyby nám LE odmítla vydat nový certifikát – riziko nutnosti použití placeného certifikátu zde pro Root asi nebude významné) a že prohlížeč zvládne udělat zabezpečené spojení přes HTTPS.

Tyto předpoklady nejsou dostatečně silné na to, abych mohl vyloučit nutnost návratu na HTTP. Typicky se může objevit nějaký mixed content, nejspíš něco 3rd party, s čím si neporadím. To mi ale nebrání vypnout HSTS a přejít zpět na HTTP.

Lze samozřejmě polemizovat s mými predpoklady. Myslím ale, že jsou celkem rozumné:

* Předpokládám, že admin je rozumný a na testovací provoz nebude zapínat silnější volby jako includeSubdomains.
* U části předpokladů je jejich zpochybnění zpochybněním vhodnosti HSTS pro daný web – pak ale nemá smysl uvažovat o HSTS ani do budoucna.

Máme v prohlížeči uložené HSTS (jinak nemáme problém). Prohlížeč se tedy již někdy se serverem spojil bez odkliknutí nedůvěryhodného certifikátu.
Nikoli, prohlížeč se se serverem spojil, možná po odkliknutí nedůvěryhodného certifikátu.

prohlížeč zvládne udělat zabezpečené spojení přes HTTPS
Tohle také platit nemusí. Prohlížeč se může připojovat z různých sítí a to, že se dokázal připojit z jedné, neznamená, že to půjde z jiné.

Předpokládám, že admin je rozumný a na testovací provoz nebude zapínat silnější volby jako includeSubdomains.
To je takový předpoklad „přepdokládám, že bude všechno fungovat správně“. Ono se právě až během toho testovacího provozu může ukázat, že je nějaká volba zatím příliš silná.

Tyto předpoklady nejsou dostatečně silné na to, abych mohl vyloučit nutnost návratu na HTTP. Typicky se může objevit nějaký mixed content, nejspíš něco 3rd party, s čím si neporadím. To mi ale nebrání vypnout HSTS a přejít zpět na HTTP.
To můžete předpokládat asi jen u veřejných webů. Jakmile půjde o nějaký intranet, extranet nebo webovou aplikaci, můžete se snadno dostat do situace, že se budete potřebovat vrátit k HTTP, protože se ukáže, že HTTPS spojení vůbec nelze navázat. Může to být problém specifické konfigurace sítě, problém přístupové aplikace, můžete mít nějaký captive portál na WiFi… Ty problémy se mohou objevit i později, ale obvykle se na ně přijde při spuštění HTTPS, kdy se jednotliví uživatelé postupně začnou připojovat.

„prohlížeč se se serverem spojil, možná po odkliknutí nedůvěryhodného certifikátu.“

Potom ale prohlížeč HSTS ignoroval a nemáme problém.

„Prohlížeč se může připojovat z různých sítí a to, že se dokázal připojit z jedné, neznamená, že to půjde z jiné.“

Ok, některá síť může například blokovat HTTPS nebo nějaký port. A co? Bude kvůli tomu Root přecházet zpět na HTTP? Asi ne.

„Ono se právě až během toho testovacího provozu může ukázat, že je nějaká volba zatím příliš silná.“

Předpokládám, že se budou používat pouze volby, které lze rozumně revertnout. Na druhou stranu chápu, že někdo, kdo s tím nemá moc zkušeností (no offense), se do toho navrhne po hlavě.

„To můžete předpokládat asi jen u veřejných webů.“

I kdyby, v tomto kontextu to není problém.

Potom ale prohlížeč HSTS ignoroval a nemáme problém.
Který prohlížeč zpracovává HSTS v závislosti na tom, jak uživatel zacházel s certifikátem při přístupu na web? A ten prohlížeč ignoruje HSTS když si certifikát přidám mezi důvěryhodné při přístupu přes chybovou hlášku prohlížeče, ale když si ten samý certifikát přidám předtím ručně, tak HSTS neignoruje?

Ok, některá síť může například blokovat HTTPS nebo nějaký port. A co? Bude kvůli tomu Root přecházet zpět na HTTP? Asi ne.
Psal jsem, že u veřejných webů to asi není pravděpodobné. Nicméně HTTPS se nenasazuje jen na veřejných webech, a vaše obecné tvrzení, že z HSTS se vždy lze vrátit, vyvrací i kterýkoli intranet nebo extranet nebo aplikace. A ono to může být problém i u veřejných webů, protože když použijete HSTS a následně zjistíte, že HTTPS musíte z nějakého důvodu dočasně zrušit (třeba protože Opera Mini nedůvěřuje certifikátu CA a pro vás je důležitá), dostanete se do situace, kdy u některých klientů máte povinné HTTPS a u některých ho máte zase zakázané.

Předpokládám, že se budou používat pouze volby, které lze rozumně revertnout.
Přičemž jste mezi volby, které lze rozumně revertnout, zařadil HSTS, ačkoli existuje mnoho případů, kdy to rozumně revertnout nejde.

HSTS při výjimce:

* IMHO nutnost ignorance HSTS v případě vyplývá z https://tools.ietf.org/html/rfc6797#page-33 kapitoly 14.3.
* Vyplývá to i ze zdravého rozumu. To bych povolil webu výjimku, a ten by následně zakázal jakékoli výjimky.
* Minimálně u Firefoxu to mám i oterstováno.
* Schválit výjimku je trochu speciální případ – nejde jen o přidání důvěry, ale i o ignoraci hostname a ignoraci časové validity a případně dalších omezení.

Intranet: Ještě jste nevysvětlil, co je na něm tolik speciálního, že je u něm situace okolo HSTS jiná.

Opera Mini: A kde je problém? Přidám redirect na HTTP s HSTS max-age=0. Opera Mini o HSTS nikdy nevěděla, tam to bude OK. (Ve stejné míře jako s HTTPS bez HSTS.) Prohlížeče, které vědí o HSTS, zase těžko najdou důvod se nespojit, protože certifikát CA evidentně znají.

To bych povolil webu výjimku, a ten by následně zakázal jakékoli výjimky.
Nerozumím, co tímhle myslíte.

Schválit výjimku je trochu speciální případ
Což je trochu problém, protože já tu výjimku můžu zrovna tak „schválit“ tak, že vezmu certifikát serveru a nahraju ho mezi důvěryhodné certifikáty. Nebo vezmu certifikát autority, ověřím, že je důvěryhodná, a nainstaluju certifikát autority. Ale beru, že v některých případech prostě prohlížeče HSTS ignorují – s certifikáty pracují divně, tak proč nepřidat další divnost.

Intranet: Ještě jste nevysvětlil, co je na něm tolik speciálního, že je u něm situace okolo HSTS jiná.
Třeba captive portál pro přístup na wifi. Všichni přijdou třeba do práce, do školy nebo do kavárny, při prvním použití HTTP jsou přesměrováni (únosem spojení) na captive portál na intranetu, kde se přihlásí na wifi. Během dne administrátor zapne pro intranet HTTPS s HSTS, každému z připojených, který se na intranet podívá, se povinnost HTTPS zaznamená. A když přijdou druhý den, nikdo z nich už se k wifi nepřipojí, protože při přesměrování na captive portál je prohlížeč z HTTP automaticky přehodí na HTTPS, které je ale bez přihlášení nedostupné.

Opera Mini: A kde je problém?
Problém je, že jste si rozdělil uživatele na ty, kteří musí mít HTTPS, a na ty, kteří ho mít nesmí. Jakékoli takovéhle pravidlo se velmi těžko dodržuje, vždycky někde proklouzne nějaká chybička a na stránku pro HTTP se dostane něco s HTTPS nebo opačně.

„To bych povolil webu výjimku, a ten by následně zakázal jakékoli výjimky.“

HSTS mj. zakazuje uživateli odkliknout výjimku pro nedůvěryhodný certifikát. Kdyby tedy prohlížeč po odkliknutí výjimky neignoroval HSTS, prohlížeč by ihned zakázal odklikávání výjimek.

Co se týče jiných možností schválení výjimky – čistě teoreticky ano, ale:

1. Prvně bychom museli mít web s problematickým certifikátem. (Archaické prohlížeče jsou že hry, ty stejně nebudou podporovat HSTS apod.) Už toto je samo o sobě dost malá pravděpodobnost.
2. Kdo to takto udělá, když to jde jednodušeji?
3. Z těch, kdo si dobrovolně zvolí komplikovanější cestu, kdo si s tím následně neporadí?

Captive portal: To není specifikum intranetu.

Opera Mini: Přiznávám takový tichý předpoklad, že chceme buď jen HTTP, nebo jen HTTPS. To druhé má přesměrovávat. A teď v tom nevidím problém. Ty uživatele, kterým jsem řekl, že HTTPS mít musejí, při nejbližší příležitosti informuju o změně (HSTS max-age=0) a přesměruju je na HTTP. Nic jako dvě verze webu (HTTP a HTTPS) v plánu nemám.

Intranet byl uváděn jenom jako příklad. Pokud budu mít samostatný captive portál založený na únosu HTTP spojení, nebudu tam zaváděj HSTS, to bych byl blázen. Další možnost je, že bude intranet nakonfigurován pro přístup přes HTTPS z internetu, ale pro přístup z vnitřní sítě se bude předpokládat HTTP. Podstatné je to, že intranety bývají i ze síťového hlediska nakonfigurované velmi kreativně, takže nemusí být až taková vzácnost, že se podaří jednou bez problémů navázat HTTPS spojení (a může se tedy vnutit HSTS), ale později se z téhož počítače přes HTTPS nespojíte. Pokud se na to přijde včas, opraví se to, ale pokud se na to přijde až po nasazení HSTS, je to problém.

Captive portál je celkem nezávislý na tom, jestli ten web je v intranetu, nebo ne. Je to samozřejmě u webů na HTTPS problém, a to z velké míry i bez HSTS. Není to ale problém těch webů, ale návrhový nedostatek captive portálů. Ani Twitter, Facebook či Google nevycházejí v tomto směru Captive portálům vstříc. Některé OS (minimálně Android) se to snaží řešit detekcí a uživatelsky přívětivým počinem mimo běžný webový prohlížeč. Toto bude asi celkem way-to-go.

Co se týče kreativní síťové konfigurace, OK. Už jsem nějakou kreativní konfiguraci viděl, byť způsobuje poněkud jiné problémy.

Nicméně pointa mého původního příspěvku zůstává – mixed content (zdaleka nejpravděpodobnější problém) lze s HSTS řešit jeho vypnutím a nemožnost navázání HTTPS spojení u klienta s HSTS je u webu jako Root.cz hodně hodně edge case. I tady by mimochodem šlo dávat zpočátku HSTS hlavičky třeba na 24h.

A nebo prostě HSTS hlavičku nedávat a přidat jí, až když je ověřené, že všechno funguje. Když se to bez ní obešlo takových let, těch pár dní nebo týdnů už nehraje roli. Důležití je, aby se na HTTPS vůbec přešlo, není nutné v jedné vteřině skočit z nezabezpečeného spojení na maximálně bezpečené.

Když umožníte HTTP přístup k „běžným informačním webům“, umožníte ho všude. K výraznému zvýšení bezpečnosti bezpečných webů (které i podle vás vyžadují HTTPS) dojde tehdy, až prohlížeče nebudou HTTP podporovat vůbec a nebo jen se značným odporem. K tomu se dostaneme jedině tak, že se HTTPS bude postupně nasazovat i na weby, kde podle váš HTTPS není nutné.

A jinak když vám je jedno, jaký obsah z toho informačního webu dostanete, není mi moc jasné, proč na ten web vlastně chodíte.

Pokud si myslíte, že moje komentáře jsou to nejhodnotnější na tomhle webu… Mně by třeba víc než pozměňování komentář vadilo pozměňování článků. Třeba když si v Softwarové sklizni přečtu o zajímavém softwaru, rád bych u něj měl odkaz na stránku, odkud ho stáhl autor – odkaz na nějaké úložiště softwaru s přibaleným ad-ware (v lepším případě) mne moc nepotěší.

Hlavně jste se ale nějak nevypořádal s tou vážnější námitkou, že podpora HTTP v prohlížečích ohrožuje ty stránky, kam chcete mít bezpečný přístup – třeba elektronické bankovnictví nebo e-mail.

To, že se nepodíváte na web na mikrokontroléru, není žádný argument. Na ten web se nepodíváte ani pomocí automatické pračky nebo s patnáct let starým prohlížečem. Prostě k prohlížení webu, stejně jako k čemukoli jinému, musíte mít odpovídající nástroje. A mikrokontrolér, který nezvládne ani ušifrovat HTTPS, to holt nebude. Úplně stejně byste si mohl stěžovat, že většina dnešních webů vyžaduje hlavičku Host, která dříve byla nepovinná. A že váš mikrokontrolér nemá dost paměti, aby posílal takové novoty. Smůla, množství webů a nedostatek IPv4 adres znamená, že musíte obětovat klienty, kteří nepodporují hlavičku Host. Efektivita HTTP komunikace a menší komplexnost implementace v budoucnu budou znamenat odříznutí klientů nepodporujících HTTP/2 a zabezpečení přístupu do elektronického bankovnictví nebo k e-mailu budou v budoucnu znamenat odříznutí klientů nepodporujících HTTPS. Ostatně už dávno jsou odřezáváni klienti, kteří podporují jen slabé šifry nebo certifikáty s krátkými otisky. Holt když si má většina lidí vybrat mez bezpečným přístupem k bance nebo tím, zda se vy dostanete na web z mikrokontroléru, volí tu banku.

Problém je v tom, že se to tím výrazně komplikuje. Musím hlídat, abych tam neměl mixed content, abych posílal všechno buď šifrovaně nebo nešifrovaně. Zároveň musí uživatel hlídat, jestli při přihlašování není náhodou tlačen do HTTP. Když se to prostě zašifruje celé, je problém definitivně vyřešen. Prostě šifrujeme.

Zřídím - li bezpečný a kritický web, bude přístupný výhradně přes https.
Když chcete řešit bezpečnost, nepopisujte, co bude dělat oprávněný provozovatel, ale co bude dělat útočník.

to by měl uživatel poznat
A pokud chcete řešit bezpečnost, nepředstavujte si, že máte neomylné uživatele, kteří budou do puntíku plnit cokoli, co jim bezpečák řekne. Ne, pokud chcete něco opravdu bezpečné, nemůžete to stavět na tom, že to uživatel může udělat bezpečné, pokud bude chtít a bude se snažit. Pokud chcete, aby uživatelé nepoužívali krátká hesla, nemůžete prohlásit, že by uživatelé měli používat dlouhá hesla, ale musíte při vytváření hesla délku kontrolovat a krátká hesla odmítnout. A pokud chcete, aby používali šifrovaný přístup k bance, nesmíte jim vůbec umožnit nešifrovaný přístup.

Já jsem také rád, že se používá evropský (nebo euroamerický přístup) – demokratický, který vyhoví maximálnímu počtu lidí, a zároveň počítá s tím, jak se lidé chovají. Není to jen nějaké byrokratické lejstro, které prohlásí, že od teď se všichni chováme bezpečně, tak to tak papírově bude, ale v praxi by to bylo úplně jinak.