Názory k článku (Ne)bezpečný e-mail, aneb DKIM, DMARC, DANE a další nejen od D

Že je neúroda jablek taky mohu zdůvodnit tím, že tenhle rok byly divoké bouře na Jupiteru a že je v noci tma taky mohu odůvodňovat tím, že nebe přikryl veliký černý pták. Je mi celkem jedno, co je v jaké diskuzi a co si vy myslíte, že co zdůvodňuje.

Vím co potřebuji, kde to potřebuji, proč to potřebuji a technika je od toho, aby sloužila mně tak, jak chci já. Dost by mě zajímalo, kde vám podobní berou tu drzost vyprávět, co kdo kde potřebuje a proč.

Myslím, že o vás dostatečně vypovídá už to, že odmítáte si ty argumenty vůbec přečíst.

To, že víte co, kde a proč potřebujete, je jen vaše domněnka. A sám dobře víte, že je postavená na velmi vratkých základech – když se bojíte protiargumenty byť jen přečíst.

Ano, odmítám. Protože mám na práci asi tak milion důležitějších věcí než se následující dvě hodiny přehrabovat v diskuzích na rootu jak jste doporučoval vy nebo to řešit kdekoliv jinde což bych jinak dělal já. Takže ano, vypovídá. Že nemám čas na vymýšlení teoretických nesmyslů jako někteří jiní, že?

Své sebeprojekce si, člověče, nechte pro sebe.

Když odmítáte zjišťovat si informace, nedivte se, že pak o tématu nic nevíte. A jenom teoretizujete na základě svých neznalostí.

Sice marne a zbytecne, ale zkusim.

Sifrovat verejne dostupne informace cenu nema, obdobne podepisovat a potvrzovat identitu serveru certifikatem ziskanym na zaklade ovladnuti portu 80 na danem serveru (letsencrypt a ACME obecne). Ohledne validovanych certifikatu, tam zas overovani zneplatnenych je de facto z pohledu bezneho koncoveho uzivatele temer nefunkcni/nes­polehlive.

Jina situace muze byt u statnich organizaci, tam ale zneschopnit e-mail sluzbu podatelny tim, ze nebudu komunikovat s nekterymi verejnymi servery, ktere nesifruji nebo nepouzivaji certifikaty, muze byt (v case se zmensujici) problem.

Nejvetsi prinos povinneho dnssec a pouziti https uplne VZDY a VSUDE popravde vidim jen z pohledu firem typu Google - napriklad prinasi vyrazne ztizeni moznosti podvrhnout zakaznikum misto reklamy Google nechtenou reklamu nekoho jineho, a zabraneni v odposlechu marketingovych dat ziskavanych o koncovych uzivatelich, diky kterym jedine lze dnes tu cilenou reklamu provozovat. Ze stejneho duvodu (a aby organizace podobnou komunikaci nemohly svym uzivatelum blokovat/omezovat ani pri pouziti https desifrace) maji do budoucna nastoupit jeste dalsi vylepseni - konkretne QUIC protokol zalozeny na UDP, a kompilovany binarni obsah web stranek.

Asi neni nahoda, ze Google zijici v podstate vyhradne z cilene reklamy a majici fakticky monopol na poli browseru je soucasne i hlavnim tahounem a propagatorem techto "vylepseni bezpecnosti" a standardu - slouzi jim k zajisteni bezpecnosti vlastniho bussiness, tj dorucovani cilene reklamy a bezpecneho sberu dat o koncovych uzivatelich.

Ohledne dnssec a SPF zaznamu pro postu, tam je to bez diskuze potreba, a to ikdyz SPF muze zpusobit problem pri automatickem preposilani mailu z adresy na adresu v jine domene (kdy prepsat efektivne hlavicky Vam zabrani DKIM).

Ohledne DKIM, mne konkretne spise skodi. Asi dava smysl pro velke cloud poskytovatele, ktere postu masivne hradluji rozsahlou a slozitou serverovou infrastrukturou a chteji snadno overit trust a cestu mezi vlastnimi koncovymi body - typicky o365, gmail atp. Ta nevyhoda pro mne je u antispam reseni - vetsina dnestniho spamu mi chodi prave z ruznych validnich (jenze zneuzitych, anonymnich nebo docasnych) schranek , jejichz validni DNSSEC, SPF, DKIM, DMARC a DANE mi pak akorat pridava falesne "plusove" body a zhorsuje detekci spamu.

