Az email digitális aláírása - mennyire fontos a mai világban?

Közösségi kerekasztal

A kérdés a tárgyban van. Régebben érintettem a témát, talán még kreáltam is valamit PGP-vel, de annyira nem emlékszem rá. Taknyos, zöldfülű voltam még. (:
Viszont amióta benne vagyok a Tégy Jót!®-ban, a téma eszembe se jutott, de jobb később, mint soha. Tehát, adott egy saját tulajdonú levelező szerver (IMAP, SMTP), ma gondolkodtam rajta:

  • Kell-e Debianban mókolni valamit?
  • A webmail kezeli-e külön plugin nélkül a PGP aláírást (Roundcube)?
  • 5993 megtekintés

( tigrincs | 2016. 08. 19., p – 18:05 )

Cegnel es maganlevelezesben is hasznalom (kiveve a gmailes spamcsapda levelezon :D)
Maganreszre akar comodo akar startssl ingyen biztosit certet.

( SzBlackY | 2016. 08. 19., p – 18:16 )

My 2 cents:
Ha azt akarod, hogy megbizonyosodhassanak arról, hogy tényleg te a szervered küldte és útközben senki nem piszkált hozzá, állíts be DKIM-et (akár feladóként külön kulccsal, akár domain kulccsal). Ezt akkor egy az egyben elintézi neked a szervered, a fogadó félnél pedig szintén a szerver ellenőrizheti.

> A webmail kezeli-e külön plugin nélkül a PGP aláírást (Roundcube)?
Ha kezeli, az rég rossz, mivel onnantól kezdve a szerveren ott kell, hogy legyen a kulcsod (vagy a böngésződbe plugin, ami meg tudja oldani az aláírást, passz, hogy van-e ilyen).

--
Mi lenne a célja az aláírt leveleknek?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A DKIM az alap

Úgy rémlik, amikor múltkor posztolta a postfix configját egy topicban, abban nem láttam semmit, ami DKIM aláírásra emlékeztetne.

egy levelrol nem tudjuk hogy azt a felhasznalo kuldte e

De a szervert tudjuk, és fentebb ezt írtam :) [egyébként egy per-user DKIM kulccsal kb. ugyanazt éri el, mintha a webmail rendszerbe beerőszakolja a kulcsát]

Off-topic: egyébként meg egy baseball-ütő kérdése, és a PGP-nél se lehetsz biztos abban, hogy a felhasználó küldte ;)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( janoszen v | 2016. 08. 19., p – 20:21 )

Egyrészt: nem fontos. Szakmai körökben is időnként hülyén néznek rám, amikor azt mondom, hogy legyen kedves az érzékeny információt nem jelszavazott ZIP fileban küldeni.

Mindazonáltal mindkét utat bejártam (rendes CA-tól rendelt S/MIME certificate és PGP) és nekem úgy tűnik, ha valami, akkor a PGP (GPG) működik, mert mindenkinek elérhető, nem kell sokat vacakolni egy CA-val. Arra érdemes figyelni, hogy a Web-of-Trust a PGP-nél teljesen használhatatlan, ma már senki nem tart key signing partykat és mindenki mindenfélét aláírogat, úgyhogy ha megbízhatót akarsz, akkor ellenőrzöd a másik fingerprintjét valamilyen más módon mielőtt megbízhatónak jelölöd a gépeden. Értelemszerűen ezt is helyén kell kezelni, nem bízhatsz abban, hogy a másiknál rendben van a kulcsok kezelése és nem lopják el őket, de everyday használatra elég lesz. (Ez egyéként az aláírásra és a titkosításra is igaz.)

Nekem egy Yubikey 4-en van a jelenlegi aláíró kulcsom és az egyik subkeyt használom SSH bejelentkezésre, így egy picit gátat szabok a gépemen remélhetőleg nem levő, de nem kizárt kulcslopó eszközöknek.

