Názory k článku Velká část e-mailů putuje internetem nešifrovaně. Kdo to změní?

??? S/MIME je na GPG uplne nezavisle (mozna by se dalo rict, ze se vzajemne vylucuji :) ).

Podpora v Thunderbirdu 100% bez instalace doplnku (pouzivam). Predpokladam, ze Outlook taky. Kde je tedy problem? Webmaily?

Aha, certifikaty. To se asi moc nerozsiri, uz vidim, jak si BFU skrabe hlavu, kde ziskat certifikat. V GPG si nageneruju klicu, kolik se mi zachce a pekne doma, bez shaneni. Ale pro BFU to ma zase jine problemy, treba blbe fungujici key servery. Jedno jak druhe je pro BFU prakticke jak hrabe do postele a asi se moc nerozsiri.

Spousta zamestnavatelu, popr. i CESNET, certifikaty vystavuje. Ale pro BFU, jak rikate, je to trochu slozitejsi. Chtelo by to neco jako Let's encrypt pro mail certifikaty.

Chtelo by to neco jako Let's encrypt pro mail certifikaty.

Stále to neřeší, že CN certifikátu nebude odpovídat doméně odesilatele, ale maximálně poskytovateli SMTP služby. A tomu budete muset důvěřovat tím, že buďto budete věřit každému certifikátu, nebo každému certifikátu od důvěryhodných CA, nebo budete ověřovat i identitu druhé strany.

Nyní se to děje víceméně podle prvního způsobu. Přechod na Let's Encrypt by moc nepřinesl, maximálně do logů řádek o tom, s kým jsem hovořil a kdo to ověřil. Třetí varianta je zase složitější na nastavení a údržbu.

Občas proste musíš veriť aj niekomu kto nie je priateľ. Je to možno nejaká overaná autorita, mno priateľ to nie je.

Posedni dobou se ukazuje, ze cely system certifikacnich autorit je v lepsim pripade poloduveryhodny. Takze je lepsi certifikatum poloduverovat a pouzivat GPG.

Ale pro BFU, jak rikate, je to trochu slozitejsi. Chtelo by to neco jako Let's encrypt pro mail certifikaty.

Cili pokud to neni na par kliku, tak tudy asi cesta nevede. Radsi bych videl, kdyby se rozsirila podpora GPG, ta se na par kliku udelat da a casem by to dolezlo i do Utlouku, protoze MS by nechtel byt posledni, kdo to jeste nepodporuje, aby mu lidi neprestali pouzivat Utlouk.

V korporátních e-mail klientech bude podpora PGP/MIME (protokol se jmenuje (Open-)PGP, GnuPG je jen jedna z jeho implementací), až to korporát bude po výrobcích požadovat. Ale korporáty jsou obvykle zařízeny na S/MIME, často mají zaměstnanci i smart karty, takže pro ně S/MIME funguje bez problému. PGP je proti tomu takový punk srovnatelný třeba s Torem, Bitcoiny, nebo alternativními DNS stromy a funguje tak maximálně u vývojářů a lidí z bezpečnostní komunity.

Ale korporáty jsou obvykle zařízeny na S/MIME, často mají zaměstnanci i smart karty, takže pro ně S/MIME funguje bez problému.

To je mozne, ale brani to nejak aktivne autorum MUA, aby podporu ve svych aplikacich meli? Nikdo nenuti korporace, aby na to prechazely. Nezajem o sifrovani nejak nechapu, hlavne ze si vsichni stezuji, ze je NSA smiruje. A to, ze to nechteji implementovat, protoze to nikdo nepouziva, je spatny argument, protoze to nikdo pouzivat nemuze, kdyz to skoro nikde neni implementovane.

Jen si takhle asi nepujde ziskat certifikat pro adresu na freemailu =)

Nedají. Rozlišujte prosím certifikát pro TLS server, vázaný na doménové jméno a certifikát S/MIME vázaný na e-mailovou adresu. Ten první se používá třeba na spojení s HTTPS či IMAP serverem, zatímco ten druhý se používá například pro šifrování nebo elektronický podpis e-mailů v protokolem S/MIME nebo CMS. Ten první vám Let's Encrypt vydá, ten druhý ne (mimo jiné nemá zatím způsob, jak automatizovaně ověřit e-mailovou adresu). A v tomto vláknu se bavíme o šifrování e-mailů v poštovních klientech, tedy o těch druhých certifikátech.