Dalsim narustajicim nesvarem je pouziti ruznych URL redirekt sluzeb (obvykle opet za ucelem sledovani uzivatel a marketingovych kampani) pro http(s) odkazy uvedene uvnitr e-mailu - zneuziti pro phishing kampane je u nich pomerne caste. Zacinaj to bohuzel masivne pouzivat i ruzne EU instituce.

Sporne je za mne i vynucovani TLS v SMTP. Posta z principu negarantuje identicke chovani z pohledu sestaveni konkretni transportni cesty, stejne jako negarantuje doruceni ani cas prijeti. Pokud ma byt pouzito sifrovani, pak podle mne vzdy zasadne na urovni OBSAHU mailu - in-transit sifrovani ale dava jen falesny pocit bezpeci prijemci i odesilateli mailu. Provozovatele vsech v komunikaci zucastnenych serveru stejne maji pristup k obsahu.

Certifikat SMTP brany jako overeni jeji identity by daval smysl, jen kdyby neexistoval Letsencrypt (ACME) a spolehlive fungovalo overovani zneplatnenych certifikatu (snad se lepsi), a zpusob sestaveni transportni cesty byl nejak overitelny/vy­nutitelny - coz bohuzel principialne neni/nemusi byt.

Nikdo taky nepíše, že HTTPS má nebo nemá paušálně smysl. Ale je spousta případů užití, kde je HTTPS (a vlastně jakékoliv šifrování i zabezpečení) jen zbytečná komplikace. To je to jediné, co píši.

Takže ano, samozřejmě, že si mohu doma sofistikovaně elektronicky zabezpečit třeba kůlnu se dřevem nebo starý kurník, kde jsou naskládané střešní tašky, ale reálně mi to bude úplně k ničemu a jen mi to komplikuje využití protože ani staré tašky ani dřevo se u nás fakt nekradou případně mají hodnotu limitně se blížící nule.

HTTPS nic nekomplikuje. A je užitečné pro to, aby nemohl komunikaci nikdo číst, měnit a aby uživatel nemusel u každé webové stránky složitě přemýšlet o tom, jestli musí nebo nemusí být komunikace zabezpečená.

HTTPS nic nekomplikuje? Tak teď jste doopravdy pobavil. Spíš marně přemýšlím, jestli je vůbec něco, co nekomplikuje. Navíc internet i to, co je mimo něj se fakt neskládá jen z webových stránek.

Ano, HTTPS nic nekomplikuje. Kdybych já chtěl na některém webovém serveru HTTPS vypnout, musím extra něco nakonfigurovat. Protože ty web servery hned po instalaci ve výchozím nastavení mají HTTPS nakonfigurované. Jediné, co tam zadávám, je e-mail pro Let's Encrypt, kam mohou chodit upozornění – ale i ten je nepovinný.

HTTPS je prakticky povinné ve webových prohlížečích, což jsou webové stránky. Jestli HTTP používáte ve vaší aplikaci mimo web, nikdo vás nenutí tam HTTPS používat. Takže zase jen píšete o věcech, o kterých nic nevíte.

Možná máte jen poněkud omezený rozhled. HTTPs na veřejném bodě je v pohodě a žádoucí, ale HTTPs na interním API může (za jistých okolností, samozřejmě, jinde je třeba) být peklo. Není nad to, když se něco bez varování sesype, protože vyprchal certifikát. A často jde o banalitu, kde fakt šifrování není ani potřeba a kontrola platnosti certifikátu už vůbec ne, ale je tam a nejde vypnout. Pak mi tady vykládejte něco o nezesložiťování.

4. 10. 2022, 16:30 editováno autorem komentáře

Jirsáku, Ty píšeš o povinném HTTPS na serveru, najednou je to na webových stránkách. Tak si vyber. Taky je vidět, že neprovozuješ IoT zařízení, protože tam HTTP server autokonfiguraci TLS opravdu NEMÁ.

