kimenő levél titkosítása/aláírása (postfix)

 ( mogorva | 2019. szeptember 7., szombat - 19:05 )

Hali,

Long story short: ktg csökkentés miatt lemondott mail signing/encrypting appliance funkcionalitását kellene mégiscsak kiváltani FOSS cuccal.
Első körben postfix + gpg adná magát (OS szinte mindegy).

Nem igazán találtam elterjedt megoldást arra, hogy X cég leadja több száz v. ezer alkalmazottja publikus kulcsát és egy dedikált szerver szépen a kimenő leveleket aláírja/titkosítja az adott címzett publikus kulcsával.

Olyat nem szeretnék, hogy több százezer mail-t leteszünk file-ba és egyesével aláírjuk majd kiküldjük.

Valami tapasztalat hasonló ügyben?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A titkosítást nem a szervernek kellene végeznie hanem a kliensnek, én csak így használtam eddig.

Milyen kliensnek?

Pl. egy ThunderBird-nek.

Nincs kliens, Neo.

A százezer alkalmazott telnettel levelez, vagy van közvetlen agyi interfészük a mátrixba?

:D

A telnet annyira elavult, hogy manapság már inkább netcat van telepítve.

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

Nem elavult, hanem audit során visítanak miatta, hogy insecure app, tessen törölni (és ez nem vicc!). Az nc-ről meg szerintem azt hiszik, hogy Péter bátyó örökbecsű fájlkezelője :-D

Ad 1. A gpg/pgp aláírósdi jó, meg szép, meg ilyesmi - de ha a címzett oldal nincs felkészítve az ellenőrzésére, akkor nagyjából olyan, mintha nem lenne.
Ad 2. Ha az aláíráshoz használt titkos kulcshoz harmadik fél is hozzáfér, akkor azt nem igazán tudom hitelesnek elfogadni, ugyanis ebben az esetben nem azt garantálod, hogy az adott üzenetet x.y írta alá, hanem azt, hogy az üzenet aláírásához egy x.y-nak tulajdonított kulcspárt használtak. És innentől kezdve ha x.y. vitatja, hogy azt a levelet ő írta alá, akkor marha nehéz lesz hitelesen bizonyítani, hogy nem az összelapátolt motyó rendszergazdája volt... Úgyhogy nem véletlenül nem találtál ilyen megoldást még...
A titkosítás más kérdés, azt lehet a túloldal publikus kulcsának ismeretében automatice csinálni, de ez is jellemzően kliens oldali feladat.

Oké.

A jelenlegi scenario: ügyfélnek valami stuffja fut nálunk ami neki (az alkalmazottainak) levelet küld (akár naponta több 10 ezret).
Igény, hogy a levél aláírt és/vagy titkosított legyen (nem biztos, hogy az ügyfél már fel van világosítva a különbségről de ez nem fontos).

A titkostáshoz (encryption) az ügyfél ad alkalmazottanként publikus kulcsot, mi azzal titkosítunk, mindenki örül.

Az aláírás (signing) nyilván más, ott a küldő privát kulcsát használjuk és az ügyfél alkalmazottai a küldő publikusával dekriptálnak. Mint az khmm ... közismert ... uram. De jelen fázisban mindegy, hogy a kulcspárt az ügyfél adja, mi generáljuk vagy torrenten találjuk, erre valók a jogászok meg a szerződés. A lényeg, hogy van és megállapodás szerint használni kell. Azon lehet vitatkozni, hogy melyik a jobb megoldás (generáljuk v. kapjuk), amikor egymásra kell majd mutogatni, hogy kitől szivárgott ki a privát kulcs, de ez most mindegy.

De tegyük fel, hogy mindenki érti a scenariokat, vállalja a kockázatot, satöbbi.

Szóval most olyan tool-t keresek, amit be lehet fűzni lehetőleg postfix-be, hogy igény szerint aláírja és/vagy titkosítsa a kimenő mail-eket. (Appliance-ben van ilyen, csak nagyon drága.)

Idézet:
ügyfélnek valami stuffja fut nálunk ami neki (az alkalmazottainak) levelet küld

No, akkor meg is találtuk a klienst. ;-)

Szóval annak a stuffnak kellene aláírnia a leveleket, és ha már vacakol, akkor akár titkosíthatná is őket.

Ha ezt ők nem csinálják meg, akkor az aláírás értelmetlen. A te szervered bármit aláír, akár a hacker gazemberek által küldött emailt is.

