Názory k článku
Chrome postupně odstraní zámeček pro HTTPS v adrese

Chrome pouzivaju masy, treba ich prevychovat

Nojo, převýchova mas, to je historií ověřená praktika (jak na chvíli získat úspěch a pak skončit).

Má to smysl.Ukazuje to, že HTTPS je standard, a jako něco nenormálního to ukazuje HTTPS.

Má to smysl.Ukazuje to, že HTTPS je standard

Standard je něco, co si lidé zvolí nebo k čemu dojdou. Ne, co je jim vnuceno.

panuje v rámci standardizačních skupin (IETF, W3C) všeobecná shoda.

V rámci KVS(b) či KSČ byla všeobecná shoda, že je potřeba likvidovat kulaky. V NSDAP byla všeobecná shoda likvidovat židy a mouřeníny. Všeobecné shody "elitních skupin" jsou vůbec ty nejlepší.

"Ne, co je jim vnuceno."
Ne, naopak ty chceš lidem něco vnocovat.

Ne, já chci zachovat současný stav, než bude nalezeno řešení opravdu lepší.

Smysl to ma, protoze ideogram zamecku neni jednoznacny. Nekteri lide, kdyz vidi zamecek, tak mysli, ze jim je neco odepreno, a snazi se jej za kazdou cenu odemknout.

Odstranění zámečku - to je asi detail, proti kterému se nedá protestovat.
Výslovné označení HTTPS jako za nebezpečné - to už je diskutabilní. Běžný uživatel neumí rozlišit nuanci mezi slovy "nebezpečný" (= aktivní, ohrožující) a "nezabezpečený" (= pasivní, v ohrožení).

Akorát že „not secure“ znamená „nezabezpečený“, nikoli „nebezpečný“.

Akorát že „not secure“ znamená „nezabezpečený“, nikoli „nebezpečný“.

Udělejte si ale průzkum mezi běžným obyvatelstvem, jestli v kontextu dokáží mezi těmito významy rozlišit.
Ještě horší to bude mezi "secure" = bezpečný a "secured" = zabezpečený.

Prohlížeče by měly jen svým uživatelům komunikovat, že je tím ověřena komunikace s doménou XY a nikdo neposlouchá cestou. Žádné další záruky.

Toto má dvě hluboké trhliny, resp. tři.

1. Ověřena komunikace s doménou XY: lidé berou, že doména = firma, osoba či nějaké uskupení. Myslím, že lidi moc nezajímá, že firma "Masokombinát Vepřovice, s. r. o." je držitelem domény "zijme-vege.cz". DV certifikáty, z hlediska ověření s kým komunikuji neříkají ve skutečnosti vůbec nic. Podle mě je to špatně.

2. Díky ACME je možné získat DV certifikát i podloudně, stačí mít přístup k síti blízko cílovému serveru a využít reverzní MITM útok. V tu ránu máte certifikát a můžete dělat, co chcete.

3. Celá slabina systému (řetězce) se dnes přesunula na to, jak dobře je zabezpečený přístup ke správě DNS. Velké firmy to možná mají dobře, ale malé a střední firmy využívají registrátory, kteří umožňují správu DNS přes Web. Na Webu bývá většinou možnost zaslat zapomenuté heslo, což probíhá pomocí SMTP, které je nešifrované (opurtunisticky šifrované). Takže postup hackera: postavím se do cesty mailserveru. Vyžádám recovery hesla k DNS správě přes web. Odchytím poštu. Využiju DNS autorizaci protokolu ACME, abych získal certifikát.

Ve skutečnosti HTTP a HTTPS s DV certifkátem jsou stejně bezpečné. Označovat HTTP za nebezpečnější než HTTPS s DV certifikátem je chybné, nikam nás to neposouvá a jen to zvyšuje náklady.

BFU to možná nerozlišuje, a co jako?

Ehm, jako maximum. Pokud má nějaká technologie sloužit lidem, je potřeba se dívat na ni z pohledu lidí.

Co je "reverzní MITM"?

MITM je obecně vnímáno blíž k poslední míli (= srov. s "proxy"). Pokud tento útok posunete blíž ke zdroji, je situace jiná (= srov. s reverzní proxy).

Když říkáš, že je to špatně, tak taky řekni, jak to má být správně.

Status quo. Neumím-li situaci jednoznačně zlepšit, nehrabu do ní, protože napáchám ještě víc škod.

A proto se u CZ domény dají změny zablokovat.

Nedají. Můžete omezit dispozici s doménou (převody), ale ne správu DNS u jednotlivých registrátorů a správců.

musíš umět to samé a navíc musíš získat certifikát, což není ani trochednoduché.

Právě že je. Je to jen o něco složitější, než běžný MITM útok na HTTP.

"a jen to zvyšuje náklady."
Skutečně? Dokaž to.

Proč bych něco dokazoval? Já nechci měnit zavedené požádky. Dokazovat musí ten, kdo chce změnit chování prohlížeče milionům lidí.