Stále je dost zařízení, která třeba nikdy nebudou mít přístup na internet a běhat budou vždy na lokální síti. Pro takové zařízení může být cert management veliký opruz či dokonce překážka. Asi neprovozuješ zařízení, které třeba nemá možnost jak takový certifikát uložit. Vydat certifikát s platností na 10 let je v současnosti problém, stejně tak různé self-signed CA - prohlížeče.

Navíc, opravdu netuším, proč bych měl v ostrovní síti, kam má přístup pouze pečlivě vybraný systém, vše šifrovat. A i kdyby, tak provoz CA pro své domácí potřeby taky něco stojí a protlačovat svoji CA mezi důvěryhodné na všechna zařízení, co spolu mají komunikovat... No super. Jen proto, že si Jirsák myslí, že HTTPS musí být všude.

O povinném HTTPS tu začal psát martinpoljak, to on by si měl rozmyslet, o čem vlastně píše. IoT zařízení provozuju a žádný problém s HTTPS tam nemám. Pravděpodobně to bude tím, že se k tomu zařízení nepřipojuju z webového prohlížeče. A pokud vím, není žádná povinnost, že každé zařízení, které lze připojit do sítě, musí mít vlastní webový server a musí nýt přímo dostupné z prohlížeče.

Já zase netuším, proč v ostrovní síti, kam má přístup jen pečlivě vybraný systém, provozujete webový prohlížeč, kterým pak lezete na Root a do banky. Myslím si, že v takové pečlivě střežené ostrovní síti nemá webový prohlížeč používaný pro běžný web co dělat.

HTTPS musí být všude na webu, protože bez toho nejde udělat web alespoň minimálně bezpečný.

Co máte pořád s tím prohlížečem a webovým serverem? HTTP(s) se používá na podstatně víc věcí, než jen komunikace prohlížeč-> (veřejný) webový server...

Bel Shamharoth: A kde přesně mimo prohlížeče je HTTPS "povinné"?

Tedy vaše odpověď mě docela pobavila. Zcela očividně netušíte, o čem mluvíte.
Jednou věcí, které HTTPS značně komplikuje jsou proxy. Takže například pro HTTP streaming je (při správně nastavených proxy) HTTP podstatně méně náročné na přenosovou kapacitu v případě, kdy několik lidí kouká ze stejné sítě. Ostatně třeba zde na rootu byl článek, který rozebíral standard, který vznikl, protože HTTPS nic nekomplikuje...
https://www.root.cz/clanky/signed-http-exchanges-sxg-oddeluje-zdroj-webu-od-distributora/
Další věci, které HTTPS trochu komplikuje, jsou ruzné IoT a embeded systémy. Nevím, jestli si to dovedete představit, ale HTTP se dá implementovat i na 8-mi bitovém mikrokontroléru s 2KB RAM.
A jako perlička, s počítačem, kde máte o pár let špatně nastavené hodiny, tak se nedostanete ani na google, abyste si našel a stáhl nástroj na seřízení hodin :-)

Ne, HTTP streaming proxy nijak nepomůže, protože při streamingu stahuje každý něco jiného. Proxy by teoreticky pomohlo při stahování běžných souborů. Jenže to musí nastat ta vzácná situace, že jde o soubor, který má proxy v cache a požaduje ho někdo jiný za tím proxy serverem. Už spoustu let se takovéhle proxy servery nepoužívají, protože to nemá žádný význam. Užitečné to bylo v době dial-upů a začátků ADSL.

Odkazovaný článek není o tom, že by něco HTTPS komplikovalo. Je naopak o tom, že je potřeba zaručit integritu přenášených dat.

Netuším, proč by IoT a embeded systémy měly být přímo dostupné z webového prohlížeče.

Škoda, že nebyly internetové diskuse v dobách, kdy se z děrných štítků přecházelo na magnetická média. Že nejsou zachovány ty nářky, jak je to úplně špatně, protože na děrný štítek si lze psát i poznámky a lze jej nouzově použít také v případě, kdy dojde toaletní papír.

