jasne, to bude dalsich nadsenych BFUcek, ktery budou nadseny z toho, ze jejich kavovar je tak strasne nebezpencej, ze uz si nemuzou ani klinout na "uvarit kafe".
Mno hlavne ze soudruzi z chrozilly, zcela jiste v zajmu bezpecnosti, instalujou vzdalene malware ala mr robot, coz nejen ukazuje na to, ze chrofox je browser naprosto nepouzitelnej, ale jeste k tomu ma zadni vratka a je tudoz naprosto neduveryhocnej. V tuhle dvili je na tom presne stejne jako chromak, kterej se siri v podobe adware.
Je to trochu matoucí, protože HTTPS automaticky neznamená bezpečí, a HTTP automaticky neznamená nebezpečí. Spíš je to tlak na tvůrce a správce, aby nad zabezpečením a bezpečností začali přemýšlet. To ale fungovalo předloni a loni. Letos už jsou zákazníci zvyklí, že na panelu webhostingu kliknou na tlačítko "zabezpečit Let's Encrypt", nebo dokonce, že se to zabezpečí samo... Takže na konec zase nedochází k tomu, že by bezpečnost někdo reálně řešil. Výsledkem je, že kdejakou pitominu, obrázek, script, prezentaci bez jakékoliv interaktivity šifrujeme a utrácíme tak mega/giga/terawatthodiny, čistě jen ze zásady.
Myšlenka trochu šťouchnout do lidí, aby bezpečnost řešili, je mi sympatická. Tato snaha je ale nedomyšlená a výsledek diskutabilní, minimálně s ohledem na globální výpočetní náročnost. (Pokud je tu nějak environtamentalista, možná by to bylo téma na zajímavou disertační práci).
HTTPS samo o sobě neznamená bezpečí, ale HTTP automaticky znamená nebezpečí. Nebezpečí představuje vůbec samotná existence nešifrovaného HTTP – nejsnazší útok na HTTPS totiž spočívá v downgrade na HTTP. Takže nejde o nějakou zásadu, jde o reálné řešení bezpečnosti, kdy je potřeba se HTTP postupně úplně zbavit.
Nebezpečí ponížení spojení se dá podle mě úspěšně mitigovat daleko levnějšími prostředky.
Například? Pošlu e-mailem uživateli odkaz s HTTP na web, na kterém nikdy nebyl. Jak zajistíte, aby na něj šel přes HTTPS?
bude to zároveň impulzem k hledání nových typů hrozeb / útoků v rámci HTTPS
No a co? Snaha zaútočit na přenos bude pořád stejná, akorát útočit na HTTPS je mnohem složitější, takže uspějí jen ti lepší.
Zloduši společně s HTTP nevymřou.
To nikdo netvrdí. Ale nedostanou příležitost k útoku naservírovanou na zlatém podnose.
Pokud jsem poskytovatel webu, měl bych rozhodnout, jestli celý, či jeho části potřebují být zabezpečené šifrovaným přenosem. Nic mi nebrání nastavit HTTP redirect na HTTPS. Daleko pravděpodobnější se mi zdá, že mi někdo pošle odkaz na úplně podvržený web, a ten klidně pojede na HTTPS. Opatřit HTTPS certifikát pro libovolnou doménu (kterou vlastníte, či kde získáte přístup k DNS) není problém.
Vynucené opuštění HTTP prostě neřeší skoro nic, ale náklady zvedne všem.
Pokud jsem poskytovatel webu, měl bych rozhodnout, jestli celý, či jeho části potřebují být zabezpečené šifrovaným přenosem.
Pokud nějaké části nepotřebují být zabezpečené šifrovaným přenosem, nemusí být na webu vůbec – zřejmě nejsou důležité a ničemu nevadí, když místo nich uživatel dostane něco jiného. Takže na webovém serveru má smysl mít jen věci, které se posílají šifrovaně.
Nic mi nebrání nastavit HTTP redirect na HTTPS.
A útočníkovi zase nic nebrání ten redirect zrušit.
Daleko pravděpodobnější se mi zdá, že mi někdo pošle odkaz na úplně podvržený web, a ten klidně pojede na HTTPS.
Což je ovšem jiný problém. Když chci, tak si tu webovou adresu můžu ověřit, například.
Vynucené opuštění HTTP prostě neřeší skoro nic
Řeší ten problém, že se úplně zbytečně používá nešifrované spojení, přitom to nemá žádný přínos, jenom dost vážné negativní dopady na bezpečnost.
náklady zvedne všem
Ty náklady se limitně blíží nule.
Tak přesměrování nikdo nemůže zrušit, když server na HTTP prostě obsah nepošle a pošle jen a pouze redirect.
Zrušit ho samozřejmě může, například tím, že se k původnímu serveru nedostane ani ten požadavek. Můžete si to vyzkoušet – nainstalujte si na svůj počítač webserver, v /etc/hosts si nastavte root.cz na 127.0.0.1 a zkuste si, jestli se z prohlížeče dostanete na http://root.cz a jestli vám server Internet Infa pošle přesměrování.
To, že jsou náklady rozmělněné, neznamená, že jsou nulové.
Nepsal jsme, že jsou nulové, ale že se blíží nule. Jsou zanedbatelné, nemá smysl je řešit, protože je mnoho jiných cest, kde se dá ušetřit řádově víc.
"Například? Pošlu e-mailem uživateli odkaz s HTTP na web, na kterém nikdy nebyl. Jak zajistíte, aby na něj šel přes HTTPS?"
Proč? Pokud vlastník webu provozuje jak HTTP tak HTTPS verzi, tak asi ví, co dělá. Nebo snad chcete naznačit, že existuje vektor útoku, kdy si dokážu k nějakému webu, třebas https://rb.cz udělat vlastní web http://rb.cz?
Buď řešíte problém který neexistuje (kam se dostanu když místo https dám jen http), nebo řešíte problém, který takhle vyřešit nejde (například když místo https://rb.cz bude v emailu https://rb.cn).
Zajímá mě to čistě s ohledem na to vaše "pošlu e-mailem". O tom, že https by mělo být všude, nejsme ve při. Jen mi uniká, co to má společného s odkazem v emailu.
Proč? Pokud vlastník webu provozuje jak HTTP tak HTTPS verzi, tak asi ví, co dělá.
A pokud tu HTTP verzi provozuje útočník, už teprve ví, co dělá.
Nebo snad chcete naznačit, že existuje vektor útoku, kdy si dokážu k nějakému webu, třebas https://rb.cz udělat vlastní web http://rb.cz?
Ano, takový vektor útoku existuje, nazývá se MitM a je to důvod, proč vůbec HTTPS (a jiné šifrované protokoly) vzniklo. Jde o to, že útočník může přesměrovat komunikaci uživatele na svůj vlastní server – např. se mu podaří podvrhnout DNS odpověď, nebo ovládne nějaký router po cestě.
například když místo https://rb.cz bude v emailu https://rb.cn
A nebo bude v e-mailu https://rb.cz. Uživatel se podívá na odkaz, vidí správný odkaz, v prohlížeči pak zkontroluje správnou doménu, ale už mu nedojde, že by měl zkontrolovat ještě protokol.
Pane Jirsáku, on tu nikdo podle mě nezpochybňuje výhody HTTPS jako takového, ani existentní možnost MitM útoků. Pobuřující je, že o tom rozhoduje třetí strana. Poskytovatel obsahu, a částečně příjemce, by se měli dohodnout na úrovni zabezpečení, a prohlížeč a servery by k tomu měly dát pouze nástroje. Tomu se říká svoboda a opaku se říká diktatura. Je lhostejné, jestli se jedná o diktaturu v dobrém úmyslu, či zločinnou. Každý diktát ořezává svobodu lidí, a to je vždy nebezpečné. Nikdy si nemůžete být jistý, jestli takové rozhodnutí nebylo iniciováno, či lobbováno nějakou zájmovou skupinou. Dnes to může být opravdu dobromyslné rozhodnutí, příště to může být zájem nějakého výrobce, či vendora dobře ovládajícího danou technologii, nebo zájem vlády.
Konkrétně v tomto případě platformu PROTI MitM útoku, který jste popsal, zajišťuje HSTS + preloading.
Jakej diktát, co to plácáš???
Když se soukromá společnost rozhodne, že jí vyvíjený prohlížeč nebude podporovat protokol, tak to není diktát. Nebo snad chceš říct, že když Chrome nebo Firefox nepodporují Gopher protokol, že je to diktatura?
Diktát by byl, kdyby někdo všem vývojářům zakázal podporu HTTP. A diktát určitě je, když někdo jako ty chce určovat Mozille, jaké protokoly má podporovat.
A jak víte, že to např. celé není iniciované nápadem nějakého výrobce SSL akcelerátorů, který může očekávat zvýšený zájem o své výrobky ze strany poskytovatelů? Nebo výrobcem některých serverů? Tomu se říká lobby, a je na hranici toho, co by se mělo připouštět.
Já neříkám, že to tak je, ale být to tak může. Proto se má připouštět absolutní minimum změn, ke všemu nechat dojít svoji dobu, a nic nerozhodovat seshora.
Velmi inspirativní je Velká Británie, kde zákony mění s obrovskou opatrností, právě s respektem k tomu, že zákon má vyjadřovat vývoj ve společnosti. Zákon NEMÁ určovat nebo měnit vývoj.
Jestli chceme svobodu, musíme se všichni smířit s tím, že nám sice nikdo nebude kecat do toho, na co jsme citliví, ale zároveň také nikdo nebude ovlivňovat ani to, co si MYSLÍME, že je dobré.
Jen v této diskusi je vidět, že existuje významné procento těch, kteří násilné zavádění https považují za blbost.
"A jak víte, že to např. celé není iniciované nápadem nějakého výrobce SSL akcelerátorů, který může očekávat zvýšený zájem o své výrobky ze strany poskytovatelů? Nebo výrobcem některých serverů? Tomu se říká lobby, a je na hranici toho, co by se mělo připouštět."
Jo fakt? A co když lidi, co brojí proti HTTPS jednájí v zájmu hackerů, pro které znamená existence HTTP výhodu?
Pobuřující je, že o tom rozhoduje třetí strana. Poskytovatel obsahu, a částečně příjemce, by se měli dohodnout na úrovni zabezpečení, a prohlížeč a servery by k tomu měly dát pouze nástroje.
Jaká třetí strana? Klidně si s poskytovatelem obsahu domluvte, že si webové stránky budete posílat poštovními holuby. Nikdo vám v tom nebrání.
Tomu se říká svoboda a opaku se říká diktatura.
Chápu, že vy byste autorům prohlížečů rád diktoval, co mají dělat – oni jsou ale naštěstí svobodní.
Každý diktát ořezává svobodu lidí, a to je vždy nebezpečné.
Mou svobodu ořezává to, že prohlížeče implementují nešifrované HTTP, a já tak musím pořád hlídat, jestli jsem na HTTPS. Ale je to moje volba prohlížeče, a já dávám přednost té svobodě, že můžu používat už hotový prohlížeč, před svobodou používat prohlížeč bez HTTP. Ona totiž protikladem jedné svobody většinou nebývá diktát, ale jiná svoboda.
Konkrétně v tomto případě platformu PROTI MitM útoku, který jste popsal, zajišťuje HSTS + preloading.
Já jsem schválně psal o případu, kdy jde o stránku, kterou uživatel nikdy nenavštívil. A představa, že budou prohlížeče distribuované se seznamem všech webových serverů na celém světě, mi připadá velmi zvrácená. To je přece proti základnímu principu internetu.
jo, tovizejo ... pripojit se ke kafemlenku a rict mu "umel kafe" je fakt rizikova cinnost ... specielne kdyz si tvoje maily, vcetne trebas vypisu z banky, muze precist zcela kdokolil a nejen precist, muze je libovolne modifikovat.
Nemluve o tom, ze tu je tak mozna 100G zarizeni, ktery https (ani zadny jiny sifrovani) nikdy umet nebudou.
"Nemluve o tom, ze tu je tak mozna 100G zarizeni, ktery https (ani zadny jiny sifrovani) nikdy umet nebudou."
Máš zajímavě schizofrenický postoj, milé "jéčko".
Když komentuješ IPv6, tak říkáš, že když nějaké zařízení neumí IPv6, tak je to vina jeho výrobce. Kdyź komentuješ HTTPS, tak je najednou nepodpora HTTPS na nějakém zařízení obrovský problém.
Stěžuješ si na násilné protlačování HTTPS, ale jinak říkáš, že například Google by mél při dosažení hranice 30 % požadavků z IPv6 vypnout IPv4.
Výsledkem je, že kdejakou pitominu, obrázek, script, prezentaci bez jakékoliv interaktivity šifrujeme
To už bylo vysvětleno jinde. A dělat selektivní šifrování html ano, obrázky ne, tady bylo v minulosti a celkem správně prohlížeče na to upozorňují. Protože v takovém případě útočníkovi stačí nahradit obrázek svým vlastním sdělením (třeba vyrenderovaný text) a náhle se na "zašifrované" stránce objevuje jiný obsah. Proto musí být šifrované všechny zdroje dat na stránce.
a utrácíme tak mega/giga/terawatthodiny, čistě jen ze zásady
Máte to nějak podložené? CPU mají nějaký ten pátek (asi tak 9 let) podporu pro šifrování a na dnešním konzumním procesoru to umí něco jako 9.4GB/s (ryzen 1700, vera crypt a to ještě encóduju nějaká videa). Tento argument je dávno pasé. (Kdyby se to třeba zdálo moc moderní, tak cpu s roku 2012 umí 3.5GB/s.) Generování toho webu rozhodně takto rychle nepojede a sežere daleko víc Wh.
No stejne dost dobre nechapu proc by ciste informacni weby kde neni interakce s uzivatelem meli byt sifrovane?
Napriklad 10 let stary web kde mimo jine popisuji jak spocitat predradny odpor pro LEDku a podobne zaklady a jsou psane nejspis v cistem HTML. Co by se tam mohlo stat?
Teda krom toho ze si na kazdym routeru budou moci precist ze se vzdelavam?
Proč by mělo HTTPS nahradit HTTP úplně na všech webech bylo popsáno snad milionkrát. A stejně se vždycky najde někdo, kdo se zeptá, protože neumí používat Google...
Takže po milion prvé:
1) Koexistence HTTP a HTTPS s sebou nese riziko SSL stripingu.
2) Podle čeho by se mělo rozhodovat, jestli je obsah webu tajný nebo ne? To co je bezproblémové u nás nemusí být bezproblémové v cizině.
3) Do HTTP může kdokoli cokoli přidat (reklama, malware...) a to se skutečně děje. Na 50% free wifi hotspotů ti budou do HTTP injektovat reklamy.
NIkdo ti svobodu nebere. Prohlížeč, co bude umět HTTP jistě stále existovat bude. Stáhni si ho a používej.
Ale výchozí nastavení BFU prohlížeče pro BFU by mělo být takové, že HTTP bude označovat jako nebezpečné. Protože přes něj může kdokoliv po cestě od serveru ke klientu přimíchat cokoliv, i kdyby se původně jednalo o čistě statickou stránku. A uživatel tomu nerozumí.
Vychozi nastaveni browseru pro BFU musi byt takovy, ze pouzije !!!!!!!!!bez kecu!!!!!!!!!!!! kanal, kterej je k dispozici. Jakmile kdekoli s cimkoli vopruzuje, tak nastavaj varianty od vypnuti vopruzu po vymenu browseru za takovej, kerej se chova tak jak pisu = klidne 10 let starej, protoze to nikoho nezajima.
... to ze niekde je nieco napsiane milion krat neznamena ze to je pravda.
1. riziko tam je, na druhu stranu pretlacanie https a tvrdenie ze je spojenie uplne bezpecne a nic sa nemoze stat akurat vedie BFU k rizikovemu spravaniu
2. to je na kazdom jednotlivcovi snad
3. na tych hotspotoch ti nainstaluju mitmproxy a daju ti navod ako si mas vypnut HSTS v prehliadaci aby ti tie internety sli. 99% BFU to rado urobi len pre ten pocit ze maju free wifi. Cize akurat len dalsie riziko
Anyway, som za HTTPS, akurat nesuhlasim s tym ze riesi vsetky problemy, lenze to tak nei je. A presne toto sa malo komunikuje s end usermi.
tvrdenie ze je spojenie uplne bezpecne
To tu ale tvrdíte jenom vy.
na tych hotspotoch ti nainstaluju mitmproxy a daju ti navod ako si mas vypnut HSTS v prehliadaci aby ti tie internety sli. 99% BFU to rado urobi len pre ten pocit ze maju free wifi
A ten návod zveřejní na stránce hotspotu, na kterou se dostanete po té, co podle něj HSTS vypnete? To aby k té free WiFi přidávali ještě miniaturní stroj času. Navíc 99 % uživatelů by to stejně neudělalo, protože by to ani podle návodu vypnout neuměli.
No stejne dost dobre nechapu proc by ciste informacni weby kde neni interakce s uzivatelem meli byt sifrovane?
Nejde jen o to, že ví, kam chodíte.
Jde také o to, že pokud to spojení není šifrované, tak ta data lze změnit. Takže si například prohlížíte recepty, někdo vám chce ublížit a může změnit data v tom receptu tak, že tam dá dohromady naprosto nevhodné potraviny nebo jejich úpravy. Nebo na tom vašem elektrowebu to schéma může někdo záměrně upravit tak, abyste zničil tu nejdražší součástku apod.
Čímž ten útočník mimo jiné poškodí i toho majitele webu (který tam opravdu chce dávat jen ty nejlepší návody), ale klienti jej budou obviňovat z diletantství, protože ty návody (které oni dostávají) jsou nefunkční. Takže nejen pro klienta, ale i pro autora takového webu by mělo být velmi žádoucí to mít správně šifrované, protože tak má jistotu, že ten klient dostává to, co mu jako autor chce předat.
A tohle (změna přenášených dat), se reálně děje.
To jsou poměrně extrémní případy. Spíš https://arstechnica.com/information-technology/2015/03/massive-denial-of-service-attack-on-github-tied-to-chinese-government/
Tak ty extrémní případy se reálně dějí. Asi ne tak jak jsem je popsal (určitě ne jinak hromadně, což je možná o to nebezpečnější, protože se to špatně hledá), ale do přenášených dat se zasahuje na mnoha free wifi a vkládají se tam reklamy a informace o tom ap a provozovateli apod. Prostě je to zásah do přenášených dat jako takový.
On nejen, že si přečte, na co koukáte. On vám může i něco napsat. Nebo vám podstrčit soubor od někoho jiného. Když ví přesně, o co se snažíte (vidí HTTP hlavičky i předávaná data), tak vám prostě věci podstrčit může.
To si tak čtete jak spočítat LEDku a najednou vám začnou vyskakovat bannery na ***.
Já vidím potenciální riziko HTTP hlavně v tom, že teoreticky mi může útočník podvrhnout jakýkoliv obsah. I kdyby samotná stránka nic důležitého neobsahovala, útočník tam něco "zajímavého" podstrčit může. Klidně i jenom odkaz, který mě zavede na dobře udělaný phishing. A i když odhlédnu od toho, nemusí nikdo po cestě sledovat hlavičky, které můj prohlížeč posílá a přijímá v rámci komunikace.
Já vidím problém v tom, že tím „HTTPS“ se v současné implementaci prohlížečů myslí „HTTPS s certifikátem od posvěcené autority“, protože u obecného HTTPS prohlížeče hrají hru „jste si jisti? opravdu? a stejně tě tam nepustím!“. A situace na trhu certifikačních autorit je taková, že jsou divné, komerční, a jedna jediná použitelná (LE), která občas někomu náhodně odepře službu, musíte souhlasit s konkrétnímu ToS atd. (a obecně monopol je prostě špatný). LE tímto získává docela velkou moc nad internetem a směřuje to k situaci jako Facebook nebo GitHub.
Ja vidim problem v tom, ze sifrovat se ma na urovni IP, a na urovni protokolu ma smysl resit autentizaci, ale ne sifrovani.
A jeste o 10 radu vetsi problem je v tom, ze se tu kdosi snazi miliardy uzivatelu k necemu prinutit, coz vede k tomu, ze protoze oni chteji pouzivat ten svuj kafemlejnek a naprosto je nezajima nejaky podelany sifrovani, tak proste budou pouzivat browser, klidne 10 let starej, kterej bude hlavne drzet hubu.
Navic je stim spojeno to, ze kazda sifra bude driv nebo pozdejs prolomena, a co budem delat s tema miliardana nodu ktery ale nikdy zadnou novejsi umet nebudou ... hodime je vsechny na skladky. Kazdy 2-3 roky a tak porad dokola.
J to píše jako pitomec, ale má naprostou pravdu. Dodat k tomu můžu ještě to, že o bezpečnost by se měly zajímat zejména dvě spolu komunikující strany a standardy k tomu mají dávat MOŽNOST, nikoliv stanovovat zbytečné povinnosti a buzerovat. Cesta do pekla je dlážděná dobrými úmysly, a toto je jeden z nich.
> Ja vidim problem v tom, ze sifrovat se ma na urovni IP, a na urovni protokolu ma smysl resit autentizaci, ale ne sifrovani.
S tím naprosto souhlasím. Tohle by se nemělo řešit na L7, ale níž - už jenom kvůli tomu, že aktuálně je na linuxových serverech konfigurace TLS na 5 různých místech (webserver, smtp, imap, jabber…), každý server se konfiguruje jinak a má jiné volby, a neexistuje možnost jak např. provoz pro účely ladění poslouchat (s perfect forward secrecy už vůbec).
V klientských programech je situace ještě horší, například nastavit či zjistit použité šifrovací algoritmy často nelze vůbec.
je vidět že šifrování nerozumíte. ten model který se v TLS používá nyní a je nejvíc bezpečný se jmenuje authenticated encryption a autentizace stran z něj nejde odebrat. Proč? Protože jinak zase útočník může udělat man in the middle. Ověření identity protistran je nutná podmínka pro bezpečnou implementaci šifrování. Dříve tyto věci byly oddělené ale vedlo to jen k problémům v implementacích a širokému spektru útoků na protokol.
Je videt ze vo tom hovno vis leda ty, protoze ZADNA autentizace NEEXISTUJE. A ani JEDINEJ browser ti ani NEUMOZNUJE nejakou autentizaci bezpecne provadet.
Spokoji se totiz s libovolnym certifikatem podepsanym libovolnou ca kterou ti nekdo trebas zrovna vcera naimportovat do tvyho browseru potazmo systemu. A i kdybys svuj web mel podepsanej vlastni CA je ti to hovno platny, protoze i kdyz bude mit uplne jinej cert, browser ani nepipne.
K tomu dlužno dodat, že ještě před několika lety CA aspoň základně ověřovaly osoby, postupně to začalo slábnout na ověření e-mailem, a dnes stačí mít přístup k DNS či webserveru (Let's Encrypt). Tím, jak se snižuje překážka zavádění SSL, tím degraduje stupeň autentizace.
Řetěz je tak silný, jako jeho nejslabší článek.
Kate, tohle nikdo netvrdí. Ale vezměte si, jaké argumenty zde padají. Jeden považuje SSL za nástroj k autentikaci stran, jiný jako jediný nástroj boje proti MitM, ....
Mám ale pocit, že spousta diskutujících se nesetkává s realitou u uživatelů. Těm je totiž ve skutečnosti poměrně jedno, na co klikají, v čem klikají - nepřemýšlí. Čím víc dostanou dialogů, kterým nerozumějí, tím víc si zautomatizují, jak je přeskakovat a ignorovat.
Jak už jsem psal (výše či níže), za dobrý nástroj považuju HSTS, i když nepodchycuje situaci na 100 %, ale v případě preloadingu skoro 100%.
Až doba dojde zase dál, a vyřeší se i nejasné oblasti - např. správa vlastních zařízení v místní síti, aby nevyhazovala chyby, nebo i diskutabilní otázka celkové potřebnosti vše šifrovat, pak samozřejmě budou muset udělat další krok i prohlížeče.
Technologie mají své možnosti nabízet, ne vnucovat.
A někdo jiný tu zas dělá z rozšíření DV certifikátů pohromu. Ty vždycky byly a jsou jen ověření že dotyčný nějak ovládá doménu / obsah na ní a zajišťují šifrování. Nic víc, nic míň.
Osobně považuji za dobrý nástroj kombinaci všeho, co dovede situaci se zabezpečením webu zlepšit. Do toho spadá HSTS, stejně jako snadno získatelné DV certifikáty a šifrování všeho co jde. Jistě, útoky budou pořád, MitM jde provést nahráním vlastní CA k uživateli a podobně. Jenže přístup „tohle nemá smysl dělat, stejně to jde s o něco větší snahou obejít“ prostě u bezpečnosti není dobrý.
Kate, to si nerozumíme. Nejsem nihilista. Jen vidím tu hranici, kdy podnikat kroky, asi o něco dál a preferuji více přímou odpovědnost nad systémovými zásahy. Osobní odpovědnost je samoregulační, systémové zásahy jsou vždy z principu nebezpečnější - lehce se zavádějí, ale těžce se modifikují a ruší. Když to srovnáte s politikou, tak myslím, že všichni vidíme, kam se v praxi dostala sympatická myšlenka jednotné Evropy.
Uvidíme :) Zatím všude vidím po stávajících zákrocích ze stran prohlížečů jen pozitivní důsledky. Dneska už třeba téměř nenarazím na e-shop bez HTTPS, ještě před rokem / dvěma jich byla spousta. Souhlasím ovšem, že vyhodit čisté HTTP z prohlížečů by byl bez dostatečné náhrady nesmysl. A na to si nějakou dobu počkáme. Ale bez nějakého druhu nátlaku ze stran prohlížečů se prostě nezmění nic :)
Mám ale pocit, že spousta diskutujících se nesetkává s realitou u uživatelů. Těm je totiž ve skutečnosti poměrně jedno, na co klikají, v čem klikají - nepřemýšlí. Čím víc dostanou dialogů, kterým nerozumějí, tím víc si zautomatizují, jak je přeskakovat a ignorovat.
Tohle se vám snažím celou dobu vysvětlit. Jsem rád, že jste to konečně pochopil, že uživatele nemůžete otravovat nějakým výběrem, zda se má používat HTTP nebo HTTPS. Pokud to má být bezpečné, tak prostě není možné uživateli nabízet nezabezpečené HTTP – zvlášť, když v porovnání s HTTPS nemá vůbec žádné výhody.
Jak už jsem psal (výše či níže), za dobrý nástroj považuju HSTS, i když nepodchycuje situaci na 100 %, ale v případě preloadingu skoro 100%.
HSTS jde proti samotné podstatě internetu, je nesmyslné mít centralizovaný seznam všech webových serverů. Zvlášť když není žádný rozumný důvod pro používání HTTP. Tak si to udělejte opačně – vytvořte si seznam webů, kam je možné přistupovat přes HTTP.
> zvlášť, když v porovnání s HTTPS nemá vůbec žádné výhody
Tím myslíte HTTPS s libovolným certifikátem, nebo HTTPS + certifikát posvěcený autoritou, kterou browser uznává?
Jak byste řešil ta webová rozhraní různých krabiček, kde HTTPS implementovat nelze? Neříkám, že se to nutně musí konfigurovat přes standardní browser, nicméně se mi líbila jistá univerzalita, že to fungovalo všude a kdykoli - bojím se, že to skončí tak, že výrobci takových krabiček budou dodávat „appku pro ajfoun a exe pro Windows <= 10“ a uživatelé nových verzí nebo jiných platforem ostrouhají.
Já bych to shrnul tak, že HTTPS lze implementovat tak, aby přinášelo jen výhody, ale bohužel implementace v současných aplikacích (a tím myslím jak klientské, tak serverové*) takové nejsou (například snad nikde nelze naimportovat certifikační autoritu a říct, že se jí má důvěřovat jenom pro *.cuni.cz -- chci bezpečně komunikovat se školou, ale současně nechci, aby na mě školní správce mohl dělat MITM na jiné domény).
* příklad takového implementačního problému, který jsem řešil, byl server s bugem a z důvodu neexistence nějakého API pro získávání session klíčů komunikaci nešlo odposlechnout a podívat se, kde k chybě dochází. Pro ladění jsem tak HTTPS na jedné straně vypnul a zařadil tam socat s HTTP<->HTTPS wrapperem a logoval na něm.
Obdobně se při ladění klienta hodí mít možnost udělat MITM a opět část současných programů toto neumožňuje bez nějakého extrémního patchování.
Tím myslíte HTTPS s libovolným certifikátem, nebo HTTPS + certifikát posvěcený autoritou, kterou browser uznává?
Myslím HTTPS s certifikátem, který prohlížeč dokáže ověřit. Ideálně přes DANE, plus certifikát vydaný uznávanou autoritou, pokud jde o OV nebo EV certifikát.
Jak byste řešil ta webová rozhraní různých krabiček, kde HTTPS implementovat nelze?
Proč by to nešlo? Pokud proto, že mají tak malý výkon,necpal bych tam ani webserver, a případnou webovou konfiguraci by měl zprostředkovávat nějaký prostředník, který na jednu stranu bude mluvit přes HTTPS a na druhou nějakým protokolem, který ta krabička zvládne.
Já bych to shrnul tak, že HTTPS lze implementovat tak, aby přinášelo jen výhody, ale bohužel implementace v současných aplikacích takové nejsou
Ty implementace nebudou ideální nikdy. A někde se ta implementace HTTPS nezlepší, dokud bude nějaká možnost, jak to obcházet přes HTTP.
například snad nikde nelze naimportovat certifikační autoritu a říct, že se jí má důvěřovat jenom pro *.cuni.cz
To ale přece není důvod pro použití HTTP – s tím byste na tom nebyl lépe.
Obdobně se při ladění klienta hodí mít možnost udělat MITM a opět část současných programů toto neumožňuje bez nějakého extrémního patchování.
To chápu, ale to je také do značné míry dané tím, že po tom není poptávka – protože se takový požadavek odpálkuje argumentem „na lokálu snad samozřejmě vyvíjíte pod HTTP, ne?“ Takže nezbývá, než aby samozřejmé bylo HTTPS.
"Spokoji se totiz s libovolnym certifikatem podepsanym libovolnou ca kterou ti nekdo trebas zrovna vcera naimportovat do tvyho browseru potazmo systemu."
Ano, to je princip PKI, delegace důvěry. Bez toho by to nešlo. Není v silách uživatele ručně řešit, kterému certifikátu bude věřit a kterému ne. I kdyby neprováděl ověření a jen certifikáty odklikával, tak se z toho zblázní. Při načítání jediné stránky by musel odklikat třeba 20 certifikátů a to je nereálné.
Asi došlo k nedorozumění, kdy jsem ocitoval i to „na urovni protokolu ma smysl resit autentizaci, ale ne sifrovani“ a pak chtěl reagovat jenom na to první. Osobně bych rád řešil na nižší vrstvě všechno. (prostě TLS by se neimplementovalo tak, že si každý přilinkuje openssl, ale byla by to přímo vlastnost soketu s tím, že by existovaly funkce pro věci jako klientský certifikát).
Varování je ok. Varovat může, dokud nebude v přístupu k HTTP bránit.
Veřejný HTTP web může být riziko i když na něm uživatel nic nezadává a pouze ho čte, protože může být odposloucháván a pozměněn. Potud asi ok. I když jsou tisíce webů, kde ani na tom příliš nezáleží.
Ale vedle toho tu jsou mraky zařízení s HTTP konfiguračním webem, které jsou provozované výhradně v lokální síti (ideálně pouze v jednom segmentu přes jediný switch, router je nikam jinam nepustí, ven už vůbec ne). Taková zařízení musí zůstat přístupná, dokud se budou ve větší míře vyskytovat. Žádná certifikační autorita nikdy nevystaví certifikát mé tiskárně, mému VOIP telefonu, mému domácímu ADSL routeru, IOT hračce ve vedlejší místnosti...
Jiste, myslsi takovy to "varovani" jako ze se muze posrat z toho ze web ma selfsign cert? Pripadne cert nejaky CA kterou ti nekdo nenatlacil do browseru? Vis co udela 100% useru (vcetne ITku) s libovolnejma opakujicima se hlaskama? Serou na ne a proste klipaj na ano ano ano next next next.
Takova zarizeni se uz z chrofoxe adminovat nedaj ... trebas proto, ze dana krabka sice jeste umi "akceptovany" sifrovani, ale uz neumi klic delsi nez 768bitu a chrofox prece vi, ze ty potrebujes nejmin 1024.
Sem zvedav kdy ti pridou soudruzi z chrozilly vyrazit dvere s tim, ze nejsou dost bezpecny a ze si tudiz bud mas poridit pancerovy vrata nebo budes bez dveri.
S nepodporovanou ciphersuite mám také zkušenosti z praxe. Znám firmy, kde smaží staré verze prohlížečů se zakázanou aktualizací, protože jinak se nedostanou tam, kam potřebují. Investovat do povýšení slabých článků nebudou, pro vedení jsou to konkrétně vyhozené peníze proti konkrétně nevypočitatelně nízkému riziku. Administrace kopírky nebo docházkového systému přeci pro ně neznamená ohrožení bezpečnosti!, ale paradoxně tak oslabují bezpečnost i při přístupu ven.
Žádná certifikační autorita nikdy nevystaví certifikát mé tiskárně, mému VOIP telefonu, mému domácímu ADSL routeru, IOT hračce ve vedlejší místnosti...
Mým zařízením v domácí síti Let's Encrypt certifikáty vystavuje. Používám pro ověření DNS a na veřejný DNS server vystavím příslušný ověřovací záznam.
> Ale vedle toho tu jsou mraky zařízení s HTTP konfiguračním webem, které jsou provozované výhradně v lokální síti
Filozoficky správné řešení by podle mě bylo nepoužívat k tomuto běžný browser, ale mít „jakoby browser“, který bude upravený k této činnosti. Nebo mít v běžném browseru na toto přepínač.
Teď je otázka, jestli je to v praxi proveditelné (například by bylo potřeba, aby takový program byl předinstalovaný ve Windows, protože jinak to znamená spoustu nočních můr s BFU).
Pane Jirskáku, na Vaše teze opravdu nevím, co napsat, ale pokusím se.
Takže dodavatel začne ničit obecně používanou technologii, místo toho, aby dal dvěma stranám na výběr, jestli chtějí tímto směrem jít. To je svoboda? Ne, to svoboda není. Pokud tu HTTP je, a někdo Vám ho bere, není možné takový postup považovat za svobodný. Je to diktát skupiny, možná technicky erudované, ale pořád se jedná o diktát. První kroky komunistické strany po Válce byly také obecně přijímány jako pozitivní, přiměřeně radikální svému účelu a době. Ale jaksi se to zvrhlo...
Jestli je HTTPS vhodnější než HTTP? Ano, většinou ano, ale ne vždy. Někde je to zbytečné, složitější, nákladnější.
BFU nedokáže získávat certifikáty na zařízení, která má doma - Vy ostatně víte, kolik lidí je za NATEM, i to, jak schopní jsou koncoví uživatelé. Až budou připraveny technologie, které to umožní, tak pak přijde doba to řešit, a aspoň tuto oblast budeme moci považovat za vyřešenou. BFU rovněž není ochotný měnit všechna svá zařízení ob několik let jen kvůli tomu, že je mu vnucována bezpečnost, kterou možná ani nechce (a umí vyhodnotit rizika).
Přehlcovat uživatele varováními je nebezpečné, přestává je vnímat. V případě HTTP to bude tak častý jev, že jeho pozitivní úloha se vytratí.
Pokud někdo narušuje komunikaci dvou stran, pak je mimo jiné na místě, aby to řešila i ta poškozená strana. Přinejmenším podání podnětu na ÚOOÚ je jednoduché a účinné. Před zloduchy je potřeba se nejenom bránit, ale snažit se je i zastavit.
Za mě je to prostě špatný krok, jakkoliv jsem do teď stimulace k přechodu na HTTPS vítal, tak toto už považuji přes čáru.
Takže dodavatel začne ničit obecně používanou technologii, místo toho, aby dal dvěma stranám na výběr, jestli chtějí tímto směrem jít. To je svoboda? Ne, to svoboda není.
Je to svoboda tak, jak je chápána většinou lidí – někdo vytváří webový prohlížeč, tak on může svobodně rozhodovat o tom, co ten prohlížeč bude umět a co ne. Ostatní mají zase svobodu rozhodnout se, zda ten prohlížeč budou používat nebo ne. Vy si asi pod svobodou představujete něco jiného, chtěl byste rozhodovat o tom, co mají ostatní dělat – to je také určitý druh svobody, je to svoboda diktátora.
Pokud tu HTTP je, a někdo Vám ho bere, není možné takový postup považovat za svobodný.
Jenže on vám HTTP nikdo nebere.
Je to diktát skupiny, možná technicky erudované, ale pořád se jedná o diktát. První kroky komunistické strany po Válce byly také obecně přijímány jako pozitivní, přiměřeně radikální svému účelu a době. Ale jaksi se to zvrhlo...
Vy pořád polemizujete s tím, že je to sice diktát, ale ve jménu dobra. Jenže to tady nikdo netvrdí. Není to žádný diktát – autoři prohlížečů se můžou svobodně rozhodnout, co budou v prohlížeči implementovat, a vy se zase můžete svobodně rozhodnout, zda jejich prohlížeč budete používat. Diktát by byl, kdybyste vy autorům prohlížečů diktoval, jaké jejich prohlížeč má mít funkce.
Jestli je HTTPS vhodnější než HTTP? Ano, většinou ano, ale ne vždy. Někde je to zbytečné, složitější, nákladnější.
Složitější a nákladnější není. Zbytečné je, pokud komunikace jde bezpečným kanálem – jenže to nemá prohlížeč jak zjistit. Zapomínáte také na to, že složitější a nákladnější je podpora dvou protokolů místo jednoho. V případě HTTP/1.x je sice HTTPS jen obalené HTTP, ale u HTTP/2.0 už se šifrovaná a nešifrovaná varianta mírně liší. Naštěstí prohlížeče podporují už jenom tu šifrovanou.
BFU nedokáže získávat certifikáty na zařízení, která má doma
Taky to nemá dělat on, ale zařízení samotné nebo router. IP adresu pro zařízení, které má doma, taky BFU získat neumí – ale přesto to funguje.
Až budou připraveny technologie, které to umožní, tak pak přijde doba to řešit
Ty technologie připravené jsou – např. ACME. Jenže nikdo to neřeší, dokud nemusí.
Přehlcovat uživatele varováními je nebezpečné, přestává je vnímat. V případě HTTP to bude tak častý jev, že jeho pozitivní úloha se vytratí.
Když prohlížeč vůbec nebude podporovat HTTP, nebudou ani žádná varování s HTTP spojená. Píšu vám to celou dobu.
Pokud někdo narušuje komunikaci dvou stran, pak je mimo jiné na místě, aby to řešila i ta poškozená strana. Přinejmenším podání podnětu na ÚOOÚ je jednoduché a účinné. Před zloduchy je potřeba se nejenom bránit, ale snažit se je i zastavit.
To máte pravdu. Nicméně proč se před tím zásahem do komunikace nebo jejím odposlechem nebránit, když je to tak snadné.
Za mě je to prostě špatný krok, jakkoliv jsem do teď stimulace k přechodu na HTTPS vítal, tak toto už považuji přes čáru.
Nešifrovaná komunikace přes internet je jenom dočasná anomálie, pozůstatek z akademického období internetu, kdy se myslelo, že na internetu budou jenom „ti, co se znají“, takže není potřeba nic zabezpečovat. Dnes není žádný reálný důvod nešifrovat, a čím dřív bude všechno šifrované, tím lépe – aspoň přestanou tyhle nesmyslné debaty o tom, že by se z nostalgických důvodů mělo nešifrování zachovat, protože sice nemá žádné výhody, ale přijdeme tím o jednu z možností.
Technologie bude připravená až ve chvíli, kdy si běžný uživatel zřídí přípojku, do ní začne připojovat zařízení, a víceméně bez jakékoliv snahy a zásahu mu vše bude fungovat.
K tomu zatím chybí ta praktická část realizace (ACME v domácích podmínkách, DV když nemáte doménu, případně interní CA a distribuce důvěryhodnosti na zařízení) - nic z toho není hotové, vše je na půli cesty.
Je také zbytečné rozjímat nad tím, jestli byly nešifrované přenosy hříchem minulosti. Myslím, že nebyly, před léty nebyla ani potřeba (jak sám uznáváte), ani technologie to dělat jinak.
Abyste rozuměl, ani mě osobně tento krok nijak nezasáhne. Vám přiznávám to, že Vaše motivace je pozitivní. Jste technicky založený člověk, kterého tyto "starosti" baví, dokonce ho asi i živí. Každý takový není a přesto by měl mít volnost nejen řešit si vše po svém, ale i rozhodnout se, že některá témata řešit vůbec nechce.
SSL to jednoznačně vyhraje, ale nepáchejme zbytečné škody po cestě.
Technologie bude připravená až ve chvíli, kdy si běžný uživatel zřídí přípojku, do ní začne připojovat zařízení, a víceméně bez jakékoliv snahy a zásahu mu vše bude fungovat.
Ano, ale k tomu, aby byl technologie připravená, je potřeba tlak na výrobce těch zařízení. Protože na ně bohužel neplatí nic jiného, než že to uživatelům reálně přestane fungovat. Stačí se podívat, jak to vypadá se zabezpečením těchto zařízení, s podporou IPv6, DNSSEC, s podporou nějakých aktuálních protokolů a šifer, pokud ta zařízení umožňují šifrování. Stačí si vzpomenout, že takhle zařízení se konfigurovala přes ActiveX nebo Flash v době, kdy už ty technologie prakticky nikdo nepoužíval. Ne, na tyhle výrobce bohužel neplatí „je potřeba tohle změnit, začněte to řešit a až budete připravení, tak to změníme“. Oni něco změní až tehdy, když to lidem fakt nefunguje.
ACME v domácích podmínkách
Třeba na Synology NAS to funguje, pokud je dostupný z internetu (což se dostáváme k rozšíření IPv6, kde se postupuje přesně tím stylem „počkáme, až budete všichni připraveni“, takže tu dvacet let řešíme různé rovnáky na vohejbáky s IPv4, místo aby se používalo IPv6).
DV když nemáte doménu
Poskytovatel připojení má nebo může mít doménu vždycky. Před dvaceti lety dávali poskytovatelé připojení ke každé přípojce zdarma e-mailovou schránku, případně prostor na webovém serveru. Ty e-mailové schránky snad někteří drží dodnes. Místo toho mohou začít poskytovat něco užitečného – subdoménu.
SSL to jednoznačně vyhraje, ale nepáchejme zbytečné škody po cestě.
Už jsem zmiňoval IPv6. Už dvacet let se vyhazují peníze za NATy, za software, který NATem umí projít, za neefektivní topologie sítě, za VPN. Přesně z tohohle důvodu – aby se přechod na IPv6 náhodou neuspěchal. Takže já bych to otočil – kompletně na HTTPS nemůžeme přejít hned teď, ale pokusme se zmenšit škody, které to odkládání HTTPS způsobuje.
Jenže Váš "boj za dobro" odnesou jen koncoví uživatelé, kteří to zaplatí časem, penězi a nervy.
Pokud spotřebitel preferuje jednodušší, spolehlivější, levnější přípojku k internetu, i zařízení, i využívat starší harware, který nic z toho neumí, tak má ve Vašem pojetí smůlu. My se proste MUSÍME mít lépe, i kdyby nás to mělo zničit.
Nebo to taky zločince vystimuluje k lepším výkonům a lepšímu krytí. Malý problém může být nahrazen větším. Viz např. alkoholová prohibice v USA vs. vliv mafie, kriminalizace prostituce nebo lehkých drog vs. nárůst pohlavních nemocí a nárůst přechodu na tvrdé drogy,...,...
Dokud je to jen MOŽNÁ TO POMŮŽE, je to málo.
Nebo to taky zločince vystimuluje k lepším výkonům a lepšímu krytí.
Takže vy doma nemáte na dveřích zámek, a nemáte pro jistotu ani dveře, protože to by mohlo zloděje vystimulovat k lepším výkonům? A na počítačích máte vzdálené přihlášení na roota bez hesla?
Asi vás to překvapí, ale zločinci jsou také jenom lidé, a taky porovnávají náklady s výnosy. Když jim něco zkomplikujete, znamená to, že se to pokusí prolomit jenom tehdy, když získají o to víc. Proto se dělá veškeré zabezpečení, jak ve fyzické tak ve virtuálním světě – aby náklady pro útočníka byly větší, než co by útokem získal.
Dokud je to jen MOŽNÁ TO POMŮŽE, je to málo.
Ale ono to je „určitě to pomůže a určitě to nijak neuškodí“.
OK, co může výrobce takové krabičky teď udělat? Podle mě nic, protože žádný standard pro delegaci domén od ISP a získávání certifikátů přes ACME pro ně aktuálně neexistuje, jako malý výrobce ho těžko prosadíte, a než se rozšíří, tak to bude trvat mnoho let.
> Ne, na tyhle výrobce bohužel neplatí „je potřeba tohle změnit, začněte to řešit a až budete připravení, tak to změníme“. Oni něco změní až tehdy, když to lidem fakt nefunguje.
Jenom aby to změnili tak, jak si představujete (což vypadá poměrně komplikovaně a vyžaduje to například použití standardů, které ještě ani neexistují), a ne třeba tak, že ke svému produktu budou dodávat pět let starý Firefox se zakázanými aktualizacemi, budou instalovat certifikační autoritu s veřejně známými privátními klíči nebo vyrobí driver, který přeplácne systémovou knihovnu pro TLS verzí, která bude všechny chyby od jejich zařízení ignorovat.
Ta doména přece nemusí být od ISP, může být od dodavatele toho zařízení. Mnozí už to tak dělají, že k zařízení přistupujete přes nějakou jejich doménu, kterou zařízení „unáší“. Standard pro získávání certifikátů je právě ACME.
Že budou výrobci zařízení tvůrčí v tom vymyslet nějakou příšernost, tomu věřím. Ale od proprietárních utilit, ActiveX komponent a webových rozhraní použitelných jen v Internet Exploreru 4.0 v anglické verzi při rozlišení 800×600 jsme postupně dokonvergovali k webovým rozhraním, která jsou použitelná v libovolném webovém prohlížeči. Takže věřím, že i tohle se časem podaří. A mimochodem, k tomu současnému stavu se dospělo právě tak, že lidé neměli IE 4.0 nebo používali prohlížeč bez podpory ActiveX, takže to byl přesně ten postup, že to reálně nejdřív přestalo fungovat, a až pak to začali výrobci řešit.