Získat základní DV S/MIME certifikát je jen na pár kliknutí, ale skutečně málokdo to udělá:

https://secure.comodo.com/products/frontpage?area=SecureEmailCertificate

Intergrace takové DV S/MIME certifikační autority do poštovního klienta by byl rozhodně krok správným směrem a snad se o to třeba Let's Encrypt někdy v budoucnu pokusí.

Ano, vim, taky ho mam. V zasade jedina soucasna moznost, jak mit DV S/MIME certifikat zdarma (kdyz pominu, co jsem psal - CESNET a spol.).

Nicmene Comodo taky v posledni dobe nepusobi uplne duveryhodne.
https://www.root.cz/zpravicky/comodo-se-snazi-zaregistrovat-ochrannou-znamku-let-s-encrypt/

Souhlasim, ze integrace vydavani certifikatu by tomu hodne prospela.

Nicmene Comodo taky v posledni dobe nepusobi uplne duveryhodne.

Otazka tedy je, proc tlacit s/mime a ne radsi GPG, kde nikomu duverovat nemusite. S protejskem si po telefonu nebo v hospode na papirku vymenite otisky klicu a mate vystarano.

Otazka tedy je, proc tlacit s/mime a ne radsi GPG, kde nikomu duverovat nemusite.

Protože BFU řeší běžné životní problémy. Aby dostal svoji mzdu, aby zaplatil dětem oblečení a kroužky do školy, aby měl doma čerstvý chleba. Nikoho, ve skutečnosti, moc nezajímá bezpečnost. Maximálně ve chvíli, kdy je obětí podvodu.

Ve velké spoustě mailerů je S/MIME nativně podporováno (tedy včetně GUI) a to napříč operačními systémy. Dokonce i webový Gmail umí S/MIME, ale bohužel jen ve variantě pro firmy.

Kdysi jsem si S/MIME v Evolution zapl, ale když mi klient s nějakým zhnilým Outlookem volal, že mu přišel "prázdný mail", tak jsem si to zase velice rychle vypl. Šifrování je teoreticky velice hezké, ale v praxi je důležitější, aby si to příjemce mohl/uměl přečíst.

Hlavní problém pro uživatele není v obstarání certifikátů, ale v tom, aby si mohl maily přečíst - a to i starší maily, které má třeba v archivu a potřebuje se k nim vrátit. V okamžiku, kdy vyprší platnost certifikátu, kterým byl mail šifrován, to začíná být problém. A už vůbec je to problém např. při změně PC, notebooku apod. - v případě, že zmizí privátní klíč, zmizí nenávratně i možnost si tyto maily přečíst.
A ukládat si vše co přišlo v textové podobě někam na disk není moc pohodlné.

Expirace certifikátu nepředstavuje problém v dešifrování archivních dokumentů. Jen je potřeba, aby si uživatelé uvědomili, že i expirovaný certifikát. resp. privátní klíč k němu, má užitnou hodnotu a je třeba ho chránit a archivovat.

Expirace certifikátu nepředstavuje problém v dešifrování archivních dokumentů. Jen je potřeba, aby si uživatelé uvědomili, že i expirovaný certifikát. resp. privátní klíč k němu, má užitnou hodnotu a je třeba ho chránit a archivovat.

Velmi odvážné tvrzení, stavějící bezpečnost na hlavu.

Exspirace certifikátu je zde od toho, že se předpokládá, že časem dojde ke kompromitaci algoritmu šifrování. Jedinou možností je ještě před exspirací data přerazítkovat něčím aktuálním a prodloužit tím platnost. Tím je zajištěno to, že podpis na datech existoval už v době, kdy bezpečnost algoritmu (ještě) nebyla kompromitována.

A neni to tak, ze kdyz vim, ze ten email mi (fyzicky) dorazil v dobe, kdy certifikat platil, a ze mi ho v PC od te doby nikdo nezmenil, tak je to ok? Tedy samozrejme pokud nebyl revokovan k datu pred prijetim mailu.

Zajimal by me "vektor utoku" vyprsenym certifikatem na mail poslany v dobe, kdy jeste vyprseny nebyl. Znate nejaky takovy?