Pokud to nechápete – nástroj má dobře sloužit k tomu, k čemu je navržen. To, že vy ho používáte k něčemu jinému, co nebude fungovat s vylepšenou verzí toho nástroje, je váš problém.

Netuším, proč by IoT a embeded systémy měly být přímo dostupné z webového prohlížeče.
Protože na nich běží http služba pro monitoring a nastavení?

Člověče, vždyť vy vůbec nevíte, o čem to píšete.... Já nemluvím o nějakém hypotetickém případě, kdy by to nefungovalo, ve světě, který jste si vymyslel. Já mluvím o něčem, co (na rozdíl od vás) znám z praxe, kde takové systémy provozujeme.
HTTP streaming funguje tak, že se zdrojové video rozdělí na malé kousky a ty se servírují normálně po HTTP(s). Každý klient si pak pravidelně stahuje playlist a jednotlivé kousky. Ty kousky jsou pro všechny stejné. Rozumím tomu, že chcete zpochybňovat vše, čemu nerozumíte, ale takto fungují takové okrajové služby jako Twitch a Youtube. A dokonce mají celé mechanismy a algoritmy, jak přesouvat kousky videa co nejblíže klientům.
A HTTPs přichází se dvěma komplikacemi.
1) se musí každý kousek videa šifrovat pro každého klienta zvlášť, což netriviálně zvyšuje zátěž serveru - možná víte, že šifrování stojí nějaký výpočetní výkon. Toto dnes naštěstí není takový problém, protože i bez různých akcelerací je výkon CPU dostatečný. Ale pořád je šifrování řádově pomalejší, než přehazování dat mezi pamětí - bez HTTPs bylo možné na nevýkonném VPSku nebo třeba Raspberry PI udělat lokální uzel pro netriviální množství kientů....
2) pokud více klientů kouká ze stejné sítě, tak bez TLS můžou využít systém proxy - kterážto se poměrně často používá právě v případech, kdy hodně lidí používá stejné zdroje. Například ve velkých institucích. Ale samozřejmě podle vás je to nějaká technologie z dob ADSL.... Tím pádem se sníží zátěž linky dané instituce, protože ty objemné kousky videa se stahují pouze jednou. A to je přesně ten problém, který se snaží řešit mnou odkazovaný článek. Kousky videa se zabezpečí jednou a pak se doručí transportem, který nevyžaduje další šifrovaní, ale za to umožňuje stále využívat všechny výhody HTTP.... Ona matematika je prevít a nenechá se přesvědčit naivními nerealistickými názory.... Pokud mám stream, který má 5MBit/s a kouká na něj 500 lidí, tak potřebuju minimálně 500x5MBit/s, což je 2.5GBit/s. Tedy za předpokladu, že není možné využít nějakého principu "jedny data po jedné lince pouze jednou".
A co se týče těch IoT zařízení. Možná to nevíte, ale protokol HTTP je velice snadný na implementaci, takže se často používá na základní administraci zařízení nebo low level komunikaci. Ono i pokud máte hodně omezené prostředí (pamět a CPU výkon), tak se docela snadno napíše kód typu if received_data == "GET /status" then send("alles gutte").... A právě výhoda byla, že na straně klienta nepotřebujete žádný speciální nástroj/program, ale vystačíte si s běžným prohlížečem.
Samozřejmě to, že takový systém musí být zabezpečený jiným způsobem (například oddělená síť, filtrování na firewallu,....) aby nebyl dostupný z Internetu, to je zřejmé.
Ostatní vaše nápady, výpady a odpady nemá smysl ani komentovat.

Radek Hladík: Mýlíte se. Youtube nikdy nebylo založené na tom, že by posílalo data přes HTTP a cachovaly je proxy servery po cestě. Kdybyste se podíval na to, co Youtube posílá, zjistil byste, že tam jsou hlavičky, které nastavují nulovou dobu platnosti a zakazují kešování veřejným serverům.

Ta teorie o lokálním uzlu pro netriviální množství klientů je sice hezká, ale nějak jste zapomněl zmínit, jak byste zařídil, aby těm klientům někdo nepodstrčil svůj vlastní obsah.

