Hlavní navigace

Vlákno názorů ke zprávičce Chrome bude od verze 83 blokovat některá stahování po HTTP od David Heidelberg - HTTPS je super, ale tohle mi začíná smrdět. Skoro...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 7. 2. 2020 15:39

    David Heidelberg

    HTTPS je super, ale tohle mi začíná smrdět.
    Skoro mám pocit, že se brzy objeví HTTP/4 s QUICem a možností vypnout šifrování, potom co lidi začnou nadávat, že je to zbytečně náročné na výkon a datový tok.

    Řekněme, že chci stáhnout _veřejně přístupný_ 10GB datový soubor s videem, proč bych měl přidávat režii HTTPS když:
    - URL je stejně skrz HTTPS viditelná
    - obsah se přenáší po TCP, takže by nemělo docházet k chybám
    - po stažení mohu zkontrolovat sha512sum nebo jiným způsobem ověřit, že je v pořádku...

    ... samozřejmě těžké chtít po běžný uživatelích pouštět shaXXXsum nad čerstvě staženým souborem, ale pokud je obsah servírován skrz HTTPS, nebylo by jednodušší vynutit shaXXXsum check?

    řekněme že máme na https stránce a prohlížeč bude tak laskavý, že nás nechá po čistém HTTP stáhnout soubor a potom ho rovnou ověří kontrolním součtem (získaným skrz HTTPS)...

  • 7. 2. 2020 16:39

    J ouda (neregistrovaný) ---.jirkan.cz

    Dnes je overhead kolem šifrování docela zanedbatelný.
    ad shaxxsum - jenže ten obrovský fajl po stažení nebude asi v cache, takže (neřeším-li krajní nepohodlí) se bojím, že to bude pomalejší než při použití současných AEAD modů šifer které nejspíš ten browser už používá.
    (varianta použít Content-MD5 tu je taky, ale její použitelnost končí u vyloučení neúmyslné chyby někde na drátě).

  • 7. 2. 2020 16:45

    Filip Jirsák

    Aby to dávalo smysl, musel by být hash uvedený už u odkazu. Já jsem byl dnes překvapen, že element a ještě takový atribut nemá, byl jsem přesvědčen, že se přidával spolu s atributem download.

  • 7. 2. 2020 17:23

    kamui

    Overhead je zanedbaptelný, když máte počítač s nabušenou i5/i7. Zkuste si to nějakého Android aparátu přenést něco většího přes FTPS (ekvivalent HTTPS), ideálně když máte 802.11ac WiFi. Já to zkusil a tablet (Samsung Galaxy Tab S5e) se skoro zavařil, přičemž rychlost proti obyčejnému FTP byla asi tak poloviční.

    Takže ne, nešifrované protoooly mají stále smysl.

  • 7. 2. 2020 17:38

    J ouda (neregistrovaný) ---.jirkan.cz

    Tak vzhledem k tomu, že už ta samotná WiFina tam jede na AES, tak bych chybu hledal hlavně v tom klientu.
    Jinak šifruju už od doby Apache1.2.xx/BenSSL a nějak problém s CPU nikdy nebyl.

    (jen tak mezi řečí - taky se mi nelíbí způsob zasazování omezení do browserů a osobně je beru za nesmyslná - nevidím rozdíl mezi 'provozovatel stránky je lama, neodhadnul risk http a někdo to změní po cestě' versus 'provozovatel stránky je lama a nechá si to infikovat přímo na serveru' což z pohledu klienta dopadne ve výsledku stejně, ale technické parametry proti by měly být racionálně k věci - tam bych to chápal jako argument pádný u Arduina a spol. ale ty bych stejně nevystrkoval do netu přímo ale přes nějaký WAF, cache apod. který už může udělat šifrování pořádně.)

  • 7. 2. 2020 17:47

    Filip Jirsák

    Podpora HTTP v prohlížeči ohrožuje každý web, i ten, který má HTTPS udělané sebelépe. Takže cílem je podporu HTTP z prohlížečů úplně odstranit. To neznamená, že každý jednotlivý krok na té cestě zvýší bezpečnost webů. Jedním z kroků je například to, že HTML načtená přes HTTPS nebude mít žádné zdroje načtené přes HTTP. Protože uživatel vidí jen URL té stránky a neví, odkud se co načítá uvnitř stránky. Jenže ani tohle omezení se nezavedlo najednou, zavádí se postupně, podle typů zdrojů. Styly, skripty a obrázky ve stránce už tohle omezení mají delší dobu, a teď přišla řada i na stahované soubory (které uživatel vnímá jako součást stránky).

  • 7. 2. 2020 18:00

    kamui

    A jak bude vyřešena nepodpora HTTP u zařízení typu domácí router, konfigurovaných přes web? Pokud tam dáte HTTPS, jaký tam dáte certifikát, aniž by prohlížeč řval jako píchlá svině?

  • 7. 2. 2020 18:16

    Filip Jirsák

    Ty otázky jsou myšlené vážně? Opravdu je potřeba se ptát na takové triviality?

    Nepodpora HTTP bude vyřešena tak, že zařízení bude podporovat HTTPS. Konfigurace těchto zařízení se totiž neustále zjednodušuje a přibližuje uživateli – nejprve se nastavovala pomocí hardwarových propojek, pak přes sériový port, telnet, pak ActiveX v prohlížeči a dnes už jsou to často AJAXové nebo SPA webové aplikace. Prostě se využívá toho, co už má uživatel k dispozici. Když bude mít webový prohlížeč, který podporuje jen HTTPS, výrobci routerů se tomu přizpůsobí.

    Certifikát tam dám třeba od Let's Encrypt nebo od jiného vydavatele, který bude podporovat ACME protokol. K certifikátu je samozřejmě potřeba doména. Doménu může poskytnout výrobce toho routeru, jeho distributor nebo prodejce, poskytovatel připojení, poskytovatel dynamického DNS případně může mít uživatel svou vlastní doménu.

    Dříve například bylo běžné, že ISP poskytoval k připojení e-mailovou schránku a prostor pro malý web. Takže to není nic nového. Aspoň se zbavíme dalšího nesmyslu, totiž že lidé doma běžně používají IP adresy. Pokrok nezastavíte, a když už lidé zařízení při připojení do sítě musí pojmenovávat, třeba se v historicky krátké době dočkáme i toho, že budou moci pomocí těch jmen také se zařízeními komunikovat.

  • 7. 2. 2020 18:13

    J ouda (neregistrovaný) ---.jirkan.cz

    A teď prakticky, mám web s Strict-Transport-Security headerem, cookiny mají secure, a o tom, jestli něco načtu nebo nenačtu přes http rozhoduji já (a abych byl konkrétní, tak přes http je tam jedna věc, kterou si stahuje bot ten si kontroluje HMAC). Jak mě ohrožuje _podpora_ http v prohlížeči? že budu naštvanej když se něco po...á, že se z browseru nepodívám, co to vlastně vrací.
    Nevidím větší riziko než třeba vlastnictví nože - když s ním budu dělat blbosti, můžu se pořezat. Zakážeme plošně vlastnit nože?

  • 7. 2. 2020 18:20

    Filip Jirsák

    Podpora HTTP v prohlížeči vás ohrožuje tím, že každý uživatel, který chce s prohlížečem navštívit váš web a nemá uloženou informaci z HSTS, půjde nejprve na HTTP variantu – a na tu může útočník zaútočit velice snadno. Všechno ostatní, že máte na webu HTTPS a že tam máte HSTS, je úplně jedno, protože ten první požadavek je nechráněný – a to útočníkovi stačí.

  • 7. 2. 2020 19:33

    J ouda (neregistrovaný) ---.jirkan.cz

    Nepůjde. Půjde tam nejspíš přes odkaz - https. Nebo tam půjde přes HTTP, a dobře motivovaný útočník po cestě mu tam podvrhne cokoli. Protože je to evidentně první přístup, nemá ta stránka evidentně nic povoleného - nic horšího než když se překlepne v hostname a jde to rovnou na falešný web útočníka (který navíc bude mít platný letsencrypt certifikát, takže z deště pod okap).
    Mimochodem tohle je řešitelné triviálně tak, že odkaz bez protokolu se automaticky bez http fallbacku doplní na https. A rozbije to mnohem méně věcí.
    Nebo snad mi (bez platné session cookiny) něco podhodí na ten https web? Tam bych opravdu chtěl vidět praktický útok, pokud ten https web nemá mnohem horší problém.

    Naopak purismus, který tu propagujete vede k průseru mnohem závažnějšímu. Mám appliance, pod supportem, aktualizované, ne úplně zadarmo. Když se něco zblbne, je poslední možností factory reset, což je obnova původní image. Pak se pustí (webovej) first time config wizard, následně se to zaktualizuje a znovu přihodí do clusteru.
    Jenže aby se ten wizard pustil, tak je potřeba mít na admin stanici nainstalovaný několik let starý browser, který si poradí i s RC4 a SSLv3, jen proto že moderní browsery jsou tak puritánské, že už nejdou použít ani s silným hrabáním do configu. Takže místo celkem malého rizika možnosti downgradu na slabou šifru tu máme najednou riziko kriticky zranitelného browseru, navíc s docela zajímavým přístupem do security zón, kam se normální opatchovanej browser nedostane. A kde je bezpečnost teď?

  • 7. 2. 2020 20:01

    Filip Jirsák

    Ten odkaz na HTTPS se vezme kde? Na stránce servírované přes HTTP, kterou útočník může změnit? Dostat se pomocí překlepu v doméně na web útočníka je poněkud méně pravděpodobné, než zadání správné adresy, nemyslíte? Netuším, jak to souvisí s cookies. Pokud útočník může ovládnout web, protože může kvůli HTTP manipulovat s obsahem, může třeba získat takovou maličkost, jako přihlašovací údaje uživatele. Pořád je to nezajímavý útok?

    Odkazy bez protokolu se na odkazování na jiné weby prakticky nepoužívají. Navíc máte spoustu odkazů s protokolem HTTP – to ten váš návrh nijak neřeší.

    Příklad s nějakým zařízením, které je dostupné jen přes HTTP, nebo přes nějaké staré HTTPS, se objevuje snad v každé diskusi. A mne už nějak nebaví předstírat, že je to rozumný protiargument. Takže budu upřímný – to, co píšete, je hodně hloupé. Ohrožovat miliardy uživatelů, miliony webových stránek a aplikací, internetová bankovnictví, platební brány, webové e-maily, souborová úložiště a další a další jenom pro to, že by si nějaký administrátor musel pro ovládání nějakého zařízení nainstalovat speciální software – nějakou starou verzi prohlížeče, který by používal jen pro správu toho jednoho zařízení, případně SSL proxy? Opravdu myslíte takovou hloupost vážně? Jaké bude vaše další bezpečnostní opatření? Třeba by banka mohla nechávat otevřený trezor, protože to tam má blízko uklízečka a hodilo by se jí tam nechávat kýbl s hadrem, ne? To je tak na stejné úrovni, jako ten váš argument. Správce by musel pro správu drahého důležitého zařízení minimalizovat prohlížeč, kde čte iDnes, a spustit speciální aplikaci – to po něm přece nemůže nikdo chtít…

  • 8. 2. 2020 19:43

    J ouda (neregistrovaný) ---.jirkan.cz

    Ten poslední odstavec myslíte vážně? Pokud ovšem nemá jít o přehlídku argumentačních failů, pak je plně na místě.
    Vzhledem k tomu, že od diskuse na odborném webu očekávám argumenty odborné a ne přehlídku rétoriky, nema další diskuse smyslu.

  • 8. 2. 2020 19:52

    Filip Jirsák

    Pokud očekáváte odborné argumenty, proč sám píšete tu hloupost o tom, že miliardy lidí musí používat jako webový prohlížeč stejný program, jaký používá správce pro správu nějakého zařízení? Argumentační faul jsem nepoužil žádný, jenom jsem po pravdě napsal, že váš argument je hodně hloupý. Ale máme štěstí, že ke správě toho zařízení nepoužíváte telnet – to byste ho nutil všem, pro přístup do internetového bankovnictví, do webmailu, pro čtení novin.

    Ale pokud máte nějaký argument, proč nemůžete použít proxy server, starý prohlížeč ve virtuálním prohlížeči nebo starý prohlížeč přímo na svém počítači, který budete používat pouze pro správu toho zařízení (řazeno podle bezpečnosti), sem s ním.

  • 8. 2. 2020 21:19

    Miroslav Šilhavý

    píšete tu hloupost o tom, že miliardy lidí musí používat jako webový prohlížeč stejný program, jaký používá správce pro správu nějakého zařízení?

    Pokud by tato funkce byla ovládána headerem ze serveru, splnilo by to stejný účel. Provozovatelé (ti zodpovědní) by to nastavili a bezpečnost by byla zachována.

    Mimochodem, zcela jistě by se dalo "vyjednat" s autory webserverů i maintainery distribucí, aby u http serverů byly tyto hlavičky odesílány by default v případě https spojení (ale vypnutelné). I takovéto opatření by pomohlo zvýšit bezpečnost pro miliardy lidí (nové instalace by k tomu vedly), a zároveň by se zachovala kompatibilita.

    Filipe, nikdo zde nezpochybňuje to, že se jedná o krok směrem k bezpečnosti. Kritika zaznívá na způsob, jakým je to od Googlu vynucováno, s ohledem na to, že existují i jiné rozumné alternativy. To pochopitelně vede k úvahám, proč Google zvolil takto drsný způsob.

    8. 2. 2020, 21:20 editováno autorem komentáře

  • 8. 2. 2020 21:37

    Filip Jirsák

    Pokud by tato funkce byla ovládána headerem ze serveru, splnilo by to stejný účel.
    Jasně, prohlížeč by se k tomu zařízení připojil přes TLS 1.3, zařízení by spojení přijalo a odpovědělo by hlavičkou „já jsem si vlastně vzpomnělo, že TLS 1.3 vůbec neumím, vracíme se k SSLv3, OK?“ Pane, vy jste hlava!

    Kritika zaznívá na způsob, jakým je to od Googlu vynucováno, s ohledem na to, že existují i jiné rozumné alternativy.
    Není to vnucováno Googlem. teď nevím, zda rozumnou alternativou myslíte to, že zařízení bude podporovat nejnovější HTTPS, pak si vzpomene, že to vlastně neumí a tím nejnovějším HTTPS pošle hlavičku, že je potřeba udělat downgrade. Nebo zda rozumnou alternativou myslíte spíš to, že se prohlížeč nejprve připojí přes SSLv2, server odpoví hlavičkou „já ale umím i TLS 1.3“, kterou útočník smaže a dál budou vesele komunikovat přes SSLv2 pod dohledem útočníka. Mimochodem, myslel jsem, že přesně tohle (tedy že bezpečnější kanál je jen volitelný a útočník může jeho volbu potlačit) kritizujete na SMTP.

    Rozumná alternativa je, že když máte zařízení, které umí jen nějakou starou verzi SSL/TLS, dáte před něj proxy, která bude do světa komunikovat bezpečným protokolem a s tím zařízením bude komunikovat protokolem, kterému to zařízení rozumí. A zakážete přístup k tomu zařízení z čehokoli jiného, než z toho proxy serveru. Na proxy pak můžete udělat pořádnou autentizaci, audit apod. Tohle je bezpečné řešení, ne to, že povolíte SSLv3 ve všech prohlížečích.

    To pochopitelně vede k úvahám, proč Google zvolil takto drsný způsob.
    Problém není v těch úvahách, problém je v tom, že ty úvahy stavějí na nesmyslech.

  • 9. 2. 2020 13:54

    Jan Hrach

    > Příklad s nějakým zařízením, které je dostupné jen přes HTTP, nebo přes nějaké staré HTTPS, se objevuje snad v každé diskusi. A mne už nějak nebaví předstírat, že je to rozumný protiargument.

    Jak se řešilo na AbcL: existuje nějaký attack vector, když prohlížeč nechá uživatele přistoupit na děravou verzi HTTPS pouze po odsouhlasení stejného dialogu, jako když přistupuje na self-signed HTTPS?

  • 9. 2. 2020 14:26

    Filip Jirsák

    V obou případech je útok stejný – uživatel to prostě odsouhlasí a pokračuje na web. Drtivá většina uživatelů nemá znalosti na to, aby dokázala posoudit, zda je pro ně bezpečné či nebezpečné ten web navštívit. Pro ně je to dotaz: „Chcete jít na tento web? Ano/Ne.“ A uživatel tam chce jít, jinak by neklikal na odkaz nebo nepsal adresu. Ten dialog je jenom překážka, kterou uživatel musí překonat – a při jejím překovávání prakticky nikdo nemyslí na bezpečnost, ale jenom jak tu překážku překonat.

  • 9. 2. 2020 14:37

    Jan Hrach

    Takže vstup na web s nedůvěryhodným certifikátem byste také úplně znemožnil?

    Dobře, tu motivaci chápu (byť tímto dáváte obrovskou moc do rukou provozovatelů CT logů a CA, kteří nevydáním/neza­řazením certifikátu můžou zrušit libovolný web), ale vychází mi z toho, že bych akutně potřeboval dva módy browseru: jeden pro BFU, a jeden pro lidi, co tomu rozumí.

  • 9. 2. 2020 15:15

    Filip Jirsák

    Ano, vstup na web s nedůvěryhodným certifikátem bych u prohlížeče ve výchozí konfiguraci úplně znemožnil. Ovšem za důvěryhodný certifikát by se měl považovat i certifikát ověřený přes DANE (a ověřený přes DNSSEC) – bez ohledu na to, jakou autoritou byl vydán nebo zda je self-signed.

    Certifikačních autorit je spousta, provozovatelů CT logů už je také víc. Mnohem větší moc mají jiné subjekty. Kdyby prohlížeče začaly podporovat DANE, byla by ta moc ještě mnohem menší.

    Dva módy prohlížeče přece dávno existují – lidé, kteří si myslí, že tomu rozumí, si mohou spoustu věcí změnit v konfiguraci prohlížeče. Akorát teda lidé, kteří tomu rozumí, obvykle nic vypínat nepotřebují – u svých webů to umí nastavit správně, a na weby, které to nastavit neumí, buď chodit nepotřebují, nebo mají pro legacy web legacy prohlížeč.

  • 9. 2. 2020 20:43

    Miroslav Šilhavý

    Dva módy prohlížeče přece dávno existují – lidé, kteří si myslí, že tomu rozumí, ...

    Ještě je tu třetí typ lidí, které zvesela ignorujete: ti, kteří to platí. Nemám rád, když nabubřelý technik-odborník rozhoduje o tom, co je dobré pro druhého. Je to služná profese, která má dávat ostatním alternativy a rozšiřovat možnosti. Ne je zužovat a určovat.

  • 9. 2. 2020 20:49

    Filip Jirsák

    Nikoli, ty, kteří to platí, neignoruju. Ty, kteří musí platit zabezpečení, které by měl zajišťovat prohlížeč, případně škody, které byly způsobené málo bezpečným prohlížečem. Bohužel dotyční nemohou donutit majitele jiných webů, aby používaly lepší zabezpečení, a prohlížeče tak nemohou bezpečnější režimy nasazovat rychleji.

  • 10. 2. 2020 0:04

    Miroslav Šilhavý

    @Filip Jirsák

    Stejně tak bychom mohli mít zbraně, které povolí vystřelit jen do vzduchu (nebo zakázat ostré patrony, vždyť můžou ublížit). Auta, co jezdí nejvýš padesátkou. Potraviny na příděl, protože přemíra cukrů a tuků škodí. Počítač, co se vypne, abyste se nepřepracoval.

    Naštěstí máme zbraně a každý z nás ví, že střílet na člověka je špatné. Auta dokáží zabít, ale dodržujeme předpisy. Potraviny si můžeme koupit zdravé i nezdravé a sedět u klávesnice durch několik dní a nocí. Každý má volbu, co a jak bude užívat.

    V každém oboru najdete "odborníky", kteří by nejradši svoji oblast řešili radikálně. Naštěstí ve většině oborů nemá nikdo takovou sílu, jako Google mezi prohlížeči, aby se mohl zachovat prasácky. Proto zde hovoříme o zneužití podstatné tržní síly.

    Zapomínáte zcela, že každý takový krok má své vedlejší efekty. Prohibice alkoholu v USA nesnížila společenské problémy, naopak umožnila na dlouhou dobu (dodnes) zakořenit silným mafiím. Gorbačovův pokus s alkoholem v SSSR nefungoval a přinesl další mrtvé, jak pálili samohonku (výbuchy destilačních kolon, metanol).

    Nepřirozený tlak Googlu na tato opatření může mít podobné následky. Namátkou: devitalizace konkurence. Únava klientů z problémů a jejich odchod do cloudu.

    Přitom stačilo dát provozovatelům webů do ruky nástroj (header), kterým by mohli pro svůj web toto chování vypnout (klidně formou opt-out). Historicky se to tak dělalo. Otázka není, jestli je HTTPS lepší, než HTTP. Otázka zní, proč Google zvolil tento postup?

  • 10. 2. 2020 8:32

    Filip Jirsák

    Miroslav Šilhavý: Problém je ovšem v tom, že se v této oblasti vůbec neorientujete. Proto pak děláte nesmyslné závěry.

    Za prvé, že střílet na člověka je špatně každý ví, protože každý si tak nějak dokáže představit, co takový výstřel udělá. Představu o tom, co znamená snížení protokolu z TLS 1.2 na TLS 1.0 má málokdo.

    Za druhé, vymyslel jste si jakýsi „nepřirozený tlak Googlu“, kterým neustále argumentujete, aniž by něco takového existovalo.

    Za třetí, vůbec nechápete, jak celé TLS a zabezpečení funguje. A ani si to vysvětlit nenecháte. Už jsem vám vysvětloval, že aby mohl server poslat HTTP hlavičku, musí nejprve s klientem navázat spojení. A když už tedy naváže to bezpečnější spojení, je nesmysl, aby posílal hlavičku, že to bezpečnější spojení neumí. Pokud byste to nechtěl dávat jako HTTP hlavičku do šifrovaného spojení, ale upravil byste TLS tak, aby tam byla tahle možnost ještě v nešifrované části, zase byste tím úplně pohřbil smysl nových protokolů. Protože útočník by normálně nejdřív nastavil tenhle příznak, že se má přepnout na starý málo bezpečný protokol, a pak už by mu bylo jedno, že existuje nějaký novější protokol, do kterého se nabourat neumí.

    Víte, a tohle je právě důvod, proč vaše komentáře nikdo nebere vážně. Já vám vysvětlím, proč je váš návrh nesmyslný – ne že byste měl odlišný názor, je objektivně nesmyslný, protože jste nevzal v úvahu něco jako přírodní zákon. Ale vy to klidně ignorujete a stejný nesmysl zopakujete znova. Kdybyste přišel na fórum fyziků s tím, že jste vymyslel perpetuum mobile, někdo by vám vysvětlil, že by to bylo v rozporu s prvním nebo druhým termodynamickým zákonem, a vy byste v dalším komentáři napsal, že není potřeba řešit elektrárny, protože jste přece vymyslel to perpetuum mobile, taky by z vás všichni akorát měli legraci.

  • 10. 2. 2020 9:32

    Miroslav Šilhavý

    Za třetí, vůbec nechápete, jak celé TLS a zabezpečení funguje.

    Nehovořím jen o TLS 1.2, ostatně tam byl dán obrovský čas. Diskutujeme pod článkem o odkazech HTTPS => HTTP, a to je příklad toho nepřirozeného tlaku.

    V diskusi si vypícháváte vždy jen jedno konkrétní téma, ale kontext nechcete vidět. Šedá je odstín černé, ale i odstín bílé.

  • 10. 2. 2020 12:10

    Filip Jirsák

    Už dlouho tu diskutujeme o HTTPS obecně.

    Pro provozovatele webu asi bude jednodušší opravit ty HTTP odkazy než přidávat novou hlavičku, že ty HTTP odkazy myslí vážně. Navíc je to funkce prohlížeče, prohlížeč má chránit uživatele, ne provozovatele webu. Takže pokud by web poslal tu vaši hlavičku, musel by to prohlížeč dát nějak najevo uživateli a ten by to musel schválit. A opět se dostáváme k otázce, zda jsou všichni uživatelé natolik kvalifikovaní, aby to mohli posoudit.

    Já kontext vidím, na rozdíl od vás. Vidím kontext, že nechat rozhodovat uživatele o něčem, čemu vůbec nerozumí, je čirý alibismus, nemá to nic společného se svobodou uživatelů. Také vidím ten kontext, že prohlížeč je nástroj uživatele, má tedy dělat to, co potřebuje uživatel, ne to, co by chtěl nějaký provozovatel webu. Vaše představa, že všichni provozovatelé webů jsou ti hodní, je hezká, ale míjí se s realitou. Ne, mezi provozovateli webů jsou hodní i zlí, a proti těm zlým musí prohlížeč uživatele chránit. A provozovatelé webů se holt musí přizpůsobit tomu, co chtějí uživatelé, tomu, jaké prohlížeče používají.

    Když lidé začali jezdit nakupovat autem, také mohli provozovatelé obchodů nadávat na výrobce aut a vytýkat jim, že nepřirozeně tlačí auta. A nebo se smířili s tím, že lidé jezdí nakupovat autem, a udělali před obchodem parkoviště. Možná někteří zkoušeli mluvit do toho, jak by mělo auto vypadat, aby se to provozovateli obchodu hodilo. Ale měli smůlu. Obchod poskytuje nějakou službu, takže se musí přizpůsobit tomu, co chce odběratel té služby – zákazník. Obchodník bud na požadavky zákazníků přistoupí, nebo může zavřít krám. Stejně je to s weby. Weby poskytují nějaké služby svým návštěvníkům a uživatelům. A ti se rozhodnou používat nějaký prohlížeč, který jim třeba zaručuje větší bezpečnost. Provozovatel webu se může rozhodnout, zda na ty požadavky uživatelů přistoupí, nebo ne. A když nepřistoupí, tak holt uživatelé přestanou jeho služby využívat.

  • 7. 2. 2020 16:42

    Filip Jirsák

    Nebyla by celá ta režie kolem rozhodování provozovatele webu co lze umístit na HTTP a rozhodování prohlížeče co lze stahovat přes HTTP nakonec větší, než režie HTTPS?

    Berte to takhle: nešifrované protokoly jsou relikt, a je potřeba směřovat k tomu, abychom se jich zbavili – ne hledat okrajové případy tvořící miliontiny provozu, ve kterých by stačil i nešifrovaný protokol. Také nemáte v garáži vedle auta zaparkované spřežení s kočárem, protože přece jednou za pět let pojedete na pětiminutovou cestu, kde je auto zbytečné a kočár s koňmi by stačil.

  • 7. 2. 2020 20:28

    Miroslav Šilhavý

    ne hledat okrajové případy tvořící miliontiny provozu, ve kterých by stačil i nešifrovaný protokol.

    Minorita je to jen kvůli tomu, že to Google dost bezohledně vynutil.

  • 7. 2. 2020 22:02

    Filip Jirsák

    Možná by se ta vaše posedlost Googlem dala léčit.

    To, že by nešifrovaný provoz stačil na miliontinu provozu, není nikým vynucené, to je objektivní fakt. Nešifrovaný provoz by stačil pouze na provoz, který je veřejný, tj. každý může vidět na co se díváte i plný obsah, a zároveň je integrita zajištěná jiným způsobem – součástí odkazu je bezpečně předávaný hash a prohlížeč by ten hash při stahování kontroloval. Takže reálně by se to dalo použít leda tak pro stahování nějakého nekonfliktního softwaru, třeba linuxových distribucí. U všeho ostatního potřebujete alespoň integritu přenášených dat a často i šifrování.

  • 7. 2. 2020 22:32

    Miroslav Šilhavý

    Nešifrovaný provoz by stačil pouze na provoz, který je veřejný, tj. každý může vidět na co se díváte i plný obsah, a zároveň je integrita zajištěná jiným způsobem

    Spíš nejsem tak paranoidní, abych zvyšoval "bezpečnost" za každou cenu.

    HTTPS je v současném podání starou belu bezpečné. U naprosté většiny domén získáte heslo do správy DNS tím, že u registrátora vyžádáte zapomenuté heslo a unesete zaslaný mail pomocí nešifrovaného SMTP. S přístupem do DNS získáte certifikát během pár minut (od Let's Encrypt) i s tím, že z DNS znovu odstraníte ověřovací TXT záznam.

    Pokud je potřeba něco na poli bezpečnosti opravdu řešit, tak je to ku příkladu toto. Nejlépe řešit celý SMTP, kterým chodí v poměru daleko víc skutečně cenných informací, a který je děravý jak řešeto. Místo toho se vynucují kraviny, které si mohou poskytovatelé obsahu rozhodovat sami.

  • 8. 2. 2020 11:04

    Filip Jirsák

    Ono to není zvyšování bezpečnosti za každou cenu. HTTPS zvyšuje bezpečnost velmi podstatným způsobem, a cena je naopak velice nízká. Vlastně mne nenapadá jiný případ v dnešním světě, kde by poměr zvýšení bezpečnosti a ceny byl tak výhodný, jako u zavedení HTTPS.

    Nemyslíte, že je trošku rozdíl v tom, jak snadné je unést spojení na poslední míli a jak snadné je unést spojení k poštovnímu serveru? Když pak budete moci přesměrovat DNS na svůj server, budete tam nejprve potřebovat zreplikovat celou původní DNS zónu – ne všechny DNS servery mají povolený přenos celé zóny kamkoli. A když nějaký záznam vynecháte, je dost možné, že váš únos DNS vzbudí pozornost už v okamžiku, kdy bude probíhat. Samozřejmě můžete namítnout, že někdo má DNS hostované přímo u registrátora a heslo bude stačit pro přidání validačního záznamu, aniž by došlo k jiné změně. Ano, někdo to tak má.

    No a pak jste zapomněl na takovou drobnost, že ten vydaný certifikát bude navěky zaznamenaný v CT logu, takže ten svůj útok neutajíte.

    Ale určitě jste si ten příklad nevymyslel, takže buďte prosím konkrétní a popište, jak přesně a u které domény takhle došlo k neoprávněnému vystavení DV certifikátu.

    Ale on je drobný problémek především v tom, že jste vůbec nepochopil, jak funguje bezpečnost. Když si pořídíte a namontujete na dveře bezpečnostní zámek, neznamená to, že by vás ten zámek ochránil před tím, že zloděj do bytu vnikne přes okno nebo otevřené balkonové dveře. Ne, nikdy neexistuje jedno univerzální řešení, které by vás chránilo před jakoukoli hrozbou – vždy musíte každou hrozbu řešit zvlášť. Takže úplně stejně, jako bezpečnostní zámek na dveřích nezabrání vniknutí zloděje oknem nebo otevřenými balkonovými dveřmi, nezabrání HTTPS ani únosu DNS, ani útoku na nezáplatovaný WordPress, ani uhodnutí přihlašovacích údajů admin:admin. Je potřeba řešit každou hrozbu zvlášť.

    SMTP se dávno řeší – nebude se vám to líbit, ale řeší se to šifrováním. Přičemž k největšímu posunu došlo právě v souvislosti s HTTPS. Díky Let's Encrypt je snadné získat certifikát pro poštovní server zdarma, což vedlo k největšímu růstu v nasazování TLS na SMTP servery. Navíc „celý SMTP“ je už bezpečně vyřešený – certifikát zveřejníte v TLSA záznamu, podepsané to bude přes DNSSEC, SMTP klient přes DANE získá informaci, že má povinně použít STARTTLS a konkrétní certifikát. Celé už to funguje, SMTP klienti na rozdíl od prohlížečů DANE nebojkotují. Takže jediný reálný problém je rozšíření. No a předpokládám, že vy budete velmi silně proti tomu, aby někdo na větší rozšíření bezpečného šifrovaného spojení při SMTP tlačil. Takže v SMTP je stav přesně takový, jaký ho vy chcete mít – technologie jsou připravené, stačí je nasadit, a nasazení je na zodpovědnosti konkrétních provozovatelů poštovních serverů.