Názory k článku Gmail označuje nešifrovanou poštu. Jak to opravit?
-
standaaaaa9 (neregistrovaný)
no sice to je pekne ale ak uzivatel pouziva win/down/s 1x0 tak mu to je k nicomu kedze vsetky udaje aj tak zverejnil , vedome :) alebo o tom to mozno aj je neviem , urcite je to na zvazenie .., a v linuxe/bsd ... to je teoreticky pouzitelne ale asi je lepsie pouzit platenu Email schranku a tam praktizovat sifrovanie ako na frEe email ... ak som nieco zle napisal tak ma opravte a pozdravujem Original Blek.a a aj neoriginal blek.a :)
-
TKL (neregistrovaný)
Netroufám si odhadnout, zda je mailserverů s kvalifikovaným certifikátem poskrovnu nebo ne, ale třeba můj mezi ně už docela dlouho patří. A i přesto, že jsem postfixu nikdy žádná speciální pravidla pro servery druhých stran nenastavoval, nepamatuji si, že by s TLS šifrováním nastal někdy nějaký problém. Jediné, co jsem před nedávnem udělal bylo, že jsem přidal DKIM a SPF, aby byla komunikace o kousek důvěryhodnější.
-
Ondřej CaletkaZlatý podporovatelA máte taky na doméně DNSSEC? Protože bez něj vám je kvalifikovaný certifikát úplně k ničemu – útočník jednoduše pozmění cíl MX záznamu na svůj server ve svojí doméně, pro kterou bude mít taky kvalifikovaný certifikát.
Z podobného důvodu je vám k ničemu kvalifikovaný certifikát i v případě, že DNSSEC máte, protože stejně si nikdo na Internetu nemůže dovolit doručovat jen serverům s kvalifikovaným certifikátem. Jediné, co opravdu funguje, jsou TLSA záznamy s otiskem klíče serveru, takže na certifikátu pak vlastně nezáleží.
Jinak také poštu doručujeme s oportunistickým šifrováním všem a nikdy s tím nebyl žádný problém. Tedy rozhodně bych doporučoval spíše oportunistické šifrování s opt-out přístupem, než opt-in pouze pro gmail.
-
blergh (neregistrovaný)
Nechci se mylit, ale obavam se, ze to nebude kvalifikovany certifikat podle zakona.
Kvalifikovane certifikaty nejsou urcene pro sifrovani, ale pouze pro podpis a to jeste zejmena pro konkretni osoby (i kdyz uz se vydava i kvalifikovany certifikat pro automaticke zpracovani, ale stale je to neco jineho nez certifikat, na jehoz zaklade je mozne sifrovat).
Vizte: http://www.postsignum.cz/kvalifikovane_certifikaty.html -
blergh (neregistrovaný)
Tak urcite by stacil k sifrovani i podpisu verejny klic z certifikatu a k nemu prislusici klic privatni. Takze technicky to problem neni.
Nicmene pokud budeme chtit pouzivat certifikat (tedy v tomto pripade kvalifikovany dle zakona) - se vsemi daty, ktera obsahuje, pak - protoze je urcen pro osobni pouziti, v CN bude obsahovat jmeno cloveka, nikoliv stroje (to je vylozene v certifikacnich politikach akreditovanych CA). Z toho potom vyplyva to, ze pro pouziti postfixem neni vhodny.
Ale spis bych odhadoval, ze kolega myslel na normalni komercni certifikat.
A samozrejme certifikat s prislusnym privatnim klicem, ktery je urcen k podpisu, je mozne pouzit i pro sifrovani. Ale z dobrych duvodu ma kazdy certifikat deklarovan svuj ucel, pro ktery je vydan a v nekterych pripadech je nevhodne ho pouzivat pro sifrovani, i kdyz to technicky jde. -
kutr (neregistrovaný)
Google se pořád snaží vytvořit dojem, že šifrování mailů při přenosu zvyšuje bezpečnost. Jenže skutečnost je taková, že dokud nezašifruju mail už před odesláním, tak je prostě veřejný. I pokud přijde do googlu zašifrovanou formou, nemůže google vědět jestli někdy předtím už nebyl poslaný nezašifrovaně.
Podle mě je cílem přesvědčit uživatele, že mail je bezpečný a zároveň mít přístup k jejich obsahu.
-
cracko (neregistrovaný)
to je svata pravda, částečne to řeším tím že používám ne google mail ale protonmail .. sifruje i moji schránku. Takže zasifruje i to co prijede nešifrovane ..
Může nastat změt situací ..
1. dám nekomu svuj public key, může mi tedy zašifrovat "tělo" mailu. Pak je jedno jakýma kanalama to jede, nikdo se k tomu nedostane.
2. nemá muj public key .. ale jede to šifrovanými kanály .. pristane u mne a zasifruje protonmail. nikdo se po ceste ani s mé schranky nedozví co bylo odesláno. JEN z mailboxu odesilatele.
3. Nema public key, jede nesifrovanými kanaly, mail je možno odchytit a precist po ceste, ze scranky odesilatele take. U mne v schránce ne.odesilaní pošty funguje obdobne -
1. mam cizí public key, muzu zašifrovat telo správy
2. nemám cizí public key muzu symetricky zasifrovat zpravu, a jiným kanalem poslat k ni heslo, prijemce dostane jen link na zpravu na servru protonmail.
3. odeslu klasicky - pak plati ze je zprava dostupna dle kanalú jakými jede a je dostupna i u príjemce. -
Ondřej CaletkaZlatý podporovatel
Ve skutečnosti je to naopak – zobrazí červený zámeček u zpráv, které nebyly po cestě zašifrovány a tedy byly zajisté vystaveny zvýšenému riziku. Pro ostatní zprávy se žádný zelený zámeček nezobrazuje, protože jak píšete, není zřejmé, kde všude předtím e-mail putoval v otevřeném textu. Takže o žádné přesvědčování o bezpečnosti tu nejde.
-
kutr (neregistrovaný)
Takže červený zámeček znamená, že si zprávu mohl přečíst kdokoliv a bez zámečku to znamená, že si to mohl přečíst kdokoliv. Jaký smysl to teda má?
A třeba tohle mi teda připadá jako přesvědčování o bezpečnosti: https://www.google.com/transparencyreport/saferemail/
-
Ondřej CaletkaZlatý podporovatel
Červený zámeček znamená, že zpráva byla přijata s nižším než běžným bezpečnostním standardem. Což má smysl, protože to umožní vytvořit tlak na těch posledních 20 procent co ještě nešifrují a v budoucnu takové zprávy vůbec nepřijímat.
A v odkazovaném textu jsem žádné velké přesvědčování o bezpečnosti nenašel, naopak bych ho hodnotil jako překvapivě realistický: „Když je e-mail při přenosu zašifrován pomocí protokolu TLS, je pro neoprávněné osoby složitější k němu získat přístup.“
-
kutr (neregistrovaný)
Je potřeba si to trochu proklikat. Např.
" If my email is encrypted in transit, does it mean that no one can ever snoop on my email?Security is an ongoing challenge where no solution is perfect and progress is incremental. Encryption in transit makes it more difficult to snoop on email and universal encryption of email in transit would be a huge step forward for security and privacy online. But encryption doesn’t make snooping impossible. Moreover, email is not only vulnerable in transit—it can also be snooped on after it’s delivered. For example, unauthorized parties could still gain access to your email by installing malware on the computer you use to read it. "
Slovo "privacy" v té odpovědi nemá co dělat. Dále zapomněli říct, že si je může přečíst každý server na cestě i bez virů, takže vlastně oproti nešifrovanému přenosu vůbec žádná změna..
Opět není pravda, mail poslaný zašifrovaným spojením je pořád ekvivalent pohledu:
"Why isn’t all email sent to or from Gmail encrypted in transit?
For decades, the default has been for email to travel across the Internet unencrypted—as if it was written on a postcard. Gmail is capable of encrypting the email it sends and receives, but only when the other email provider supports TLS encryption. ..." -
Ondřej CaletkaZlatý podporovatel
Slovo "privacy" v té odpovědi nemá co dělat. Dále zapomněli říct, že si je může přečíst každý server na cestě i bez virů, takže vlastně oproti nešifrovanému přenosu vůbec žádná změna.
Nemyslím si, že by v odpovědi slovo „privacy“ být nemělo. A ten „každý server na cestě“ jsou ve skutečnosti jen servery domény odesílatele a servery domény příjemce. To je dost výrazné zlepšení ochrany soukromí. Ano, předpokládá se zde, odesílatel důveřuje tomu, jehož prostřednictvím odesílá poštu a příjemce stejně tak důvěřuje tomu, jehož prostřednictvím poštu přijímá.
Jestli to opravdu není žádná změna, tak vám pošlu PCAP dump jednoho e-mailu přeneseného s TLS a klidně vám vyplatím odměnu, když mi napíšete, co bylo jeho obsahem.
-
kutr (neregistrovaný)
Nic se nemění, protože stále nevím kdo ty maily čte a nejsem ani schopen dopředu říct, kdo k nim bude mít přístup. Situace se trochu zlepší, protože se ochráním před náhodným odposlechnutím, ale to stále nezlepšuje důvěryhodnost mailu. Já osobně nejsem proti šifrování, ale v daném případě nic moc neřeší. Pokud by chtěli zvýšit bezpečnost a soukromí, vypadali by ty kroky úplně jinak.
Soukromí znamená, že to čtu jen já nebo lidi kterým to ukážu, rozhodně ne každý prostředník na cestě. A rozhodně ne, že někdo moje zprávy využívá pro byznys.
"A ten „každý server na cestě“ jsou ve skutečnosti jen servery domény odesílatele a servery domény příjemce."
To by mě zajímalo jak to zaručíte? Pokud to nedokážete zaručit, tak z hlediska bezpečnosti se musí předpokládat, že si to čte kde kdo. Bezpečné systémy se nevytvářejí na základě optimistických předpokladů. -
Ondřej CaletkaZlatý podporovatel
To by mě zajímalo jak to zaručíte?
Je to zaručené přímo v SMTP protokolu. MTA odesílatele se zeptá na MX záznam domény příjemce a poštu předá tam. Systém je samozřejmě postaven na tom, že uživatel, který je původcem zprávy, má důvěru k prostředníkovi, kterému zprávu předává k doručení a stejně tak příjemce má důvěru k případnému prostředníkovi, který jeho schránku hostuje. Ostatně, oba mají na výběr, jakého prostředníka zvolit či případně se obejít bez něj.
Žádná náhodná třetí strana či skupina dalších serverů, přes které pošta prochází se v přenosu pošty nevyskytuje a nikdy se nevyskytovala.
-
Filip JirsákStříbrný podporovatelRouter není poštovní server. Když dva poštovní servery mezi sebou posílají e-mail šifrovaně, routery po cestě se k obsahu nedostanou. Právě proto se komunikace mezi mail servery šifruje.
-
Ondřej CaletkaZlatý podporovatel
server třetí strany != router třetí strany
Ano, e-mail nikdy neprochází přes router třetí strany – neprochází totiž přes žádný router. E-mail je záležitost aplikační vrstvy, kdežto router je zařízení síťové vrstvy, takže ničemu jako e-mail vůbec nerozumí, vidí jen spoustu datagramů. Routery pro e-maily se jmenují MTA a běžně se jim říká poštovní servery. Pro ně platí, co jsem psal dříve, tedy že se na přenosu podílejí jen ty, které zvolil buď odesílatel, nebo adresát.
Proti pasivnímu odposlechu na routeru třetí strany TLS zabezpečení přenosu pomáhá, při přidání autentizace pak dokonce pomáhá i proti aktivnímu/MitM odposlechu.
-
sachy (neregistrovaný)
Napriklad CIsco routery umi filtrovat provoz i na aplikacni vrstve, akorat tomu nerikaji ALF, ale CBAC http://docwiki.cisco.com/wiki/CBAC
Pochopitelne ze sifrovani pomaha, ja jen rozporuji tvrzeni, ze se k mailu treti strana nemuze dostat, cituji:
<cite>Žádná náhodná třetí strana či skupina dalších serverů, přes které pošta prochází se v přenosu pošty nevyskytuje a nikdy se nevyskytovala.</cite>
-
Ondřej CaletkaZlatý podporovatel
Předně tvrzení, že se k mailu třetí strana nemůže dostat, v uvedené citaci není.
Navíc je potřeba brát kontext, na který citace reagovala, totiž že:
Dále zapomněli říct, že si je může přečíst každý server na cestě i bez virů, takže vlastně oproti nešifrovanému přenosu vůbec žádná změna..Moje věta o nepřítomnosti náhodných třetích stran či skupiny serverů se tedy vůbec nevztahuje k možnosti odposlechu/modifikace zprávy během přenosu, ale k množství serverů, na kterých je možné zprávy odposlouchávat a modifikovat i pří TLS zabezpečení přenosu.
-
j (neregistrovaný)
Asi by si tu nekdo mel pocist o tom, jak funguje mailserver ... ne, MX vubec pouzivat nemusi, muze mail predat naprosto libovolnemu dalsimu mailserveru, vse v zavislosti na konfiguraci. A ta muze klidne rikat, ze tomu jinymu MTA, ma predavat vyhradne maily od caletky ...
Co vic, dokonce se predpoklada, ze odesilatel bude pouzivat geograficky nejblizsi MTA. Tzn toho, u koho je zrovna pripojen, byt to tak pouziva malo kdo (a smysl to melo v dobach vytacenyho pripojeni).
Tzn NEEXISTUJE ani jediny duvod, proc by nekdo mel necemu takovymu prikladat naprosto jakoukouli duveryhodnost, proste proto, ze nic NEZARUCUJE, ze ten mail nebude putovat siti vi buh kudy a vi buh kam.
-
Ondřej CaletkaZlatý podporovatel
ne, MX vubec pouzivat nemusi, muze mail predat naprosto libovolnemu dalsimu mailserveru, vse v zavislosti na konfiguraci…
Jistě, proto má také odesílatel možnost svobodně zvolit takový server, kterému důveřuje, že s poštou dělá jen to, na čem se dohodli.Co vic, dokonce se predpoklada, ze odesilatel bude pouzivat geograficky nejblizsi MTA.
Zdroj? -
j (neregistrovaný)
Cece, takovyhle placy, bez delat politiku .... japa asi tak uzivatel zjisti, jak je MTA nakonfigurovanej? Zeby presne nijak?
To, ze se maily primo predavaj je zcela BEZNA konfigurace. Naprosto bezne existuje sada stroju ktery maily prijimaj, a pak jina sada stroju, ktery maily odesilaj, mezi nima pak muze jeste byt dalsi sada stroju, ktery (treba) provadeji nejakou analyzu (spam, viry, ...)... ze by vse delal jedinej stroj je spis vyjimecny. A japa maily putujou mezi nima? No to vi buh. A myslis ze to bude v hlavickach? Vubec byt nemusi.
Proc ma DHCP jako jeden z parametru mailserver? Asi proto, aby ho uzivatel nepouzil ... jinak si najdi prislusna RFC.
Nehlede na to, ze uzivatel velmi casto navyber vubec nema, protoze nekteri "takyisp" mu jinej nez svuj MTA neumoznej kontaktovat.
-
Ondřej CaletkaZlatý podporovatel
japa asi tak uzivatel zjisti, jak je MTA nakonfigurovanej? Zeby presne nijak?
A co na tom záleží? Uživatel musí předat poštu prostředníkovi, kterému důvěřuje, nebo si ji doručit sám. Stejně jako když v reálném světě posílá zprávu po poslovi, musí vybrat důveryhodného posla, nebo ji donést osobně na místo určení.To, ze se maily primo predavaj je zcela BEZNA konfigurace. Naprosto bezne existuje sada stroju ktery maily prijimaj, a pak jina sada stroju, ktery maily odesilaj, mezi nima pak muze jeste byt dalsi sada stroju, ktery (treba) provadeji nejakou analyzu (spam, viry, ...)... ze by vse delal jedinej stroj je spis vyjimecny.
To není v rozporu s ničím, co jsem dříve napsal.A japa maily putujou mezi nima? No to vi buh. A myslis ze to bude v hlavickach? Vubec byt nemusi.
Vždycky je to ale v rukách buď osoby, které důvěřuje odesílatel, nebo osoby, které důvěřuje příjemce. Nikdy nejde o náhodnou třetí stranu.Proc ma DHCP jako jeden z parametru mailserver? Asi proto, aby ho uzivatel nepouzil ... jinak si najdi prislusna RFC.
Kdo tvrdí, ten prokazuje. Která jsou ta příslušná RFC? RFC 2132 specifikuje DHCP volbu pro mailserver, ale žádným způsobem nepředepisuje, jak by se tato volba měla používat. Dokonce jsem ani nenašel informaci o tom, že by existovala nějaká implementace MUA, která by tuto DHCP volbu používala.Nehlede na to, ze uzivatel velmi casto navyber vubec nema, protoze nekteri "takyisp" mu jinej nez svuj MTA neumoznej kontaktovat.
Obvykle bývá pouze zablokovaný provoz na cílový port 25. Porty 465 a 587, které se pro předávání pošty k odeslání používají, blokovány obvykle nejsou. -
Filip JirsákStříbrný podporovatel
muze mail predat naprosto libovolnemu dalsimu mailserveru
Přičemž ten naprosto libovolný další mailserver ten e-mail odmítne s tím, že ten e-mail není určen pro něj a nebude dělat open relay. A pokud náhodou nějakou open relay najdete, nebude od ní zase přijímat e-maily nikdo jiný, protože bude na všech blacklistech.Co vic, dokonce se predpoklada, ze odesilatel bude pouzivat geograficky nejblizsi MTA.
To se předpokládalo kdysi dávno. Dnes už nikdo nic takového nepředpokládá, třeba SPF s tím nebude fungovat vůbec a DKIM by mnoho příjemců asi překvapilo.Tzn NEEXISTUJE ani jediny duvod, proc by nekdo mel necemu takovymu prikladat naprosto jakoukouli duveryhodnost, proste proto, ze nic NEZARUCUJE, ze ten mail nebude putovat siti vi buh kudy a vi buh kam.
To jste ale ale obrátil to tvrzení naruby. Google neoznačuje poštu, která přišla šifrovaným kanálem, právě naopak, označuje poštu, která přišla nešifrovaným. -
j (neregistrovaný)
Jirsak, v Bohnicich maj zas vychazky? Ty vis o fungovani smtp naprosty hovno. Co myslis ty trotle, kdyz forwardu vsechny maily na MTA providera, co snima udela? NJ, zazrak, posle je, protoze sem jeho zakaznik a on mi to poskytne jako sluzbu. A to je asi tak jeden z miliardy zpusobu. Kupodivu presne stejne muzu naconfit DNS, a nedelat resolv sam, a jen forwardnout dotazy jinam ... zazrak.
Ten cestin byti jazyk slozita ... google explicitne tvrdi, ze kdyz mu neco prijde pres ssl, je to OK, ale pritom to OK vubec neni. Ale to tatar jako ty nemuze pochopit.
-
lol (neregistrovaný)
pozrite si hlavicku nejakeho mailu. Mate tam hromady:
Received: from localhost (localhost [127.0.0.1]) by a.b.c.d (Postfix) with ESMTP ...Cize milters ala amavis,spamassasin,opendkim,.... Zakazdym ked to cez nejaky prejde, je to rozsifrovane a vacsina z nich mail ulozi pri processingu na disk a neskor zmaze.
Takze je uplne jedno ci bude TLS na komunikaciu so svetom pouzivat kazdy, ked 99% casu je ten mail v plaintexte a posledny hop urobi cez ESMTPS
-
j (neregistrovaný)
Ano, genialni pristup ...
Hnedle zduvodnim jak. Takze zacneme sifrovat, je to sice nanic, protoze nevime jestli bylo sifrovany celou cestu, ale necht. Pak zacneme odmitat nesifrovanou komunikaci ... proc ne, jde prece o bezpeci. Mno a pak, pak zacneme resit, ze ten ci onen algoritmus je prece nebezpecny, takze ho nebudeme pouzivat ... a uzivatele/administratori/... budou konecne naprosto v bezpeci, protoze budou naprosto v pici.
Proc ze to? Mno uz ted si nenakonfigurujou svuj router, protoze jim nekdo zcela bezpecne vypnul ty nebezpecne sifrovaci algoritmy, takze si prej maji https vypnout, a pouzivat http. Je totiz daleko bezpecnejsi prihlasovat se k routeru tak, a heslo posilat jako open text.
S mailama je to presne totez. Hromada vsemoznyho harampadi posila maily. Miliony tehle krabic neumi sifrovat nebo umi "nebezpecne" varianty. Takze uzivatelum dame na vyber ... vyhodte sve krabice ... nebo pouzivejte starou veriz MTA, ktera jeste nevyzaduje ssl povine ... Uzasny, primo genialni ...
A samo, protoze cyklus likvidace nebezpecnych sifer bude rok co rok, tak si budou muset useri zvyknout, ze tok co rok maji svuj HW zahodit, a koupit novy. Vsak s televizi to bude brzo stejne, ze ... pocitam ze pristi rok nekdo prijde s dvb-t3.
-
Ja mam s googlem naprosto negativni zkusenosti.
Vsechny maily co poslu na adresu nekdo@gmail.com, dava adresatovi do slozky SPAM. Uz jsem nastavil sfp a dkim, podporuju sifrovani, ale nic se s tim neda delat. V mem gmail konte jsem jednou oznacil jeden z techto mailu jako ze neni spam, od te doby co si poslu na muj gmail, tak projde, ale pokud poslu ten samy mail nekomu cizimu, u nej to zase skonci ve spamu. Muj server neni na zadnem blacklistu. Google ve FAQ tvrdi, ze se to mozna casem spravi samo.
Mate s tim nekdo podobne zkusenosti a podarilo se to nekomu vyresit? Podobny problem jsem uz jednou mel s jinym serverem, ale tehdy stacilo dat do poradku zaznam sfp a od te doby to jede. Ale tady proste nic. -
No tak je pochopitelne, ze takovyhle email (toto body a toto telo) skonci ve spamu. Zkus poslat bezny "dopis babicce".
Dale podle me google nejakym zpusobem hodnoti taky to jak dlouho uzivatel ty emaily cte, jak casto je z inboxu naprimo archivuje apod. Chodi mi takhle maily z meho Bitbucket serveru o commitech. Po case "prestaly" chodit a gmail je me konktretne zacal davat do Spamu. Ostatnim ne. Prisuzuju to prave tomu, ze jsem je v 99% archivoval hned z Inboxu bez zobrazeni detailu. Samozrejme po pridani vyjimky uz mi zase chodi do Inboxu. Takovym indikatorem toho, ze to zacne padat do spamu je kdyz google vyhodnoti prioritu jako nejnizssi v te ikone co vypada jako vojenska hodnost.
-
Jenomze pruser je v tom, ze pokud ma google takovy postup, ze maily z urcite adresy napred dava do spamu a az teprve uzivatel rekne, ze to neni spam, tak pak mu je prestane vyhazovat. Jenomze ja samozrejme nemuzu vsem lidem co poslu mail poslat jeste jeden, at si ten prvni oznaci jako ze neni spam, aby ho uz priste dostali!
Pokud bude google uplatnovat presumpci viny, tak se proste nedaji posilat maily. -
Já (neregistrovaný)
Zkus neco poslat na https://www.mail-tester.com/ myslim, ze je nekde nejakej zadrhel v konfiguraci (co treba reverz?)
...a pak si muzes jeste zkusit nainstalovat do dockeru komplet mailserver https://poste.io/open ...sam jsem s tim nikdy nemel problem a to uz jsem par novejch mailserveru instaloval. -
Pali (neregistrovaný)
> Gmail označuje nešifrovanou poštu. Jak to opravit?
Jednoducho, prestať to používať.
Kvôli ním tu máme DMARC, vďaka čomu musia mailinglisty, bugzilly (a podobné služby) mršiť emaily, lebo inak ich Gmail dáva do spamu. Sú to úplne validné emaily, ktoré vôbec nie sú spam a vyhovujú (asi poslednému?) štandardu RFC 5322.
Som zvedavý, kedy dospejeme do stavu, že na komunikáciu bude treba mať službu gmail, ktorá bude úplne nekompatibilná so službou "email"...
-
msx. (neregistrovaný)
Mám freemail na atlas.sk, ale tu nastáva problém. Freemailoví poskytovatelia predsa zadarmo nebudú šifrovať. Na druhej strane ten email zrušiť zo dňa na deň nemôžem. Niekde som čítal, že vraj atlas, centrum a pobox (jedna firma na Slovensku, neviem ako v Čechách) umožňuje aj šifrovanie pošty pre freemail. Nastavoval som to 2x, ale nepodarilo sa. Vedel by s tým niekto pomôcť? Je mi jasné, že článok je o niečom inom, ale v rámci diskusie si myslím, že sa môže spomenúť aj táto časť problému.
-
Filip JirsákStříbrný podporovatel
Jsou dvě různé věci. Šifrování e-mailu (konkrétní zprávy), a šifrování komunikace mezi servery. Šifrování e-mailu je nezávislé na poskytovateli, je potřeba jenom podpora v klientovi – takže pokud můžete použít třeba Thunderbird, můžete šifrovat. Druhá věc, která je potřeba, je mít veřejný klíč adresáta – a na tom to vázne, protože jen málokdo má certifikát pro šifrování e-mailů. Takto zašifrované e-maily pak může číst jenom adresát (vlastník odpovídajícího privátního klíče), k obsahu e-mailu se nedostane ani provozovatel žádného serveru.
Zprávička je o tom druhém, tj. šifrování komunikace mezi servery. Tj. vy svému serveru předáte nešifrovaný e-mail, on ho šifrovaným kanálem pošle na cílový server, a ten ho zase nešifrovaný uloží do schránky. Tohle vy jako uživatel ovlivnit nedokážete, to ovlivní jenom správce toho serveru, přes který e-mail posíláte. Poskytovatel freemailu by komunikaci šifrovat měl, náklady na to jsou minimální v porovnání s ostatními náklady na provoz freemailu. Teoreticky nemusíte pro odeslání ani používat servery toho freemailu, ale jiné – třeba svého ISP. Bez problémů to tak fungovalo dříve, dnes už se často kontroluje, že je e-mail odeslán z toho „správného“ serveru (což záleží na nastavení jak na straně toho serveru freemailu tak serveru adresáta).
-
yarda (neregistrovaný)
Další nesmyslná googlovina. To že to přijde na google last hop přes zašifrovaný kanál, neznamená, že to někde po cestě nešlo nezašifrovaným kanálem nebo že to někdo po cestě neodposlechl např. přes MITM. Bez šifrování obsahu a podepisování na koncových bodech pomocí PGP nebo S-MIME je to úplně k ničemu a v podstatě stejné jako by se ty maily posílaly s CC na info@nsa.gov
-
Ondřej CaletkaZlatý podporovatel
Opravdu k ničemu? Takže když vám dám dva PCAP záznamy přenosu zprávy, v jednom bude zpráva přenesena v plaintextu, v druhém v TLS, tak vám bude trvat stejně dlouho získat obsah?
Nebo je k ničemu všechno, co není absolutně bezpečné? Tohle logikou bychom doteď používali Telnet. SSH je totiž k ničemu, útočník může při prvním spojení udělat MitM a spojení odposlouchávat.
-
ujo imro (neregistrovaný)
Ak si schopny spravit PCAP, tak si schopny aj spravit MITM a kedze klientsky server neoveruje serverovsky certifikat, tak na to google ani odosielatel nepridu. A hned je na svete falosny pocit bezpecia.
Takze ano, je mozne lahko precitat aj pozmenit email, ak si schopny spravit PCAP (snifnut, pozmenit traffic medzi dvoma SMTP servermi).
-
Nestačím se divit, kam diskuze spěje. Fakt je tak složité pochopit, že email můžete poslat šifrovaně na SMTP třeba z mobilního klienta. Ten si ho rozšifruje a při následném odeslání cílovému systému ho zase zašifruje. Ten ho ve schránce znovu má rozšifrovaný.
V dešifrované podobě se tedy vyskytuje jen u vás v počítači, SMTP serveru a cílovém systému. Po síti ale putuje stále v zašifrovaném stavu, to je špatně? Dokonalé to není, ale Google tam má prostě červený zámeček (nejhorší možnost). Jinak nezobrazuje nic.
ČLÁNKY DO MAILU