Nechápu, proč opakujete ty nesmysly o proxy serveru, když už jsem vám napsal, že lidé stejný obsah dávno nekonzumují. Jenom teoretizujete a asi jste nikdy žádný proxy server neprovozoval, jinak byste věděl, že míra cache hit byla už dávno tak nízká, že se nevyplatilo proxy server kvůli cachování provozovat, protože ušetření přenosového pásma bylo neměřitelné.

Máte pravdu, žádný proxy server jsem nikdy neprovozoval, lidé stejný obsah nekonzumujou, lokální uzly nedávají smysl a všecko jsou to nesmysly....
Jediné, co mne utěšuje, je, že nám za implementaci těch nesmyslů naši zákaznici platí :-)

Radek Hladík: Že lokální uzly nedávají smysl jsem nikdy netvrdil. Lokální uzly ale nemají s HTTPS žádný problém. Zkuste se někdy podívat na stránky jako Google nebo Youtube – jejich obsah dostáváte z lokálních uzlů. A budete překvapen, ale dostáváte to po HTTPS. Podobně dostáváte spoustu dalších stránek a a ni o tom nevíte.

Ano, lidé stejný obsah nekonzumujou. Sice jdou všichni na Facebook nebo Twitter, ale tam má každý svou personalizovanou stránku. Pak jde jeden na Novinky, jeden na Aktuálně, jeden na Aeronet, každý tam má svou personalizovanou stránku a dostane svou personalizovanou porci reklamy.

Pokud byste měl velkou síť s tisíci uživatelů, občas by se možná trefil nějaký obrázek k článku, ale kvůli tomu nemá smysl ukládat gigabajty procházejících dat na proxy serveru s tím, že se možná pár kilobajtů použije znovu a nebudou se muset stahovat z původního serveru. Navíc uživatelé nechtějí, aby kde kdo věděl, co na internetu čtou – takže to, že zpravodajské servery jedou přes HTTPS, je záměr, je to tak správně a nikoho nezajímá, že vy byste chtěl nakešovat v lokální síti tři obrázky pro dva uživatele, abyste tím "ušetřil" pásmo na gigabitových linkách.

Jsem rád, že vy víte, co já nevím :-)

Radek Hladík: Dobře, upřesním to – možná to ve skutečnosti víte, ale v diskusi to úspěšně maskujete a předstíráte, že to nevíte.

Každopádně kdybyste provozoval kešující proxy v koncové síti, jistě by nebyl problém vytáhnout statistiku, jak velký je objem nakešovaných dat, jaký je podíl dat použitých z cache a kolik procent trafficu se tím ušetří.

No, nerikal bych ze HTTPS nic nekomplikuje. jakakoliv kryptografie je vypocetni vykon navic. Ale kvuli bezpeci a soukromi se to zaplati.

To by se ovšem muselo upřesnit, oproti čemu ten výpočetní výkon "navíc" počítáte. Pokud by mohl někdo dovnitř přenášených stránek přidávat svou šílenou reklamu, bude tam zase výpočetní výkon navíc na tu reklamu, například.

No jistě. Proč to dělat jednoduše když to jde i složitě. Přece nebudu tak staromódní abych pro přístup k zásuvce na lokální síti používal jen trapné HTTP když to přece mohu desetkrát zkomplikovat.

Jasně, protože je přece úplně super, když vám tu zásuvku může vypnout i soused, který je možná v té vaší "lokální" síti také, akorát o tom nevíte.

Představa, že mi soused vypne zásuvku je naprosto katastrofální. Zejména ve srovnání s banalitou, že ta zásuvka nepůjde ovládat, protože tam vyprchá certifikát nebo je použita zastaralá šifra/hash. To se navíc ani stát nemůže, protože přeci ty zásuvky měním 10x ročně.

Proč by tam měl vyprchat certifikát? Proč by tam měla být použita zastaralá šifra/hash? Proč byste se vůbec měl připojovat webovým prohlížečem přímo k zásuvce? Pro mě za mě si s tou zásuvkou komunikujte třeba přes děrné štítky, když to považujete za dobrý způsob.

