Názory k článku Bezpečnější šifrování HTTPS s hlavičkami HSTS a HPKP

Mám nasazeno HPKP s LE a není to žádný problém - vpodstatě jen použijete stejné csr pro další žádost o cert. Nicméně s HPKP bych byl i tak opatrný, podle mě to není to co by měl mít každý a všude. Ostatně stačí si projet, které největší weby pinning používají.

Mám z toho podobné dojmy: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead

Z logiky věcí by HSTS mělo být jen přechodné opatření a neměla by být daleko doba, kdy budou prohlížeče zkoušet vždy nejdříve HTTPS spojení — a v případě nedostupnosti šifrované vrstvy zobrazovat méně či více důrazné varování a/nebo omezovat některé funkce webu (jako odesílání formulářů s heslem — což, vzpomeňme si, bylo ve výchozím nastavení Internet Exploreru už více než před 15 lety)

To by neslo ... to by totiz bylo moc jednoduchy reseni ... prehodit default na https je totiz jeden radek v kodu (mozna ani to ne).

Nemluve o tom, ze na to samo davno existujou pluginy.

Prehodit default nestaci. Nebrani to odkazom na http verziu.

A v čem je rozdíl? S HSTS prohlížeč stejně odkaz na HTTP nerespektuje a připojí se přímo na HTTPS. Bavím se o tom, že není daleko doba, kdy tato politika nebude opt-in, ale výchozí stav.

Jenže HSTS je no opt. Prostě to pojede jen a pouze na HTTPS.

Co kdyz server vrati HSTS hlavicku v odpovedi na na nejakou podstranku (tedy dotaz na URL s netrivialni path casti), je takova hlavicka platna pro celou domenu nebo je neplatna? Muze uzivatelsky cgi skript takto aktivovat HSTS pro celou domenu bez vedomi spravce webserveru?

Diky za pekny clanek.

JJ, po delší době článek, který jsem si opravdu s chutí přečetl a dozvěděl se něco zajímavého. Víc takových !!!

HSTS je dobrý sluha, ale špatný pán.

HSTS je docela zlo, pokud to nejde vypnout/obejít potvrzením v prohlížeči. Zaměstnavatel má vlastní certifikační autoritu a tou pak podepisuje certifikáty pro všechny svoje stránky. Zároveň je na stránkách aktivní HSTS. Nejde tedy jen povolit výjimku, ale musíte mít nainstalován certifikát jeho certifikační autority. Takže může hodit klidně certifikát jiné stránky a to nejen v práci, ale třeba při práci z domu musíte mít takto zmršený i svůj vlastní počítač.

Jedna "duveryhodna" CA sem nebo tam ... jak rikam, naprosto chorej a neopravitelnej system.

Seznam security policies lze v chromu tak trochu spravovat (a lze ho i mazat). Netvrdil bych, že to je nemožné :-)
chrome://net-internals/#hsts, "Delete domain security policies"

Ale to použijeme tak maximálně my, při testingu a troubleshootingu HSTS. Nikoliv uživatel.

HPKP mi přijde úplně geniální!

Už chápu, proč existují všechny ty služby "nastavíme vám HTTPS ZDARMA!"

Zákazníci se jen hrnou, existenci nějakých HPKP hlaviček neřeší, všichni se radují z ušetřených stokorun ročně. Až se jich nahromadí významný počet, najednou jim přestane web fungovat.

A dojde jim výzva k uhrazení zajímavé částky, kterou jistě rádi zaplatí, pokud chtějí dál podnikat.

A stejně tak zlý zaměstnanec nemusí být vůbec zlý. Může být hodný a zavádět sám a z vlastního úsilí nejmodernější technologie.

Jen běda, pokud chce zaměstnavatel s takovým zaměstnancem neférově vyběhnout. Zaměstnanec bude mít slušnou páku na vymožení svých práv :)

Jeste bych k HPKP dodal, ze muze nastat problem, pokud klice k certifikatum (a tim padem i certifikaty) z nejakeho duvodu menite casto. Dejme tomu, ze jste jako admin pripinoval 2 otisky VK - jeden hlavni (abc) a druhy zalozni (def). V tuto dobu na stranky pristoupil uzivatel Pepa, ktery je navstevuje velmi zridka a automaticky se mu otisky ulozily napr. na rok. Pak doslo ke kompromitaci hlavniho klice (abc), tak jste zacal vydavat zalozni (def) jako hlavni a vytvoril novy zalozni (ghi). Zatim je vse v poradku ale pokud by se toto jeste jednou opakovalo (duvodem muze byt chyba admina, opetovna kompromitace apod.), tak vydavate jako hlavni (ghi) a jako zalozni nejaky novy (jkl). V tuto chvili vase stranky opet navstivi Pepa ale presto, ze neudelal nic spatne, tak nebude duverovat ani jednomu vasemu otisku a na web se po zbyvajici cast roku nedostane.

Resenim je nemenit otisky klicu tak casto a mit vice zaloznich. Pripadne nepinovat koncove certifikaty.

HPKP je nebezpecne i v dalsich pripadech... Pokud utocnik ziska plnou kontrolu nad webovym serverem, muze s nim delat vicemene cokoliv do te doby, nez to administrator zjisti, vse opravi a utocnikovi odepre pristup. S HPKP ale prichazi moznost "skodit" i po ztrate pristupu k serveru obeti...

Uvazujme, ze na cilovem webu nikdy nebylo HPKP zapnuto (stejne je to dnes spise rarita, co bezi jen na par stovkach webu). Utocnik s plnym pristupem mohl HPKP aktivovat a odesilat 2 pinovane otisky - jeden novy a cerstve nasazeny (misto originalniho) a nejaky druhy, ktery nazveme Ransom. Oba si mohl nechat pro danou domenu vygenerovat napr. u Let's Encrypt (nadvladu nad serverem ma, takze neni problem). Nejakou dobu to tak necha, pocka, az se majorite ulozi do prohlizecu tyto 2 otisky a pote ten prvni, aktualne pouzivany, smaze. Pak jedina moznost, jak se uzivatele budou moci na web dostat je, aby server pouzival certifikat s otiskem Ransom, ktery ma utocnik a necha si za nej pekne zaplatit :)

Obavam se, ze je to jen otazka casu, nez se to bude pravidelne dit. Pro nejakou vetsi spolecnost to muze mit katastrofalni ucinky a spis zaplati.

Zajimavy, kdyz sem presne totez psal https://www.root.cz/clanky/ssls-strasi-pred-let-s-encrypt-ale-pouziva-klamne-argumenty/nazory/897802/ tak prej nechapu, jak to funguje ...

Ja bych pridal navod https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html a hlavi4ku Public-Key-Pins-Report-Only report-uri pro otestovani.

díky za článek. Ještě pro zajímavost statistika, kolik webů se zapnutým HPKP ho má zapnuté správně, případně nejčastější chyby - možná by stálo za to doplnit do článku:

https://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html

co delam spatne???

$ curl -I https://cs.wikipedia.org/
curl: (35) error:140770FC:SSL routines:SSL23_GE­T_SERVER_HELLO:un­known protocol