Názory k článku
Chrome bude od verze 83 blokovat některá stahování po HTTP

Rozhodně může existovat situace, kdy bude nutné v uzavřeném prostředí HTTP použít. Jen ten výše uvedený příklad mi příliš smysl nedává. Zkuste vymyslet konkrétní situaci, kdy jsem nucen po HTTP stahovat z takto omezeného (embedded) zařízení uvedené typy souborů (exe, zip a podobně).

Tak já neměl na mysli zrovna embedded, ale spíš sloní mašiny, HPC a sálovky, kde jsou různé Unixy a SSL je bez podpory, resp. jen na obtíž, a s takovým železem děláte v enterprise SI skoro výlučně. To je jedno. Primárně se mi prostě nelíbí, že by takovou věc měl browser tvrdě blokovat, když varování umožňuje uživateli obě alternativy.
PS: Já bych Chrome nepoužil ani za nic, takže to je snad jedno. Jen aby se toho zas nechytli všichni. :)

7. 2. 2020, 14:09 editováno autorem komentáře

Zkuste vymyslet konkrétní situaci, kdy jsem nucen po HTTP stahovat z takto omezeného (embedded) zařízení

Spousta lokálních aplikací - intranety, malé i větší systémy, kde je HTTPS k ničemu. Zabezpečení reálně nezvyšuje, ale zavést ho všude je složité. Složité to může být ze spousty důvodů - už jen kvůli certificate enrollmentu, nebo chybějící podpoře SSL (nebo ve staré verzi). Přinese to další náklady na zřízení i na maintenance takových prkotin.

Bohužel, nemůžu se ubránit dojmu, že Google dlouhodobě dělá kroky vedoucí k tomu, že malé firmy usoudí, že levnější, než si něco tvořit a spravovat je přejít do čmoudu. Přitom ale ta nákladnost je vytvořena uměle.

Jenže v takovém prostředí není HTTPS ani na těch strankách a žádný problém nevzniká. Tohle není správný argument.

Zkuste vymyslet kombinaci „web sice zobrazujeme po HTTPS, ale soubory vám ke stažení musíme nabídnout jen po HTTP“. Protože tohle je jediná kombinace, které se tahle zprávička týká.

Zkuste vymyslet kombinaci „web sice zobrazujeme po HTTPS, ale soubory vám ke stažení musíme nabídnout jen po HTTP“. Protože tohle je jediná kombinace, které se tahle zprávička týká.

Přechodová doba a cesta mezi HTTP a HTTPS. Nové systémy často už vznikají na HTTPS by design, ale musí zahrnovat podporu i těch starých.

Podívejte, když začaly prohlížeče blokovat vyskakovací okna, nejdřív byl warning, ale dodnes je zobrazena ikona, pomocí které se dá pro daný web funkce zpět zapnout. Myslím, že některým vadí přístup Googlu v tom, že teď nedává žádnou takovou (rozumně ovladatelnou) možnost. I prastarému flashi dal daleko větší přechodovou možnost.

Myslím, že některým vadí přístup Googlu v tom, že teď nedává žádnou takovou (rozumně ovladatelnou) možnost. I prastarému flashi dal daleko větší přechodovou možnost.
Četl jste zprávičku, pod kterou diskutujete? Jak si vykládáte slovo „postupně“ v druhé větě? Jak si vykládáte tabulku na konci zprávičky?

Vyskakovací okna jsou jen komfort, stahování souborů přes HTTP je bezpečnost. Kdo dokáže posoudit, zda pro něj stahování souboru přes HTTP je nebo není bezpečné, umí si to blokování v prohlížeči vypnout. A pokud jde o nějaký podnikový informační systém, tam to může pro ten systém vypnout správce pomocí politiky.

Kdo dokáže posoudit, zda pro něj stahování souboru přes HTTP je nebo není bezpečné, umí si to blokování v prohlížeči vypnout.

Laik (uživatel) to posoudit nemůže.

Má to posoudit provozovatel webu. Jeho obsah, jeho odpovědnost.
Super by bylo toto chování nastavovat hlavičkami na serveru. Kdyby Google vydával aktualizovaný seznam doporučených nastavení zabezpečení, usnadnilo by to správcům a motivovalo by je to zavádět. Ale i dalo možnost usoudit, co je a co není bezpečné.

Prohlížeč nemůže starost o bezpečnost koncové stanice přenechat v rukou provozovatelů webu. Jeho úkolem je naopak chránit uživatele navzdory problémům jednotlivých serverů.

V současné situaci umožní špatné rozhodnutî správce webu vyměnit při přenosu obsah stahovaného souboru a uživatel to nijak nezjistí. Stránka s HTTPS všechen zobrazovaný obsah získává bezpečným kanálem. Proč by to mělo být u stahování jinak?