A webmail kérdést nyugodtan felejtsd el, én nem találkoztam olyan módszerrel, amivel ez szívásmentesen megoldható lenne anélkül, hogy a szerveren meglenne a kulcsod (ami értelemszerűen rossz ötlet). Ha GPG-t akarsz használni, az asztali levelező programokhoz vannak egészen tűrhetően működő pluginek (Thunderbirdhez Enigmail, alma levelezőhöz GPGTools, stb), de végszükség esetén parancssoron is alá tudod írni a leveledet. Ha S/MIME certet használsz, akkor az defaultból működik, de mint említettem, valamelyik CA baromságainak kiteszed magad, és nincs is ingyen.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

"Egyrészt: nem fontos. Szakmai körökben is időnként hülyén néznek rám, amikor azt mondom, hogy legyen kedves az érzékeny információt nem jelszavazott ZIP fileban küldeni."

OFF: ha beleírja a levél főrészébe az érzékeny információt, az mennyire veszélyes, és milyen szempontból?
Bocs az offért, csak egyszer meg akartam nézni, és kb csak annyit találtam hogy ha a fejlécben ESMTP szerepel, akkor az elvileg titkosítva van, bármit is jelentsen ez.

Kell félni?

(egyszer megadtam minden létező adatomat egy form-ban (beleértve az e-mail címemet) és autómatikusan elküldték nekem emailben, hátha elfelejteném őket)

Az e-mailben átküldött infó kb ugyan annyira védtelen mint a sima http vagy ftp. A levelező szerverek között nem kötelező a titkosítás, de ha éppen használnak akkor is bármilyen certet elfogadnak, ezért nem védett pl. MITM vagy DNS spoofing ellen. Általában az utolsó szervertől a felhasználóig már nem ennyire rossz a helyzet, ott IMAPS/POP3S elterjedt és a kliens valamelyest a certet is ellenőrzi. Vagy esetleg webmail van, https felett, az sem vészes.

Ahol a formban megadott jelszavadat, bankkártyaszámodat, vagy más érzékeny adatodat e-mailben visszaküldik, onnan érdemes menekülni.

Nem. Ebből a szempontból semmiben nem különbözik a gmail sem.

Természetesen előfordulhat hogy egy levél véletlenül éppen csak biztonságos útvonalon utazik - pl. a feladó és a címzett egy e-mail szerveren van, a szerver teljesen megbízható, nem használ semmilyen külső szolgáltatást (pl SMTP feletti SPAM-szűrőt) a feladó SMTPS-t használ és ellenőrzi a szerver certjét, a címzett pedig IMAPS-t használ, szintén a certet ellenőrizve. Ebben az esetben az "e-mail" biztonsága kb azonos lenne egy https weblappal. De erre egyszerűen semmilyen garancia nincsen. Még egy gmail-gmail viszonylatban is simán lehet hogy valahol normál SMTP-n is utazik a levél, és onnantól kezdve lőttek az egésznek.

A lényeg: sem az e-mail feladójaként, sem a címzettjeként nincs ráhatásod arra hogy a levél végig biztonságos útvonalon utazik-e, ezért egyszerűen nem tekintheted annak. Jelenleg egyébként a legritkább esetben utazik egy e-mail végig biztonságos csatornán.

Nem.

A Gmail csak az utolsó (küldéskor első) kapcsolat titkosítási állapotát tudja jelezni. Ez nem jelenti sem azt hogy ez a titkosított kapcsolat védett lett volna MITM-el szemben, sem pedig azt hogy a levél nem utazott titkosítatlanul valamelyik másik két levelező szerver között.

Csak akkor véd, ha ellenőrzöd hogy a tanúsítvány a megfelelő névre szól-e. Ez jelenleg mailszerverek között nem szokás, a fentebb kifejtett okok miatt. Kétség kívül két szerver között sokkal nehezebb egy MITM támadást kivitelezni, mint egy user és egy szerver között, és az érvényes tanúsítványok biztonságáról is lehetne vitatkozni, de ez mind egy külön beszélgetés témája lehetne.

Bevallom hogy nem olvastam az X.400 szabványt, de sajnos nem is érdekes: A levelezőszerverek a maximális kompatibilitás miatt hajlandóak titkosítás nélküli kapcsolaton elküldeni a levelet. Erre hivatkozva általában nem ellenőrzik a cert érvényességét mert ha nem érvényes úgyis elküldené a szerver SSL nélkül.

