Vlákno názorů k článku
Firefox bude varovat před nezabezpečenými HTTP weby
od Jenda - Já vidím problém v tom, že tím „HTTPS“...
-
Jenda (neregistrovaný)
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.
-
j (neregistrovaný)
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.
-
Jenda (neregistrovaný)
> 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.
-
Starous (neregistrovaný)
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.
-
j (neregistrovaný)
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.
-
KateStříbrný podporovatel
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.
-
KateStříbrný podporovatel
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 :)
-
Filip JirsákStříbrný podporovatelMá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. -
Jenda (neregistrovaný)
> 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í.
-
Filip JirsákStříbrný podporovatel
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. -
lojzak (neregistrovaný)
"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é.
-
Jenda (neregistrovaný)
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).
ČLÁNKY DO MAILU