"velká část pošty putuje internetem v otevřené podobě nebo s velmi slabým zabezpečením."
Zdroj tohoto tvrzeni? Ve zminovanem RFC jsem nic takoveho nenasel.
To vychází z nastaveného principu. Šifrování je navržené jako volitelné. Stačí tedy, aby jedna strana nepodporovala, nebo aby kdokoliv po cestě narušil komunikaci, a obě strany sklouznou k využití nešifrovaného kanálu. Opravdu jen málokdo má "koule" na to zakázat na své straně nešifrované přenosy pošty, protože by určitou část pošty nedostal a neodeslal.
On je tenhle pristup taky jednim z primarnich duvodu, proc emaily proste fungujou.
Az zacne nekdo resit, jestli ta ci ona protistrana pouziva to ci ono sifrovani (protoze prece nebude komunikovat s necim, co pouzije RC4 ...) tak maily fungovat prestanou.
A ti soudruzi co podobny veci prosazujou samozrejme pri svy mozkovy kapacite nemuzou tusit, ze tech zarizeni ktery pouzivaj pro komunikaci mail a zaroven o sifrovani vzivote neslysely jsou tu miliardy. Ono je totiz jednou z nejzasadnejsich vlastnosti mailu to, ze se da posilat i telnetem ...
Mnohem prinosnejsi by bylo tlacit uzivatele do toho aby sifrovali oni, jenze to by krachnul biznis soudruhum z freemailu ...
Az zacne nekdo resit, jestli ta ci ona protistrana pouziva to ci ono sifrovani (protoze prece nebude komunikovat s necim, co pouzije RC4 ...) tak maily fungovat prestanou.
Dovedu si představit, že MUA (včetně webmailů) začnou nějakou značkou ověřovat e-maily, které od odesilatele až k příjemci došly šifrované a bez změny. Např. že by zprávy doručené tímto způsobem byly označovány barevně.
Bohužel, zdá se mi to jako utopie. Zatím se nikdo s nikým nedokázal domluvit ani na efektivním boji proti spamům - a spamy lidi trápí víc, než šifrování po cestě.
Jiste, a tou znackou je ... jedine zasifrovani mailu uz na strane odesilatele.
Ne nutně. Tak, jak je zpráva předávána, může být označována těmi, kdo s ní pracují po cestě. Samozřejmě, není to všespásné, minimálně MTA mohou do zprávy zasáhnout. Zde nám jde ale o docela běžnou situaci, na kterou by jednodušší řešení stačilo: firemní server na jedné straně (po kontrolou jedné strany), firemní server na druhé straně (pod kontrolou druhé strany). A o jediné, o co nám jde je, aby tyto dva servery komunikovaly šifrovaně, a pokud ne, aby to uživatel uměl rozlišit. Samozřejmě, jakmile do řetězce zapojíte SMTP server od ISP, nebo freemail, pak musíte těmto prostředníkům také aspoň základně věřit.
Co jsem svým příspěvkem myslel bylo to, aby informaci získali samotní uživatelé pošty a aby se na své IT-podpoře pídili, jak to zlepšit. V tuto chvíli jsou IT-pracovníci za potížisty, kterým pořád něco nefunguje. To je špatně.
Pokud uživatel vidí, že 7 z 10 zpráv má "zelených" - tedy přenesených bezpečně, patrně na to dřív nebo později upozorní druhou stranu - a ta to bude, opět dřív, nebo později, řešit.
"může být označována těmi, kdo s ní pracují po cestě."
Jo, to je asi tak stejne duveryhodny jako "duveryhodnej" certifikat ...
V běžném styku spolu hovoří MTA odesilatele s MTA příjemcem. Je to jediný přenos mezi dvěma stranami, které si důvěřovat chtějí (těžko budu odesílat informace tam, kde nevěřím, že je nezneužijí).
Hele Silhavy, ze ty vubec ale ani trochu netusis, jak email funguje?
To ze by spolu naprimo komunikoval smtp server na kterej se pripojuje klient s jinym podobnym je spis vyjimka. A to pomijim ty "takyisp", kde ti nic jinyho nez posilat maily pres jejich nezbejva.
Random sem otevrel mail ... a voiala, 7x Received.
Naprosta vetsina komercnich konfiguraci, ktere jsem videl, davno pouziva zabezpeceni klientskeho kanalu, protoze vychazi z verejnych navodu jak postu nastavovat a u navodu na postfix to staci jen prevzit z webu as-is. Za poslednich 10 let jsem videl pouze trikrat, ze by to bylo jinak.
V prvnim pripade se jednalo o generaly s postovnimi schrankami v Belgii. Tim myslim opravdove generaly, kteri se sjeli na bezpecnostni konferenci ENISA a tam se pripojovali hotelovou (nesifrovanou) WiFi.
Druhy pripad byli novinari z Beneluxu a Velke Britanie. U tech ale nehrozi, ze by si posilali neco super tajneho.
A treti pripad byla nejmenovana organizace UN, ktera na jinou konferenci poslala sveho "bezpecnostniho hlavouna". Za 14 dni po te konferenci byla presne tahle organizace hacknuta a ucet tohodle klauna k tomu dost pomohl. Mimochodem, sidlo mela tusim opet v Belgii nebo Holandsku, uz nevim presne, ale v analech UN to jiste pujde najit, tolik neodhalenych hacku tam zas nebylo ;)
Pro tyhle tydyty, resp. spravce IT jejich infrastruktury, je podle meho nazoru primarne urcen RFC 8314. Ti rozumni to uz tak stejne davno maji.