Persze vannak kivételek hiszen a szervereket át lehet konfigurálni. Postfixben pl. fel lehet venni listát azokról a szerverekről amiktől helyes certet várunk el, ide elvileg a rendszergazda felveheti a nagy szolgáltatókat. Nem tudok viszont olyan implementációról ami ezt automatikusan csinálná pl. ha egyszer már volt érvényes cert utána mindig megkövetelné). De vegyük észre azt is hogy ez nem jelent védelmet a DNS-spoofing ellen, mert a certnek csak a szerver nevére kell érvényesnek lenni. Az MX-et hamisítva továbbra is eltéríthető a levél, ez ellen csak a DNSSEC védene, az pedig ismét nem túl elterjedt.

Egy szó mint száz: nem lenne műszaki akadálya hogy TLS-el jól biztosítottak legyenek az e-mailek, de a kompatibilitás az első számú prioritás, és az átállás annyira lassú hogy ez a távoli jövőben sem várható. (A legnagyobb probléma hogy a rendszergazdák nem is igazán motiváltak az átállásra, ebből a szempontból a Google piros lakatja egy nagyon jó és támogatandó kezdeményezés!)

"Egy szó mint száz: nem lenne műszaki akadálya hogy TLS-el jól biztosítottak legyenek az e-mailek, de a kompatibilitás az első számú prioritás, és az átállás annyira lassú hogy ez a távoli jövőben sem várható."

Az én lelkemet tökéletesen megnyugtatja, hogy a google (majdnem minden) levelem alá odaírja hogy Titkosítás: normál TLS.

Igazság szerint nem hiszek neked abban, hogy a google ne tudná hogy mit csinál.

Még egyszer a legfontosabb mondat:
"A Gmail csak az utolsó (küldéskor első) kapcsolat titkosítási állapotát tudja jelezni"

Az emailt ne egy pont-pont kapcsolatként képzeld el, hanem egy hálózatként, ahol sok levél több hoppon át érkezik meg a címzetthez, és akkor beláthatod, hogy miért nem tudhatja a Google mi történt az utolsó hop előtt.

Néztél te már valaha megkapott levél fejlécet? :)

Arról nem is beszélve, hogy még onnan is ki lehet gyomlálni bármit, bármelyik SMTP szerver kénye kedve szerint. Ráadásul a TLS csak a kapcsolatot titkosítja, a levél tartalmát útközben szintén bármelyik SMTP szerver szabadon módosíthatja. A gyakorlatban meg is teszi ezt, legtöbbször ugyan csak valami szarságot hozzáad, nem elvesz, de ez a tényen tulajdonképpen nem változtat: megváltoztatja a leveled tartalmát.

Ezellen véd(ene) a digitális aláírás - amennyiben az emberek képesek lennének használni.

--
zrubi.hu

Jó esetben csak a fejléceket mókolják, és azt is csak hozzáadnak.
Egyébként meg DKIM, aztán a fontosabb fejlécek és a levéltörzsed alá van írva, ha belenyúlnak, azonnal látszik.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Hát azért a levelek nagyrésze az interneten át valóban egy pont-pont átvitellel közlekedik.

Ahogy én nézem a leveleimet, vagy az van, hogy a felhasználó a kliensével feladja egy szervernek (céges vagy szolgáltató), az meg kézbesíti egy másik szervernek, ahol bekerül egy mailboxba, vagy az van, hogy egy cégen/szervezeten belül egy kicsit pingpongoznak a belső szerverek a levéllel, aztán az utolsó belső szerver az interneten át kézbesíti egy másik szervernek, ahol megint csak a belső hálón esetleg jön egy kis pingpong.

Olyasmit, hogy egy levél az internetet többször járja meg, nagyon ritkán látok. Elméletileg persze a beállított MX megkaphatja, ha mondjuk a végső szerver nem fut, de sokszor azt látom, hogy nincs igazi működő MX. Ha nem megy a szerverem, akkor majd a küldő szerveren vár a levél egyszerűen.