Ad 2 – to nijak nesouvisí s ACME, ale se způsobem ověřování. DV certifikáty se běžně vystavují tak, že dokážete, že ovládáte webový server nebo poštovní schránku.

Ad 3 – ano, DV certifikáty překvapivě potvrzují schopnost manipulace s DNS. Pokud útočník může libovolně manipulovat s doménou, jak předpokládáte, může se stát i jejím vlastníkem. Mimochodem, který registrátor umožňuje převzít kompletní správu doménu tím, že jenom odchytíte e-mail?

Já za větší problém, než potvrzování přes DNS (které potvrzuje to, co potvrzovat má, totiž že dotyčný ovládá doménu), považuju ověřování přes HTTP nebo přes e-mail – protože to, že někdo dokáže vystavit specifický soubor na webovém serveru, nebo přijmout e-mail pro určitou schránku, neznamená, že ovládá doménu.

Ve skutečnosti HTTP a HTTPS s DV certifkátem jsou stejně bezpečné. Označovat HTTP za nebezpečnější než HTTPS s DV certifikátem je chybné, nikam nás to neposouvá a jen to zvyšuje náklady.
No jistě. Je jenom na vlastníkovi domény, jak si přístup k její správě zabezpečí. Pokud jej má bezpečný, jsou i DV certifikáty bezpečné. Jak to samé zajistíte s HTTP?

Je jenom na vlastníkovi domény, jak si přístup k její správě zabezpečí. Pokud jej má bezpečný, jsou i DV certifikáty bezpečné. Jak to samé zajistíte s HTTP?

Ta odpověď je stejná, jako píšete Vy: je to na vlastníkovi domény, jestli HTTP používá, nebo přejde na DV HTTPS, nebo přejde na OV/EV HTTPS.

Odpovídáte na něco jiného. Bavíme se o případu,kdy vlastník domény chce zajistit zabezpečené spojení uživatelů ke svému webu, aby viděli opravdu to, co on na svém webu píše. Já jsem psal, že k tomu může použít HTTPS spojení ověřené DV certifikátem, protože vlastník domény si reálně může zajistit to, že s jeho doménou nebude manipulovat nikdo nepovolaný a nepůjde tedy vystavit falešný DV certifikát podvodem na straně vlastníka domény. (Podvod či chybu na straně CA zase umožňuje odhalit CT.) Vy píšete, že HTTP je srovnatelně bezpečné, jako HTTPS. Tak se ptám, jakým způsobem dokážete to zabezpečené spojení uživatelů k webovému serveru zajistit pomocí HTTP.

To jsem zvedav co dostane za punc self-signed, kdyz http bude not secure...

To jsem zvedav co dostane za punc self-signed, kdyz http bude not secure...

Navrhoval bych označení stříbrno-červenou a nápis: Unsecure Non Plus Ultra (nebo Non Minus Ultra?).

S výrazným rozšířením https to smysl má. Když bude všude, je potřeba upozorňovat kde není aby bylo.
Pokud se tedy smíříme s tím, že to co dělá Google je správně...

Ale docela by mne zajímalo, kdy opraví ten český překlad "Připojení není zabezpečené" == "Site is secured" co je už měsíc v Chrome + Win.
Pokud toto nikomu nevadí, všichni jsou v klidu, tak pak je úplně jedno co tam vlastně a jak to vypadá, protože to nikoho nezajímá :o\

misto blbosti se zmenou barvy zamku by se meli zamysled nad tim, proc, kdyz napisu adresu bez specifikace protokolu, jdou default na http a ne na https. To je pak k nicemu.
priklad
mam web server a na nem nejake stranky dostupne jak pres http, tak pres https
do browseru napisu https://mujweb.com, dostanu to po https
ale pokud napisu jenom mujweb.com, dostanu to pres http
To je blby, co?
Jestli se chce nekdo ptat proc to http nenecham automaticky presmerovavat na https, tak je to kvuli klientum, co se nedokazou pripojit pres https (nemluvim o klientech lidech, ale o klientech strojich).

Jestli se chce nekdo ptat proc to http nenecham automaticky presmerovavat na https, tak je to kvuli klientum, co se nedokazou pripojit pres https (nemluvim o klientech lidech, ale o klientech strojich).

Na to Vám zde kolegové napíší, že problém je Váš a minoritní, a abyste dokázal, že přechod na https Vás bude stát nějaké peníze.

> Nemůžete ty klienty rozlišit pomocí User-Agent a zbytek přesměrovat?
Jo, muzu, ale prijde mi jednodussi a spravnejsi nabizet obsah obema protokoly. Kdo chce, vezme si to pres https. Kdo nechce nebo nemuze, vezme si to pres http. Nektere stare verze nasich produktu se nedokazou spojit pres https, protoze kryptografie, ktera fungovala pred 10 lety uz dnes nefunguje. Pokud si zakaznik z jakehokoliv duvodu nechce nebo nemuze upgradnout system, neda se nic delat, pouziva 10 let stary produkt a ten se proste nedokaze spojit pres https. User-Agent je furt wget, dokonce stejna verze jako v posledni verzi produktu, ale chybi tam pravdepodobne podpora nejposlednejsich kryptovacich agoritmy, diky cemuz se to nespoji. Ono uz jenom donutit ssh aby se spojilo s temito starymi systemy byl peknej porod.