Prohlížeč nemůže starost o bezpečnost koncové stanice přenechat v rukou provozovatelů webu. Jeho úkolem je naopak chránit uživatele navzdory problémům jednotlivých serverů.

Historicky je mnohokrát ověřeno, že jakákoliv regulace funguje krátkodobě pozitivně a dlouhodobě negativně. Navíc svádí k tomu regulovat víc a víc, až se ztratí pojem o tom, co je rozumná hranice. Níže Filip píše, že HTTP je minoritní - a to je přesně ten příklad posunutí hranic. HTTP nebylo minoritní do doby, než Google začal HTTPS de facto vynucovat. Vynucený stav ale už v očích některých povýšil na standard.

Prosím uvědomme si, že "standard" není zákon. Standard je jen kodifikace stavu, který už existuje. Účelem standardů není hnát vývoj dopředu, ale pouze pomoc udělat pořádek v určité oblasti.

U Googlu je navíc docela podstatné riziko, že to velkou měrou slouží jejich obchodním zájmům. Google dokáže změřit co děláme, na co se chceme koukat a co poslouchat. A že by ten samý Google neuměl své kroky s Chromem spočítat ve svůj prospěch?

Musím ale uznat, že to mají vymyšlené hlavou. Uživatel chce "bezpečí" (ať už se za tím skrývá cokoliv). Technici, geekové mají technologické novinky rádi a pomáhají je prosadit (jsou to pěkné hračky pro velké kluky - myslím vážně). Bohužel, ti, co to platí (miliony malých firem, podnikatelů, jednotlivců) se k tomu nemají jak vyjádřit, protože v technických otázkách nemohou oponovat.

Historicky je mnohokrát ověřeno, že jakákoliv regulace funguje krátkodobě pozitivně a dlouhodobě negativně.
Třeba s tím, že se na silnicích jezdí vpravo, teď máme velké problémy – a bylo by mnohem lepší, kdyby to bylo neregulované a každý by si jezdil, kudy by chtěl.

Bývá vhodné vycházet z faktů a na jejich základě si udělat názor. Pokud máte nejprve názor, o něj opíráte svá tvrzení a je vám úplně jedno, zda ta vaše tvrzení jdou nebo dojdou dohromady s fakty, je to cesta do pekel.

Laik (uživatel) to posoudit nemůže.
Kdo dokáže posoudit, zda pro něj stahování souboru přes HTTP je nebo není bezpečné, umí si to blokování v prohlížeči vypnout.

Ale to už jsem psal, ne?

Má to posoudit provozovatel webu. Jeho obsah, jeho odpovědnost. Super by bylo toto chování nastavovat hlavičkami na serveru.
A k čemu by to celé bylo dobré? Myslíte, že tím, že někomu dáte tisíce nesmyslných možností, zvětšíte jeho svobodu?

Kdyby Google vydával aktualizovaný seznam doporučených nastavení zabezpečení, usnadnilo by to správcům a motivovalo by je to zavádět.
Třeba by o tom mohli psát na blogu, mohli by mít přehled toho, co se chystá do které verze. Aha, ale to Google má. Akorát že vy to nesledujete, dozvídáte se o změnách až ze zpráviček na Rootu, a pak jste rozhořčen, že vás nikdo neinformoval.

Ale i dalo možnost usoudit, co je a co není bezpečné.
Laik (provozovatel webu) to posoudit nemůže.

> Spousta lokálních aplikací - intranety, malé i větší systémy, kde je HTTPS k ničemu.

To může za určitých podmínek platit zhruba do chvíle, kdy všichni používají výhradně ethernet nebo vyjmenované a dobře zabezpečené Wi-Fi. Jakmile se jednou třeba na služební cestě ve vlaku připojíte na Wi-Fi poskytovatele, může se to snadno sesypat. Vizte cache poisoning a Wi-Fi Pineapple.

A taky to předpokládá dobře zabezpečenou samotnou síť. Od fyzické bezpečnosti, přes ochranu proti útokům jako ARP poisoning, až po dobře zabezpečené síťové prvky (s dobrým heslem/klíčem admina a aktualizovaným firmwarem).

Neříkám, že se nikde nemohou potkat různé zmiňované podmínky, aby HTTPS bylo fakt k ničemu. Ale IMHO mnohem častěji půjde o podcenění rizik.

Pokud se na služební cestě připojím na Wi-Fi poskytovatele, tak se samozřejmě do interní firemní sítě nepřipojím, pouze přes VPN.

L.: Nepřipojíte se úspěšně do firemní sítě. Ale jste si jist, že když se vám nepodaří navázat VPN spojení, nebo v průběhu práce vypadne, že nemohou data uniknout mimo VPN?

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ě?

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.

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čí.

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…

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.

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

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.

> 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?

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.

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í.

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č.

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.

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.

@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?

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.

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é.

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.

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ů.