A neni to tak, ze kdyz vim, ze ten email mi (fyzicky) dorazil v dobe, kdy certifikat platil, a ze mi ho v PC od te doby nikdo nezmenil, tak je to ok? Tedy samozrejme pokud nebyl revokovan k datu pred prijetim mailu.

A jak to víte, že ten e-mail nikdo v mezičase nezměnil? Máte opravdu tak plnou kontrolu nad úložištěm mailů? Dovedu si představit situaci, kdy bude nějaký algoritmus kompromitován tak silně, že nebude problém vytvořit ransomware, který Vám pročeše e-maily a vloží do nich např. odkazy na které bude doufat, že jednou kliknete. To je jen příklad.

Z principu, cokoliv co od dnešní chvíle zpět nemohou ověřit řetězcem důvěryhodnosti, svoji důvěryhodnost pozbývá.

Ale prosím nemylte se, že bych považoval takový přístup za nutný. Já spíš poukazuji na to, že dělat to dobře není vůbec lehké, naopak je to velmi nákladné. Je možná lepší mít data uložena nešifrovaně a vyhodnocovat důvěryhodnost doručení jen v momentě "živého" čtení, ale neřešit to zpětně. Zpětně, když nebude zpráva přerazítkovaná, musíte ji zobrazit jako bez důvěryhodnosti.

Ano, přesně tak a přesně k tomuhle jsem cílil.
Např. také může dojít ke ztrátě úložiště privátního klíče, certifikát je revokován atd. - jak se odstanu k šifrovaným mailům? Pokud nemám úložiště přímo v PC a certifikát mi vydala organizace, kde je politika certifikátu bez možnosti exportu, nemůžu ani zálohovat, tak vůbec nemám šanci. Jediná možnost je opravdu jen ukládat každý mail nešifrovaně na disk. A opravdu každý - protože kolik mailů můžu bez obav o jejich budoucí potřebě okamžitě smazat/resp. neukládat?
A teď tohle všechno chtít od běžného uživatele.
Jsem přesvědčen, že tudy cesta nevede, nehledě na to, že běžně existují systémy, kde jsou zašifrované maily zahazovány, protože neprojdou antivirem/spamem.

Ten vtip je v tom, že k dešifrování certifikát vůbec nepotřebujete, stačí vám privátní klíč. A ten neexpiruje. Samozřejmě se může stát, že v čase ztratí sílu, nebo bude jinak kompromitován, to vám však nebrání starou poštu rozšifrovat a chcete-li, zašifrovat znovu a bezpečněji. Jediné, co nesmíte udělat, je po nahrazení certifikátu novým konstatovat, že ten starý už nepotřebujete a nenávratně ho smazat spolu s privátním klíčem.

Ten vtip je v tom, že k dešifrování certifikát vůbec nepotřebujete, stačí vám privátní klíč.

Už mícháme jabka a hrušky. Podpis a šifrování jsou něco odlišného.
Data dešifrovat půjdou, ale podpis už nebude možné ověřit.

Proto jsem přece psal, že přijdete o privátní klíč. Typicky - mám certifikát spolu s privátním klíčem uložený na čipové kartě, kterou ztratím. Certifikát není exportovatelný, tedy nemůžu ani udělat zálohu do souboru (certifikátu, ale ani privátního klíče). Po ztrátě nechám certifikát reovokovat, takže ho nikdo nemůže zneužít. Ovšem k šifrovaným maillům se už nedostanu, protože není způsob, jak získat privátní klíč.

Snad už je to dostatečně podrobné, aby to bylo jasné :-).

Aha, pokud to je takhle, tak je to skutečně dost nešťastné a takové e-maily bych rozhodně archivoval v rozšifrované podobě.

Ve firmě, kde o tom přemýšlejí, to mají zařízené tak, že mají na kartách dva různé certifikáty – ten který slouží k šifrování je generován externě během personalizace karty a existuje k němu (a privátnímu klíči) na bezpečném místě záloha. Druhý certifikát – podepisovací – je naopak vygenerován přímo v kartě, nelze exportovat a záloha k němu neexistuje. Díky tomu je nepopiratelné, že kdo vytvořil elektronický podpis, měl v ruce danou kartu.

Z počátku jsem se podivoval nad tím, proč jsou na kartě dva velmi podobné certifikáty, ale po takovéhle úvaze to začne být jasné ;)