Olyasmit még nem láttam, hogy az interneten több hopon keresztül menne egy email (bár hallottam róla, hogy régen volt erre lehetőség, voltak nyílt továbbító gépek, meg be lehetett állítani kézbesítési útvonalat, de szerintem ezeket talán mindet a spam elleni harcban megszűntették)

A többiben egyébként igazad van, akár a saját szerverem vagy a másik oldal szervere is belefirkálhat, ha úgy állította be a rendszergazda (vagy valaki). Ez ellen nem véd.

Szerintem a TLS főleg az ellen véd, hogy az áthaladó levelemet valaki elolvassa, elemezze menet közben. Mondjuk a szolgáltató, vagy valamelyik hopon egy kíváncsi rendszergazda, stb.

vagy az van, hogy egy cégen/szervezeten belül egy kicsit pingpongoznak a belső szerverek a levéllel, aztán az utolsó belső szerver az interneten át kézbesíti egy másik szervernek, ahol megint csak a belső hálón esetleg jön egy kis pingpong.

Hát attól, hogy nem az "interneten", hanem "belső hálón" van több hopp, az engem nem vígasztalna. Ettől még igen erőltetett, (és nagyon nem igaz) hogy ez pont-pont kapcsolat...

Szerintem a TLS főleg az ellen véd, hogy az áthaladó levelemet valaki elolvassa, elemezze menet közben. Mondjuk a szolgáltató, vagy valamelyik hopon egy kíváncsi rendszergazda, stb

Ezek ellen pont nem véd sem a TLS, sem a DKIM.

a TLS a kliensed és az első SMTP szerver között, majd az esetleges további SMTP-SMPT szerverek között "véd", de magukon az SMTP szervereken nem. Tehát minden szolgáltató és kíváncsi rendszergazda szabadon olvasgatja (vagy akár módosítgathatja) a leveleidet.
Arról nem is beszélve, hogy szinte mindenhol opcionális, bármilyen probléma esetén sima SMTP-vel folytatják a levélküldést. (de ezt is már írta valaki koorábban)

a DKIM pedig csak egy domain-t "véd", nem az egyes leveleket. Ez pedig nem saját domain esetén, főleg publikus levelező domainek esetén (mint pl a @gmail.com) elég sovány vigasz.

Szerintem.

--
zrubi.hu

"Hát attól, hogy nem az "interneten", hanem "belső hálón" van több hopp, az engem nem vígasztalna. Ettől még igen erőltetett, (és nagyon nem igaz) hogy ez pont-pont kapcsolat..."

Szerintem nem egy adott szerverben "bízol meg", hanem egy adott szervezetben, értve ezalatt az infrastruktúrát és az üzemeltetőket is. Ebből a szempontból mindegy, hogy adott szervezeten belül 1 vagy több hop van.
Szerk: és egy pont-pont kapcsolatra miért lenne erőltetett, hogy pont-pont kapcsolat?

A többiben egyetértek veled.

Szerintem a TLS főleg az ellen véd, hogy az áthaladó levelemet valaki elolvassa, elemezze menet közben. Mondjuk a szolgáltató, vagy valamelyik hopon egy kíváncsi rendszergazda, stb

Ezek ellen pont nem véd a TLS

a TLS a kliensed és az első SMTP szerver között, majd az esetleges további SMTP-SMPT szerverek között "véd", de magukon az SMTP szervereken nem.

Félreértesz.

Pont azt mondom, hogy az SMTP szerverekben (az én cégem üzemeltetésében és a másik cég üzemeltetésében) megbízom, és közöttük akarom védeni a kíváncsi szemektől.
Tehát ha az én cégem SMTP szervere TLS használatával elküldi a levelet a te céged SMTP szerverének, akkor közben az én szolgáltatóm, a te szolgáltatód, meg az összes közbeeső internet hop gép/rendszergazda nem tud beleolvasni.

Gmail súgó: https://support.google.com/mail/answer/7039474?co=GENIE.Platform%3DAndr…

A titkosítást visszajelző ikon elsődleges célja igazából a nem az hogy téged tájékoztasson, hanem hogy a felhasználókon keresztül nyomást gyakoroljon azokra a rendszer üzemeltetőkre, akik nem TLS képes e-mail szervert használnak.