A titkosítással kapcsolatban annyi jutott eszembe, hogy ahelyett, hogy több ezer különböző titkos kulccsal titkosítanál napi több 10 ezer levelet (azért ez idő, meg a sávszélességet is eszik), megcsinálhatnátok, hogy egy kulcs számára titkosítotok, és annak a kulcsnak a privát részét megkapja mindenki az ügyfélnél (vagy az ügyfélnél a fogadó szerver azzal az egy kulccsal visszafejti, és a titkosítatlan emailt szórja szét az zászlóaljnak).

Kimenő leveleket nem kellett eddig piszkálnom, de bizonyára úgy működik, hogy találsz egy pontot az architektúrában, ahol minden küldött levél átmegy, leteszel oda egy hookot, és a saját kis scripted gpg parancsot meghívja megcsinálja az aláírást és titkosítást.

Gyors google kereséssel találtam egy példát disclaimer hozzáadására. Meghív egy content filtert, ami egy script, ami megcsinálja neki.
Na, te elindulhatsz ugyanerre csak más scriptet faragsz.

https://www.howtoforge.com/add-disclaimers-to-outgoing-emails-with-altermime-postfix-debian-etch

+1, szerintem nem "aláírás", ha nem "bélyegzés" kell neki, azaz olyan megoldás, ami adott küldő szervezethez kapcsolja a levelt, nem adott személyhez. Ilyesmire fizetősben a Netlock-os Netlock Sign-hoz volt szerencsém, ami -eltekintve attól, hogy a telepítéshez azért szükség volt némi "reszelésre" (telepített (kicsomagolt) app fájljainak a jogosultságait helyrehúzni, systemd-s unitot rendbeszedni/megcsinálni, selinux-os dolgokat hozzáfaragni), teljesen korrekten "bélyegezte" a dokumentumokat - mint amikor a postázóba beérkező levelekre a postázó rányomja az érkeztető stemplit.

Nem.
Az ügyfél akar adni n darab publikus kulcsot.
Ezeket kell felhasználni az alkalmazottai számára küldött levlek titkosítására/aláírására.
Ennyi és nem több és ehhez keresek FOSS megoldást.

Oké, fussunk neki újra, mert ebben az esetben neked nem aláírásra, hanem "bélyegzésre" (szervezet, nem személy általi aláírás) van szükséged kifelé, a titkosítás mellett. A címzett(ek) listájának megfelelő publikus kulcso(ka)t hasnzálva titkosítod a tartalmat, illetve a szervezeti kulcspárral alá is írod, "lebélyegzed", hogy "ezt a levelet az x.y.z cég, mint szervezet küldte".
Csak egy megfelelő hook kel a MTA-ban, ahova becsövezed azokat a kimenő leveleket, amikre ezt el kell végezni, aztán megmogyorózod a levél body részét, oszt' jónapot :-)

Először is szerintem mindegy, hogy aláírásnak vagy bélyegzésnek hívod, ha:
- az "aláírás" biztosítja, hogy az üzenet integritása nem változott,
- a fogadó fél meg tud róla győződni, hogy az "alárás" egy általa megbízhatónak ítélt kulcssal történt.

Működési elvét tekintve ennek valóban így van értelme - ám a gyakorlatban (enterspájz környezetben) mégis sok helyen látom hogy, a usererk kulcsa bizony (kizárólag) a szerverern van, és a kliens csak "jelzi" az aláírás kérelmet. A tényleges aláírást pedig mindig a szerver végzi.

Persze ez így értelmetlen, de úgy tűnik mégis ezt a működési modellt póbálják másolni.

(úgy egyébként nekem az jött le, hogy a topiknyitó nem értelmes megoldás akar, hanem a valahonnan kapott specifikációnak megfelelőt ;)

szerintem.
--
zrubi.hu

na, igen, de ebben az esetben ugy szeretne titositani, hogy a cimzett pub kulcsait az ugyfel adja. Akkor nyilvan kell egy email lista is a hozza parositott pub kulcsokkal is, hogy a titkositott levelet csak az olvashassa akie, illetve kell szabaly is, hogy ha y a cimzett, akkor automatikusan encryptalja a kapott pub key-el (meg kene egy sajat kulcsparnak is lennie, aminek a pub key-e jo lenne, ha a cimzettnel is ott lenne.)

Akkor nyilvan kell egy email lista is a hozza parositott pub kulcsokkal
Ez gyakorlatilag a szerveren lévő gpg kulcsarika. Ez a könnyű, és egyértelmű része a tervezett megoldásnak.

--
zrubi.hu

Vagy a certben lévő e-mail cím ugye... :-p

