Vlákno názorů k článku Velká část e-mailů putuje internetem nešifrovaně. Kdo to změní? od Miroslav Šilhavý - Pro poskytovatele poštovních služeb, zejména pro ty menší,...
-
Pro poskytovatele poštovních služeb, zejména pro ty menší, to bude zavádění povinného (ehm, řekněme, "povinnějšísho" - to je slovo) šifrování velký problém.
Koncový uživatel není připravený na diskusi typu "máte špatně nastavený program", nebo "používáte nesprávný port", nebo "e-mail pro Vás nepřišel, protože druhá strana nepodporuje TLS". To všechno jsou témata, se kterými uživatel nic udělat neumí nebo mu musí dát nějaký technik podporu. V první řadě to odnesou technici na straně ISP příjemce (interní IT, ISP, poskytovatel pošty), ale k odesilateli a jeho technikům, kteří drží v ruce klíč, se problém prakticky nedonese.
Pokud by něco opravdu pomohlo, pak by to byla nějaká signalizace stavu směrem k odesilateli a jeho technikům. Pokud by odesilateli čas od času přišlo uporoznění, že má chybně nastavenou svoji stranu, byla by to aspoň nějaká stimulace tam, kde problém začíná.
Dnes to vypadá takto:
Příjemce: "Nedošel mi od Vás e-mail".
Odesilatel: "To je divné, mně vše funguje, píšu si se spoustou lidí".
Příjemce: "Mně taky e-maily chodí".A tady je bod zlomu: na místo toho, aby to jeden nebo druhý začal řešit s technikem (a mělo to aspoň jakous takous šanci na zlepšení, přijde toto:
Příjmce: Tak mi to zkuste poslat na soukromý e-mail.
Odesílatel: Dobře, tak já to také zkusím ze soukroméhoPak se podívám do zdejších fór a vidím, jak se o rozchození poštovního serveru snaží ti, kteří si zjevně nepřečetli o internetové poště ani řádek. SPF a DKIM jsou termíny z jiné dimenze. Řešení certifikátu pro zabezpečení pošty? Zcela mimo možnosti, v nejlepším případě tam hodí vzorový certifikát z distribuce OS, který mají. Až pochopí, jak TLS funguje, na místo toho, aby získali důvěryhodný certifikát, začínají lidem distribuovat svoje CA mezi důvěryhodné...
...takže výsledkem takové snahy, to je co chci říct, bude opět to, že vymře základní třída poskytovatelů (čehokoliv), tím pádem za pár let nebude ani kdo by tvořil střední stav...
Jestli by zde něco pomohlo, tak by to bylo zavedení:
1. motivace, aby každá doména měla definovaného mailmastera,
2. aby přes whois informace a přes mailmastera byl tento čas od času upozorňován na to, jaké má prohřešky proti ideálnímu stavu,
3. aby správně nastavená pošta byla bonifikována na poštovních serverech.Současný stav a návrhy vývoje povedou jedině k tomu, že všichni budeme (přeháním) brzy na GMailu a O365, uživatele nebudou zajímat důvody, a malí ISP budou bez zakázek.
-
Ondřej CaletkaZlatý podporovatelRád bych zdůraznil, že celý dokument RFC 8314 se týká výhradně předávání pošty mezi MUA a MDA/MSA, čili spojení uživatelského poštovního klienta se serverem, kde je vedena schránka a se serverem, přes který je předávána odchozí pošta. Čili jde o místa, kde se šifrované spojení používá zcela rutinně a navrhovaný standard pouze klade důraz, aby se podobný přístup uplatňoval i pro SMTP a hlavně, aby poštovní klienti i servery ve výchozím stavu neumožňovali nešifrované spojení. Standard tedy nevynucuje šifrované předávání zpráv mezi MTA.
Koncový uživatel není připravený na diskusi typu "máte špatně nastavený program", nebo "používáte nesprávný port"
Domnívám se, že přesně na to připravený je. Pokud bude mít program špatně nastavený, nedostane se ke své schránce a/nebo pokus o odeslání jakékoli zprávy skončí chybou.
-
Domnívám se, že přesně na to připravený je. Pokud bude mít program špatně nastavený, nedostane se ke své schránce a/nebo pokus o odeslání jakékoli zprávy skončí chybou.
Ano. A hned v druhém kroku otevře gmail.com, outlook.com, ..., a na místo řešení dojde k další fázi superglobalizace trhu. Že by BFU, nebo mrňavá firma (< 15 PC) volali nějakého IT, to je poměrně sen. IT s tím také nic nenadělá, pokud zjistí, že je problém na druhé straně.
Proto jsem spíš pro zavádění pozitivní motivace. Splníš = naše spam filtry to přičtou k dobru.
-
Ondřej CaletkaZlatý podporovatel
Tohle je nesmysl. Dotaženo do extrému, když uživatel zadá nesprávné heslo, stejně mu jeho poštu ukážeme, protože se asi překlepl a přece ho nebudeme demotivovat. ;)
Pokud uživatel chce používat poštovního klienta, musí si ho správně nastavit*. Je odpovědností správce poštovního serveru, aby blokoval pokusy o čtení pošty s nízkou úrovní zabezpečení (bez šifrování nebo se slabým šifrováním). Pokud uživatel nastavení poštovního klienta nezvládne a radši uteče ke cloudovým službám, pak je otázka, co ho vůbec motivovalo k instalaci poštovního klienta, protože cloudová řešení jsou prostě víc sexy.
*) Nebo musí být správně nastavený z výroby, případně musí být schopen zjistit správné nastavení už z e-mailové adresy (i na to už jsou protokoly).
-
Petr StehlíkZlatý podporovatelOndro, to jsi popsal řekl bych "akademické prostředí". V ISP firmách to takto opravdu fungovat nemůže. Např. já jsem ten, komu by volali klienti, kdybych zakázal nešifrované odesílání pošty, a když bych jim řekl "máte to blbě nastavené", tak by vzápětí volali mému šéfovi a dali by mu vybrat: buďto si to U NÁS spravíme (tj. povolím zpět nešifrované spojení), anebo nám dají výpověď a jdou jinam, kde jim bude "pošta fungovat". Bohužel.
-
Ondřej CaletkaZlatý podporovatel
Diskutují takhle zaměstnanci o každém požadavku vedení? Protože požadavek na aspoň základní zabezpečení předávané pošty by měl přijít od vedení. Tvoje role je v tom, informovat vedení o (zcela zbytečném) ohrožování bezpečnosti e-mailové komunikace. Buďto to vedení uzná jako problém a zjedná nápravu, nebo to pro vedení není problém a pak je volba, zda zůstat, nebo jít na tobě.
Dokonce bych řekl, že tady je ten problém ještě jednodušší o to, že je možné předem přesně zjistit, kdo má špatně nastaveného klienta a zjednat u něj nápravu ještě předtím, než bude zavedeno příslušné bezpečnostní opatření.
-
Petr StehlíkZlatý podporovatel
Zaměstnanec? Tohle přece není o zaměstnancích, ale o klientech. Máme tisíce klientů, kteří netuší nic o IT. Když jim napíšu "zapněte si šifrování", nebudou vědět kde a jak. Nemůžu je objíždět jednotlivě a nastavovat jim to, za to nás nikdo nezaplatí. Obávám se, že si nerozumíme, když argumentuju vlastní pozicí v maličké firmě. Zkusme si to proto představit ve větším měřítku: řekněme, že T-Mobile má zcela nepodloženým odhadem 2 miliony klientů, kteří využívají jeho SMTP server "zdarma" (v ceně připojení). Pokud by T-Mobile vynutil šifrování pro poštovní klienty klientů, tak z těch 2 milionů třeba 400 tisíc klientů zjistí, že jim nejde odesílat pošta. Co v takovou chvíli může T-Mobile dělat? Má vyslat 50 tisíc techniků, kteří budou jeho klienty objíždět a osobně jim to nastavovat? Nebo má říct těm 400 tisícům lidí, ať si seženou vlastního ajťáka, co jim to nastaví? Co by se asi stalo, až by 400 tisíc klientů pohrozilo odchodem k O2, kde "pošta chodí"?
-
Ondřej CaletkaZlatý podporovatel
Jo tak. No u vztahu provider - klient je vždycky otázka, jaká je situace na zbytku trhu. K takovýmhle velkým změnám už v historii docházelo a určitě docházet bude. Obykle se to řeší podle míry naléhavosti buď hromadným e-mailem s ultimátem, nebo třeba jen úpravou návodu pro nové klienty a čekáním, až ti staří vymřou. Pokud budou obdobné opatření zavádět i ostatní ISP, stejně klient nemá na vybranou a musí si to správně nastavit.
No a když je daný ISP dostatečně velký, jednoduše změnu provede, protože ví, že jeho zákazníci stejně nemají kam utéct. To ale rozhodně není žádoucí stav trhu ;)
-
Kkt1 (neregistrovaný)
Tyhle zmeny se ale daji planovat treba 2-3 roky predem, klient si koupi treba novy telefon a uz ho mohu upozornit ze nastaveni ktere mel je neaktualni a je nutne ho zmenit. Zpusobu osloveni klientu jsou tisice, klidne to muzete prodat i v reklame. Po 3 letech vam zustane marginalni pocet klientu. Nikdo tohle ale neresi, protoze za tim neni byznis.
-
Tohle je nesmysl. Dotaženo do extrému, když uživatel zadá nesprávné heslo, stejně mu jeho poštu ukážeme, protože se asi překlepl a přece ho nebudeme demotivovat. ;)
Nikoliv. Bavíme se v intencích toho, že dnes je nějaký stav, který chceme zlepšit, ale nechceme ho zhoršit. Zlepšení chceme realizovat na poli bezpečnosti, ale nechceme bezpečnost ani zhoršovat (příklad ad absurdum s heslem) a nechceme ani zhoršovat použitelnost.
Pokud uživatel chce používat poštovního klienta, musí si ho správně nastavit*. Je odpovědností správce poštovního serveru, aby blokoval pokusy o čtení pošty s nízkou úrovní zabezpečení (bez šifrování nebo se slabým šifrováním). Pokud uživatel nastavení poštovního klienta nezvládne a radši uteče ke cloudovým službám, pak je otázka, co ho vůbec motivovalo k instalaci poštovního klienta, protože cloudová řešení jsou prostě víc sexy.
Jenže ti cloudoví poskytovatelé na to také prdí. Přijímají nezabezpečeně přenesené zprávy. Takže to dopadne tak, že malý provider nebo firemní správce nastaví vynucené šifrování. Ale na místo toho, aby něco zlepšil, utečou mu uživatelé ke cloudu, kde bude mít POCIT bezpečí, byť to bude technicky možná hůř zabezpečené.
Proto, jsem o tom skálpevně přesvědčený, je nutné POZITIVNĚ motivovat uživatele, aby po takové službě vznikla poptávka. Pokud Outlook odmění uživatele za jeho pečlivost tím, že najednou začne vidět bezpečně přenesené zprávy zeleně, stane se to pro lidi věcí jaké si prestiže, soutěže, kdo to zaimplementuje také.
Bohužel, velcí k tomu nejsou motivováni. Ve skutečnosti Google či Microsoft nemají vůbec zájem o celkovém snížení spamů i fraudů. Jim jde hlavně o tom, aby ONI měli těchto zpráv co nejméně, ale TEN DRUHÝ co nejvíce. Kdyby měli přispět k "obecnému blahu", seberou si konkurenční výhodu.
-
Ondřej CaletkaZlatý podporovatel
A zase do toho mícháte předávání pošty mezi MTA, což je úplně jiný příběh.
Když se vrátím k tématu zabezpečené komunikace MUA a MDA/MSA, tak všichni cloudoví poskytovatelé, které znám, v tomto místě TLS vynucují už velmi dlouho, ať už jde o TLS při POP/IMAP/Submission přístupu, nebo HTTPS při použití webmailu.
Proto je argumentace pro povolení i nešifrované varianty uvedených protokolů na privátním/firemním serveru tím, že jinak by uživatelé utekli do cloudových služeb, jasně falešná.