Vontakozó blogbejegyzés: https://googleblog.blogspot.hu/2014/06/transparency-report-protecting-e…

Azt pedig ne terjeszd kérlek hogy a TLS véd a MITM ellen, mert nem igaz. Az X.509 (tanúsítvány hitelesítés) véd a MITM ellen, de ezt - mint már írtam - a plaintext fallback miatt nem használják SMTP felett. És ha használnák sem jelentene sokat, mert DNS-spoofing még akkor is eljátszható az MX rekordra DNSSEC hiányában, amit szintén nem sok helyen használnak.

És akkor még nem tértünk ki több dologra: például hogy minden útvonalba eső mailszerver (és annak adminisztrátora) azt olvas ki a leveledből amit csak akar, még ha a DNSSEC, az X.509 és a TLS is tökéletesen működik, vagy hogy aki egy szerver-szerver hálózaton MITM-et vagy DNS-spoofingot tud játszani, az simán szerez X.509-es érvényes certet is (lásd: domain-validated).

Talán picit OFF, de hátha nem.

A gmail aztán alaposan kielemzi minden leveled.

Tavaly volt, hogy haver otthoni RPi szerverére "keletkezett" valami php kód amit nem ő rakott fel.
Tömörítette majd átküldte ... én nem láttam a csatolmányt.
Aztán ismét, majd jelszavazva, többszörösen tömörítve jelszavazva, sokféle tömörítő használva mind jelszóval, de nem küldte tovább a gmail sehogy.
Aztán ugyanazon névvel másik file, az átjött.

Kissé elgondolkodtató mi lehet a gmail-nél...
Bár lehet hogy csak tömörítés utáni minta volt ismerős a gmail-nek, de az is jelszón keresztül?

Érdekes.

Nekem rendszeresen olyan levél jön Gmail Team feladóval, hogy xy ilyen olyan subjectű levelet küldött, amiben gyanús csatolmány volt, ezért a gmail ezt a levelet nekem inkább nem továbbította.
De ha akarom, akkor reply és a válaszomat elküldik a küldőnek (vagy valami ilyesmi, sosem választottam ezt).

Szóval nem csak lenyeli szó nélkül.

"Szakmai körökben is időnként hülyén néznek rám, amikor azt mondom, hogy legyen kedves az érzékeny információt nem jelszavazott ZIP fileban küldeni.

Laikusként kérdezem, miért? Vagyis miért baj a jelszavazott ZIP file. (Ha jól értem a mondatot.)

A ZIP titkosító algoritmusa borzalmasan gyenge, pár óra alatt feltörhető különleges hardver nélkül is. (Eleve csak 96 bites lenne, de létezik 2^38 környékére gyengítő támadási módszer).

Ha valamit manapság rendesen titkosítani akarsz, akkor legalább 128 bit, és általában AES vagy CAMELLIA a jó választás.

Ha rendesen van implementalva, eleg LEHET, de ugye tovabbra is van egy jelszava, amit valahogy el kell juttatni a cimzettnek. A titkositas problematikajarol hzsolt94 irt egy igen korrekt kis cikket a Refaktorra. Sztem fusd at, nem harap. :)

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Neked is köszönöm a gyors választ. A jelszó eljuttatása a címzettnek nem gond, telefonon, vagy akár személyesen is megoldható. Herczeg Zsolt cikkét már akkor olvastam, amikor blogbejegyzésedben említetted. Érdekes, de hazudnék ha azt mondanám, hogy számomra minden világos.

Minden kérdést szívesen tisztázunk :-)

A jelszón kívül a másik amire janoszen fel akarta hívni a figyelmed, hogy a 7zip-ben a titkosítás egy extra feature, a GPG e köré épül, ezért jóval nagyobb odafigyelést és biztonsági auditot kap. (Egyébként a GPG is tud szimmetrikus kulcsot használni ha azt szeretnél.)

Ettől függetlenül a 7zip AES titkosítással valószínűleg legalábbis komoly fejfájást okoz ha fel kell törni - a zip-et némi google használattal jó eséllyel bárki fel tudja törni.