Dva oddělené certifikáty jsou dost často používané, probém je v automatickém použití certifikátu, který přijde v mailu v podpisu, jako šifrovacího pro odpověď - standardní postup v SMIME/outlook.
Klascky uživatel nastaví požadavek na šifrování a o nic dalšího se nestará.
Dva oddělené certifikáty na kartě se skutečně hodně používají, ale většinou jeden pro přístup (a šifrování komunikace) a druhý pro podepisování dokumentů, ale nikoliv mailů. Zveřejňování public klíče certifikátu pro použití na šifrování mailů zrovna moc nefugnuje a to ani uvnitř organizace, natož pro komunikaci mezi organizacemi (resp. pro jakoukoliv externí komunikaci).
Prostě to opravdu není jednoduché.

Ano, souhlasím v plném rozsahu. Tady je skutečně velký prostor pro zlepšení.

Jojo. A vono to pak odesílá nešifrovaný maily a víc jak půl roku si toho nikdo nevšimne.

To jsi spatne pochopil, oni ty maily prece sifruji. Akorat tedy posilaji i kopii v clear textu, asi proto, kdyby druha strana mela problemy s rozsifrovanim. It's not a bug, it's a feature. Cilem je zlepsit spolehlivost mailu.

nehledě na to, že běžně existují systémy, kde jsou zašifrované maily zahazovány, protože neprojdou antivirem/spamem.

Tak by asi bylo dobre takove systemy nepouzivat. To je jeste vetsi pitomost, nez cenzura mailu na Centru. Kde jste tohle slysel? S tim jsem se jeste nesetkal.

BTW, proc by nemely projit antivirem a spam filtrem, kdyz ty nemuzou mit tuseni, v cem se hrabou? To by znamenalo, ze to zase nastavovalo nejake hovado. Nerozumim=zahodit? To by mohli zahazovat i maily v tamilstine, protoze na tu ceske spam filtry urcite nebudou stavene.

Už jsem se s tím setkal několikrát - pravda ne na freemailu, ale v různých korporacích i na státních úřadech. A pak jen zjišťujete, jestli mail vůbec došel - dojít nemusí a nemusíte dostat ani informaci, že nebyl doručen (běžně se informace o zahození mailu neposílá). Koneckonců je mail negarantovaná služba a doručení mailu musíte ještě ověřit telefonicky.

Potvrzuji, testovali jsme před lety nějakou komerční antispamovou krabici a ta šifrované S/MIME e-maily pravidelně vkládala do karantény. A ještě ne všechny. Jak řekl kdysi major Dastych: „Lidi vymejšlej bejkárny, takhle to je a bude.“

Jak řekl kdysi major Dastych: „Lidi vymejšlej bejkárny, takhle to je a bude.“

Já si pamatuju osobně, tenkrát ještě kapitána Dastycha, jak v dřevních dobách vyšetřoval první "kyberzločiny". Ano, byl to velký kliďas s velkou plackou od kriminálky, což na ajťáky působilo jak z jiného světa. Nevím jak později, ale ještě na konci devadesátých let to byl hlavně policista, ale IT nijak nerozuměl. Uměl ale aspoň základně zpracovat vstupy informací, které mu ajťáci dali, vytvořit z toho protokol a provést aspoň nějaké vyšetřování. Je zajímavé, že jeho ikona s námi stále žije, v té době jsem netušil, že vidím někoho nesmrtelného :).

Nesouhlasím.
Šifrovaný mail používám také proto, aby nemohl ani administrátor serveru mail přečíst - proto mi nestačí jen šifrované spojení a nemůžu také takový mail nechat nešifrovaný v inboxu - na mailovém serveru (přístup přes IMAP).
Jediná možnost je skutečně ukládat rozšifrované maily na lokálním PC (samozřejmě do šifrovaného prostor).

To si asi děláte legraci s tím dotazem, ne?

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

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

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 ;)

Třeba takto?

https://napoveda.seznam.cz/cz/email/microsoft-outlook-2013-2016/imap-nastaveni-microsoft-outlook-2013-2016/

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

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

Random sem otevrel mail ... a voiala, 7x Received.

Tak ono na freemailech je to kolikrat tak, ze si to petkrat preposlou uz u nich doma mezi vlastnimi servery.