Problem na ktery jsem chtel upozornit je v tom, ze i presto, ze vsichni vyrobci browseru se predhaneji v tom, aby zobrazovali warningy, ze web neni zabezpeceny, tak kdyz maji obe moznosti, vyberou si tu nezabezpecenou.
HSTS preload je uz uplne na hlavu postavena vec.

vyrobci browseru se predhaneji v tom, aby zobrazovali warningy, ze web neni zabezpeceny, tak kdyz maji obe moznosti, vyberou si tu nezabezpecenou.

Pravda.

HSTS preload je uz uplne na hlavu postavena vec.

To si nemyslím. To je něco, co je vědomě a kontrolovaně iniciované poskytovatelem obsahu, a příjemce se tím řídi může, nebo nemusí. Zvyšuje to bezpečnost tam, kde obě strany chtějí, ale nepopírá ji tam, kde jedna ze stran nechce.

Nicméně prohlížeč by nezabilo, kdyby zkusil nejprve HTTPS, a když se nepodaří navázat spojení nebo v případě chyby, teprve pak by zkusil HTTP. Který protokol má prohlížeč vyzkoušet je jenom věcí tradice, navíc by se tím mírně zrychlilo načítání webů bez HSTS dostupných přes HTTPS.

Pokud je server správně nakonfigurovaný, dozví se prohlížeč hned, že je port nedostupný. Jinak prohlížeč klidně může zahájit spojení na oba porty najednou, a pokud dostane odpověď na portu 443, spojení na portu 80 resetuje. Navíc Google upřednostňuje HTTPS ve vyhledávání, HTTP/2 podporuje jen s HTTPS, prodleva při čekání na timeout na portu 443 může být ze stejného ranku – pokud chcete, aby váš web fungoval co nejlépe, použijte HTTPS. Je to docela schizofrenní, že je snaha všude nasadit HTTPS, ale přitom pro provoz HTTPS potřebujete povinně HTTP – v prohlížeči pro přesměrování prvního požadavku, u ACME pro ověření vlastnictví domény přes HTTP server…

K tomu je i issue v bugzille mozilly [1]. Pokud se nespojíte nebo dojde k chybě certifikátu, situace je jasná. Horší by to bylo s jiným obsahem nebo s mixed content. Tam je někdy těžké poznat, zda je stránka v pořádku. Na jednu stranu možná nebude množství takovýchto stránek malé, na druhou stranu: Pokud se admin nerozhodl přesměrovat, snad k tomu měl dobrý důvod.

Méně kontroverzní by asi bylo spekulativně navázat HTTP i HTTPS a v případě přesměrování ušetřit trochi času.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1158191

Připojují se ty stroje ke stejným URL jako lidi? Nebo jen k nějakému API, které možná stránka na pozadí používá, ale nejde o URL, o které by věděl uživatel (pokud si neotevře zdroják nebo developre console nebo podobně)? Pak by bylo asi nejelegantnější z přejměrování pár URL vyjmout. (Pokud vyjmete i obrázky, zavádíte duplicitní obsah, ale u obrázků by to mohlo být ještě snesitelné.)

Detekce UA se taky nabízí, jak tu někdo zmiňoval. Je to sice trochu hack, ale snad celkem akceptovatelný. Redirect u wgetu bych za moc důležitý nepovažoval.

Dal by se udělat i oportunistický upgrade pomocí JS spolu s HSTS, ale to bych bral jako poslední variantu. Přináší to některé problémy, například:

* Pomalejší první redirect.
* Duplicitní obsah pro vyhledávače.
* Když budete generovat URL třeba do e-mailu, kterou variantu zvolíte? Pokud máte aplikaci zcela ve své režii, je to ještě v pohodě (no, framework může trochu působit potíže), u hotové aplikace to může vyžadovat ošklivé hacky.

(Bez HSTR budou nevýhody výraznější – jak výkonově, tak bezpečnostně.

Dvě varianty webu (HTTP a HTTPS) bez oportunistického upgrade přinášejí ještě více problémů, například:

* Duplicitní obsah i pro uživatele. Například: Dělám společnou objednávku, dám zboží do košíku (HTTPS), dostanu od někoho link (HTTP), kliknu na něj a vidím prázdný košík. (Podobný problém můžete také mít u variant s „www.“ a bez „www.“.)
* Varianta s HTTP může nastavit cookie variantě s HTTPS. Uživatel tak může být například nechtěně přihlášen útočníkem na síti. Dopad je stejný jako u https://support.detectify.com/customer/portal/articles/1969819-login-csrf , liší se jen způsob provedení. Nabízí se i vyšší náchylnost k session fixation, ale to lze ošetřit.