Ha már tágítjuk itt a világképet, a rar is AES-128-cal titkosít ha kérjük, szóval az is lehet megfelelő. Kár, hogy sajnos arra is igaz, hogy a titkosítás ebben a programban is csak amolyan mellékes valami - ellentétben a PGP/GPG párossal.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( zrubi v | 2016. 08. 22., h – 14:13 )

Először is a digitális aláírás kliens oldalon történik. Tehát semmi köze a levelezőszerverekhez.

Köze van azonban a következőkhöz:
- a CA, ami általában egy (profit orientált) cég.
- levelező kliens,
- levelező felek hozzáértése.

- X.509 tanúsítvány esetén a CA-nak lenne ugye a feladata, hogy hitelt érdemlően győzzön meg minden felet arról, hogy a tanúsítványamit kiállított, az a valóságnak megfelel. Tehát ha kapsz tőlem egy digitálisan aláírt levelet, akkor biztos lehessél benne, hogy azt valóban én írtam (és a tartalma az átvitel során nem változott!)

- Vagy: GPG-t használsz, és akkor nem kell CA, de cserébe kell "web of trust", aminek a kialakítása ugyan macerásabb lehet, de nincs egy felső hatalom akitől pénzért kell venni a tanúsítványt.

- A levelezőkliensed kell hogy támogassa mindezt. X.509-et még úgy ahogy, GPG-t már csak néhány kliens támogat.
WEBMAIL mindegyik esetben kiesik, hiszen ott a gyakorlatban a titkosítás/aláírás is a szerveren fog történni.

- A legvékonyabb jég viszont mindenképpen a felhasználók hozzá (nem) értése. Még komolynak látszó cégek esetében is szégyenteljes amit ezen a téren művelnek....

Ezek miatt én a gyakorlatban először is tanfolyamot tartanék a levelezésben résztvevőknek, majd ezek után választanék technológiát GPG vs X.509 és ezzel egyetműködő levelező klienseket.
(meglévő infrastruktúra esetén kompromisszumokkal ugyan, de nyilván lehet ahhoz is igazodni)

Szerintem.

--
zrubi.hu

( zrubi v | 2016. 08. 22., h – 14:25 )

mennyire fontos a mai világban?

Open source körökben már régóta elterjedt a GPG használata:
- levelező listákra küldött levelek esetén,
- forráskód aláírása, (pl github signed commit, signed tag)
- hivatalos repók esetében GPG aláírt repo infók, és rpm/deb csomagok,
- telepítő CD Image-ek hitelesítésére,

(MAC-en és windows-on is lehet forszolni a csak aláírt csomagok telepíthetőségét, ám ők leginkább X.509-es tanúsítványokkal bohóckodnak és/vagy szívnak)

Privát levelezésben a hozzáértés hiánya, a mobiltelefonok elterjedése, és a webmail miatt nincs elterjedve - vagy csak nem is tudod hogy valójában megtörténik a háttérben ;)

Szerintem.

--
zrubi.hu

( hnsz2002 v | 2016. 08. 25., cs – 08:26 )

Mi használjuk, de a nagyszerű outlookot használó ügyfelek az első levélváltásnál mindig megkérdezik, hogy mi ez a csatolmány amit küldtem, és nem tud megnyitni? Ennyit erről. Más klienssel még nem volt probléma.
--
The Community ENTerprise Operating System

Lehet abban valami szándékosság, hogy az outlook nem tud PGP-t használni. Az outlook nem egy új program, elég sok verzión ment keresztül. Ha akarták volna, akkor tudtak volna bele tenni PGP támogatást. (Vagy nem gördítettek volna akadályt azok elé akik ilyet akartak hozzá készíteni - biztos vagyok benne, hogy sok lelkes önként jelentkező megcsinálta volna ha hagyták volna...)

A google első találata (szó szerint) a "gnupg outlook" kifejezésre egy open source PGP plugin Outlookhoz. A legelső. Nem a második, nem a harmadik, hanem az első. Rögtön fent az oldal tetején.

szerk: amúgy meg csatlakoznék a fentihez: és? Ha nem is lenne ingyenes plugin, az miért a MS hibája? Tudtommal bárki gyárthat bármilyen plugint az Office programokhoz.