Ott van, hogy mi alapján nevezem másnak a kettőt: Az aláírás személyhez, a bélyegzés szervezethez kapcsolt, integritást és letagadhatatlanságot biztosító megoldás.
A szerveren tárolt priv.key az lehet, hogy enterspájz, de attól még harmadik fél kezeli a kulcsot, és mivel az adott személynek nincs ráhatása arra, hogy mit írnak alá vele, így bármikor vitatható, hogy egy, kispista nevében aláírt dokumentum valóban tőle származik.
Pont erre szolgál a szervezeti bélyegző cert, ami nem személyhez, hanem szervezethez köti a dokumentumot.

Idézet:
aláírja/titkosítja az adott címzett publikus kulcsával

Aláírni nem publikus, hanem titkos kulccsal tudsz. És nem a címzett kulcsával írsz alá, hanem a feladóéval.

Normális esetben ez úgy megy, hogy én küldök egy emailt neked, az én gépemen van a saját titkos kulcsom, és a kliensem aláírja (az én titkos kulcsommal) és titkosítja (a te publikus kulcsoddal) az emailt, és így megy az útjára.

Azt el tudnám képzelni, hogy a szerver egy céges titkos kulccsal minden kimenő emailt aláír, bizonyítandó, hogy az valóban a cégtől jött. De ehhez persze nem kell az alkalmazottak száz vagy ezer kulcsa.

Ha nem lehet az alkalmazottak levelező klienseit úgy bekonfigurálni, hogy ne lehessen a titkosítást kikapcsolni, és nem bízol meg bennük, hogy nem kapcsolják ki, akkor a titkosítást persze el tudja végezni a szerver is. Ehhez se kell az alkalmazottaid száz vagy ezer kulcsa, a szerver ügyesen meg tudja keresni az email címhez tartozó publikus kulcsot a kulcsszervereken. - Persze én is feltölthetek oda egy olyan publikus kulcsot, amiben a te emailcímed van, és akkor a neked küldött titkosított emailt jól elolvashatom. Pont ezért lenne jobb az, ha az alkalmazottak tudnák, hogy mit csinálnak, a megkapott publikus kulcsot a partnerrel ellenőriznék és utána a kliensen történne a titkosítás.

Rólad az a vicc jut eszembe, amikor az öreg gróf franciatanárt keres a fia mellé.
Kopognak, a kapuban ott áll az öreg béres Jóska bá'.
Kérdezik, mit akar.
- Hallom a gróf úr franciatanárt keres a fia mellé. Csak jöttem szólni, hogy rám ne számítsanak.

Mondod ezt azután, hogy eddig én írtam egyedül konkrét példát, amiből kiindulva simán meg tudod oldani a problémát?

Szerintem töröltesd. :-D

A tahót vagy a bejegyzést?

Nem írtál konkrét példát.

Ha azt mondod, hogy "vedd fel X DB-be (könyvtárba, file-ba, akármibe) a publikus kulcsokat, majd Y módon kösd rá a postfix-et a DB-re és kész", vagy hogy "ott van XYZ alkalmazás (distro repoja, git, sourceforge, akármi), azt lehúzod beálltod örülsz", akkor azt mondom, hogy az konkrétum.

De ez csak okoskodás volt.

Ezt írtam szombaton este:

Idézet:
Gyors google kereséssel találtam egy példát disclaimer hozzáadására. Meghív egy content filtert, ami egy script, ami megcsinálja neki.
Na, te elindulhatsz ugyanerre csak más scriptet faragsz.

https://www.howtoforge.com/add-disclaimers-to-outgoing-emails-with-altermime-postfix-debian-etch

Egy link egy howto leírásra, ami megmutatja, hogyan kell egy saját scriptet futtatni minden kimenő emailre, az nem elég konkrét?

Mit kellett volna még csinálnom, hogy elég konkrét legyen? Bemásolni ide a lépéseket? Lefordítani angolról magyarra?

Ne haragudj, arra nincs időm, hogy le is fejlesszem helyetted.

Azt feltételeztem, hogy képes vagy rákattintani egy linkre és követni egy angolul írt lépésről-lépésre útmutatót.

Szerintem ezt keresed https://github.com/infertux/zeyple

Igen, köszi, ezt láttam (lehet, hogy kapni fog egy esélyt), csak kíváncsi voltam, csinált-e valaki már hasonlót "házilag".
Enterprise környezetben van az az idióta dolog, hogy nem baj, ha van support valami megoldásra.
Attól tartok, erre nincs sok, bár a fejlesztő biztos örülne évente egy nagyobb zsák fabatkának. :)