Díky za krásný příklad kam může https posedlost dospět. Možný kompromis by mohl být, kdyby měl výrobce vlastní certifikáty podepsané na 100 let, ale to by nesměl být posedlý. Ale představa, že bude někdo obnovovat certifikáty všech zařízení každý rok nebo tři měsíce je úchylná.

Co má chybně řízená výměna certifikátů společného s HTTPS? Víte o tom, že protokol HTTPS vůbec neřeší to, jakou platnost mají mít certifikáty a co jsou zač? Je jen na klientovi, jak se rozhodne, kterému certifikátu bude důvěřovat. Jaká posedlost podle vás výrobci zabránila mít tam certifikáty s platností sto let? Vaše posedlost proti HTTPS?

Všiml jste si, že se ten původní protokol nahrazoval proto, že nebyl bezpečný? Vy považujete protokol HTTP za bezpečný?

Ono často ale bývá často důležitější to, aby bezporuchově fungovalo, než čísi falešný pocit bezpečí. Chybná úvaha už může být v tom, že někdo bude to výměnu každý rok provádět. Nebude a udělá to velké škody.
Představte si třeba VoIP operátor co má 10000 zákazníků by pak musel všem svým zákazníkům každý rok vysvětlovat, jak si nahrát nový certifikát, aby se dostal na webové stránky telefonu.

Otázka je, jestli něco může bezporuchově fungovat, když to může ovládat úplně každý.

Chybná úvaha je především to, že se vůbec snažíte uvažovat o HTTPS, když o něm vůbec nic nevíte. Certifikát není potřeba každý rok měnit. Až si to dostudujete, můžeme o tom dál diskutovat.

Je mě jasný, že certifikát není třeba měnit každý rok. Je to jen případ kam může a vede když to někdo bere z "bezpečnostní" příliš bezhlavě.

Kdyby jste zařízení řídil na dálku pře relátkami, také vám to může někdo hacknout tím, že se vám k tomu připojí a bude vydávat signály a nikomu to bezpečnostní riziko nepřijde.

Ad řízení relátky – ale samozřejmě, že se to jako bezpečnostní riziko vyhodnocuje. A vyhodnocuje se to komplexně – jak velké je riziko toho napadení, jaké by to mělo důsledky, jaké jsou náklady na ochranu.

5. 10. 2022, 19:55 editováno autorem komentáře

Mohu se jen domýšlet, že změna protokolu byla prosazena z těch bezpečnostních důvodů, které (často) uvádíte. Jen někdo nedomyslel, jak si s výměnou certifikátů poradí (relativně hloupá) zařízení typu tenký terminál (thin client). Pokrok nelze zastavit.

Předpokládám, že ty tenké terminály fungovaly jako HTTPS klienti. Takže stačilo nahrát tam certifikát certifikační autority, který by měl platnost třeba dvacet let. A nejspíš u něj na platnosti ani nezáleželo – je pravděpodobné, že by ten klient platnost certifikátů důvěryhodné CA vůbec nezjišťoval. A pak už by stačilo jenom jednou za rok vyměnit certifikát na serveru – nový certifikát by byl vystaven tou samou certifikační autoritou. Nebo by i ten serverový certifikát mohl mít platnost třeba dvacet let – ale to by z mého pohledu bylo horší, protože by hrozilo, že se na to zapomene. No a kdyby se blížil konce platnosti certifikátu CA, tak by se prostě vystavil nový certifikát se stejným klíčem.

Zkrátka to nebyl žádný problém s protokolem HTTPS, jenom prostě někdo nezvládl základní správu certifikátů.

Při snaze o různé způsoby přeposílání mailů, nasazení listserverů nebo nějakého jiného produktu, který v konečném důsledku přeposílá maily nebo manipuluje s adresami jejich odesilatelů a adresátů (ať už v záhlaví nebo smtp obálce) zjistíte, že kvůli DMARC je nejlepší, když od vás odcházejí maily, které mají všude včetně DKIM domény uvedeného totožného odesilatele/doménu.

Takže uvedete nějakou "vlastní" adresu a podepíšete svým DKIMem.