Forum » Informacijska varnost » SMTP in PKI - avtomatična (ali vsaj on demand) izmenjava public key-ev uporabnikov?
SMTP in PKI - avtomatična (ali vsaj on demand) izmenjava public key-ev uporabnikov?
HotBurek ::
Pozdravljeni.
Danes me iz firbca zanima, kako se postavi sistem, kjer se dva SMTP serverja sporazumeta o izmenjavi public key-ev svojih email uporabnik.
Se pravi, dve firme, vsaka ima svoj SMTP server, vsaka firma ima nekaj uporabnikov. User1 v firmi1 pošlje mail userju2 v firmi2.
Kako se postavi sistem, kjer pred pošiljanjem user1 dobi public key od userja2, in ga uporabi za enkripcijo?
Ter, kako se postavi sistem, da user2, ko prejme pošto, preveri če je signature od userja1 valid?
To dvoje, brez da to uporabnik dela to na roke.
Če bi dal neko vzporednico. Tako kot je autodiscover.xml, kjer lahko vsak dobi informacije za login. (In ja, jasno mi je, da ni isto, ampak gre zgolj za primer, kjer se problem enkrat reši in ne rabi vsak uporabnik nekaj po svoje dodajat/spreminjat.)
Skratka, nekdo postavi PKI. (Like this: Dogtag) What's next? Kako postavit "autodiscover" sistem za SMTP server, da bo vedel, da če pošilja email na domena.com, da mora naredit request na i-dont-know-what.domena.com, kjer bo pointer na nek site, kjer bo jasna struktura, in na koncu seznam fajlov, kateri so public key-i SMTP uporabnikov na tisti domeni?
Danes me iz firbca zanima, kako se postavi sistem, kjer se dva SMTP serverja sporazumeta o izmenjavi public key-ev svojih email uporabnik.
Se pravi, dve firme, vsaka ima svoj SMTP server, vsaka firma ima nekaj uporabnikov. User1 v firmi1 pošlje mail userju2 v firmi2.
Kako se postavi sistem, kjer pred pošiljanjem user1 dobi public key od userja2, in ga uporabi za enkripcijo?
Ter, kako se postavi sistem, da user2, ko prejme pošto, preveri če je signature od userja1 valid?
To dvoje, brez da to uporabnik dela to na roke.
Če bi dal neko vzporednico. Tako kot je autodiscover.xml, kjer lahko vsak dobi informacije za login. (In ja, jasno mi je, da ni isto, ampak gre zgolj za primer, kjer se problem enkrat reši in ne rabi vsak uporabnik nekaj po svoje dodajat/spreminjat.)
Skratka, nekdo postavi PKI. (Like this: Dogtag) What's next? Kako postavit "autodiscover" sistem za SMTP server, da bo vedel, da če pošilja email na domena.com, da mora naredit request na i-dont-know-what.domena.com, kjer bo pointer na nek site, kjer bo jasna struktura, in na koncu seznam fajlov, kateri so public key-i SMTP uporabnikov na tisti domeni?
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
- spremenilo: HotBurek ()
pegasus ::
Na nivoju SMTP? Pozabi, nima absolutno nič s tem.
To delajo ali uporabniki (smime, pgp, gpg) ali pa se admini zmenijo in med firmama potegnejo vpn (ipsec, wireguard) in poskrbijo, da gre smtp promet skozenj.
In tvoj "autodiscover" se zares imenuje DNS. Marsikaj se danes tlači vanj :)
Lahko pa furaš SMTP s TLS in zahtevaš, da se vse povezave (serverji in klienti) na tvoj SMTP avtenticirajo s certifikati, ki jih imaš na whitelisti. To hkrati tudi pomeni, da prejemaš pošto samo z znanih in potrjenih strežnikov, kar močno omeji uporabnost. Je pa v kakih specifičnih "milspec" okoljih zaželjeno.
To delajo ali uporabniki (smime, pgp, gpg) ali pa se admini zmenijo in med firmama potegnejo vpn (ipsec, wireguard) in poskrbijo, da gre smtp promet skozenj.
In tvoj "autodiscover" se zares imenuje DNS. Marsikaj se danes tlači vanj :)
Lahko pa furaš SMTP s TLS in zahtevaš, da se vse povezave (serverji in klienti) na tvoj SMTP avtenticirajo s certifikati, ki jih imaš na whitelisti. To hkrati tudi pomeni, da prejemaš pošto samo z znanih in potrjenih strežnikov, kar močno omeji uporabnost. Je pa v kakih specifičnih "milspec" okoljih zaželjeno.
HotBurek ::
To delajo ali uporabniki (smime, pgp, gpg)...
Ta del sem mislil, če se da avtomatizirat (ali pa naredit on demand).
Recimo, zanimalo me je, da če kdo pošlje email "notri" v tak sistem, da ga SMTP zavrne, če nima vsaj na svoji strani PKI, ter certifikat, s katerim podpiše email. Če pa ga ima, pa, da se v takem sistemu sama (SMTP serverja) zmenta, kaj se potrebuje in kje se najde.
Ta del sem mislil, če se da avtomatizirat (ali pa naredit on demand).
Recimo, zanimalo me je, da če kdo pošlje email "notri" v tak sistem, da ga SMTP zavrne, če nima vsaj na svoji strani PKI, ter certifikat, s katerim podpiše email. Če pa ga ima, pa, da se v takem sistemu sama (SMTP serverja) zmenta, kaj se potrebuje in kje se najde.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Zgodovina sprememb…
- spremenilo: HotBurek ()
pegasus ::
SMTP ne ve nič o vsebini maila (body). SMTP se ukvarja samo s headerji.
Torej moraš implementirat en milter, ki ti bo maile "bral" in SMTP serverju sporočil, ali so kul ali ne. In ta "ali so kul" je lahko poljubno zakompliciran, vključno z vsemi PKI checki, ki jih želiš.
Nariši diagram protokola na papir in na vsakem koraku poglej, katere vse informacije so potrebne za odločanje kako naprej, ter se potem vprašaj, ali je to res nekaj, kar si želiš vzdrževati.
Torej moraš implementirat en milter, ki ti bo maile "bral" in SMTP serverju sporočil, ali so kul ali ne. In ta "ali so kul" je lahko poljubno zakompliciran, vključno z vsemi PKI checki, ki jih želiš.
Nariši diagram protokola na papir in na vsakem koraku poglej, katere vse informacije so potrebne za odločanje kako naprej, ter se potem vprašaj, ali je to res nekaj, kar si želiš vzdrževati.
HotBurek ::
Ampak, a ni škoda, da takega sistem (še) ni?
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
pegasus ::
Ko boš narisal diagram protokola, položi čez še eno prosojnico in označi gor domene odgovornosti, kdo ima kaj čez. To ti bo dalo odgovor, zakaj takega sistema še ni. In ga verjetno tudi nikoli ne bo, vsaj ne na zaupanja vreden način.
HotBurek ::
Zakaj pa ne bi moral temeljit na zaupanju?
Npr. da pošiljatelj diz.ballz@null.com pošlje mail prejemniku troll.master@whitehole.com
Pošiljajoči SMTP server naredi GET request na _signature.smtp.whitehole.com/troll.master, z namenom, da dobi pulic key prejemnika, in s tem key-em zakriptira email, preden ga pošlje.
Ter, prejemajoči SMTP naredi GET request na _signature.smtp.null.com/diz.ballz, z namenom, da dobi pulic key pošiljatelja in preveri veljvavnost podpisa.
Kje bi tu bil problem nezaupanja?
Npr. da pošiljatelj diz.ballz@null.com pošlje mail prejemniku troll.master@whitehole.com
Pošiljajoči SMTP server naredi GET request na _signature.smtp.whitehole.com/troll.master, z namenom, da dobi pulic key prejemnika, in s tem key-em zakriptira email, preden ga pošlje.
Ter, prejemajoči SMTP naredi GET request na _signature.smtp.null.com/diz.ballz, z namenom, da dobi pulic key pošiljatelja in preveri veljvavnost podpisa.
Kje bi tu bil problem nezaupanja?
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Zgodovina sprememb…
- spremenilo: HotBurek ()
pegasus ::
Kakšen problem tu rešuješ?
V tvojem primeru lahko pošiljajoči smtp podpiše s svojim privatnim ključem in z naslovnikovim javnim ključem. Torej lahko prejemnik preveri, da je mail poslal "taprav" server. Kar je pointles, ponavadi želi preveriti, da je mail poslal taprav pošiljatelj.
Poleg tega, kako user objavi svoj public key v _signature.whatever?
Kako izgleda objavljen javni ključ serverja?
Poglej si dkim - domain keys identified system, že implementiran sistem, razvit za preprečevanje ponarejanja pošiljatelja. Mogoče tam dobiš kako idejo.
V tvojem primeru lahko pošiljajoči smtp podpiše s svojim privatnim ključem in z naslovnikovim javnim ključem. Torej lahko prejemnik preveri, da je mail poslal "taprav" server. Kar je pointles, ponavadi želi preveriti, da je mail poslal taprav pošiljatelj.
Poleg tega, kako user objavi svoj public key v _signature.whatever?
Kako izgleda objavljen javni ključ serverja?
Poglej si dkim - domain keys identified system, že implementiran sistem, razvit za preprečevanje ponarejanja pošiljatelja. Mogoče tam dobiš kako idejo.
pegasus ::
Sicer pa podrobno preštudiraj tale evergreen tekst: https://trog.qgl.org/20081217/the-why-y...
Karen ::
Mogoče je po prebranem problem v tem kaj OP sploh želi: eno je avtentikacija pošiljatelja, drugo je šifriranje vsebine maila (torej da pride neprebran s strani tretjega iz točke A v B).
BlaY0 ::
To delajo ali uporabniki (smime, pgp, gpg)...
Ta del sem mislil, če se da avtomatizirat (ali pa naredit on demand).
Recimo, zanimalo me je, da če kdo pošlje email "notri" v tak sistem, da ga SMTP zavrne, če nima vsaj na svoji strani PKI, ter certifikat, s katerim podpiše email. Če pa ga ima, pa, da se v takem sistemu sama (SMTP serverja) zmenta, kaj se potrebuje in kje se najde.
Ampak to o čemer govoriš zares nima nobene zveze s SMTP strežniki ampak kvečjemu s poštnimi odjemalci.
V kontekstu medstrežniške komunikacije že obstajajo protokoli in načini kako se zadevo naredi (bolj) varno... strežnik ki sprejema lahko na nivoju samega povezovanja najprej preveri parametre, ki jih lahko dobi prek DNS-ja, potem recimo preveri še pristnost certifikata s katerim se strežnik ki oddaja predstavi. Če je do tu vse OK (v nasprotnem primeru lahko sprejemni strežnik povezavo enostavno prekine), se začne prenos sporočil, kjer lahko sprejemni strežnik preverja pristnost sprejetih sporočil na nivoju DKIM in DMARC, in se odloči kaj bo z njimi naredil v primeru da ne ustrezajo njegovi varnostni politiki. Od tu dalje je pa vse na samem odjemalcu tako na pošiljateljevi kot tudi na prejemnikovi strani. Odjemalec na prejemnikovi strani ne ve oziroma mu načeloma ni treba vedeti kako sta se strežnika med sabo zmenila, da je sporočilo v končni fazi pristalo v nabiralniku. To je pomembno zato ker lahko sprejemni strežnik tudi spremeni ali pobriše večino zaglavnih parametrov, ki so opisovali prejeto sporočilo in odjemalec za to ne bo vedel.
Drugače pa se dve firmi lahko zmenita in ena drugi "pokažeta" LDAP z javnimi ključi, na katerega se potem povezujejo odjemalci (če to seveda znajo) in jih, če je to potrebno, tudi preverjajo. Outlook/Exchange v navezi z AD to zna, vse kar torej nucaš je proxy cache LDAP povezava na AD strežnik druge firme s katerega pač prvi on-demand "vleče" certifikate.
HotBurek ::
Razmišljal sem v tem kontekstu, da ti nekdo (random) pošlje email, ti kot prejemnik pa bi rad imel zagotovilo, da je to on res bil.
To se reši tako, da pošiljatelj podpiše sporočilo s privat ključem preden ga pošlje, prejemnik pa mora potem preverit, če se public key ujema s potpisanim mailom.
Skratka, ta postopek se, kolikor razumem, danes dela na roke ena po ena. Vedno moraš odgovorit nazaj, izmenjat public key-e, in potem še enkrat poslat originam mail.
To sem razmišljal, če so kakšni načini za avtomatizacijo. Če so kakšni standardi (kot naprimer autodiscover.xml).
To se reši tako, da pošiljatelj podpiše sporočilo s privat ključem preden ga pošlje, prejemnik pa mora potem preverit, če se public key ujema s potpisanim mailom.
Skratka, ta postopek se, kolikor razumem, danes dela na roke ena po ena. Vedno moraš odgovorit nazaj, izmenjat public key-e, in potem še enkrat poslat originam mail.
To sem razmišljal, če so kakšni načini za avtomatizacijo. Če so kakšni standardi (kot naprimer autodiscover.xml).
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
HotBurek ::
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
BlaY0 ::
Razmišljal sem v tem kontekstu, da ti nekdo (random) pošlje email, ti kot prejemnik pa bi rad imel zagotovilo, da je to on res bil.
To se reši tako, da pošiljatelj podpiše sporočilo s privat ključem preden ga pošlje, prejemnik pa mora potem preverit, če se public key ujema s potpisanim mailom.
Skratka, ta postopek se, kolikor razumem, danes dela na roke ena po ena. Vedno moraš odgovorit nazaj, izmenjat public key-e, in potem še enkrat poslat originam mail.
To sem razmišljal, če so kakšni načini za avtomatizacijo. Če so kakšni standardi (kot naprimer autodiscover.xml).
Pa saj sem ti razložil... to je stvar poštnega odjemalca in kako oziroma na kakšen način le to izmenjavo podpira. Outlook/Exchange v navezi z AD to avtomatiko podpira. AD oziroma LDAP je v tem primeru tvoj "keyserver" in z njega Outlook avtomatsko pobira javne x509 certifikate.
Zgodovina sprememb…
- spremenilo: BlaY0 ()
WhiteAngel ::
Ne vem, zakaj bi hotel sploh imel privat LDAP za keyserver? Itak hočeš, da so ključi javni in čim širše dostopni. Uporabiš https://keys.openpgp.org/ ali kaj podobnega, ki je že integriran v Thunderbird in ti kljukico nariše, če je prejet mail verodostojen.
BlaY0 ::
WhiteAngel je izjavil:
Ne vem, zakaj bi hotel sploh imel privat LDAP za keyserver?Zaradi mene je lahko tudi javen. Ni bistveno.
WhiteAngel je izjavil:
Itak hočeš, da so ključi javni in čim širše dostopni. Uporabiš https://keys.openpgp.org/ ali kaj podobnega, ki je že integriran v Thunderbird in ti kljukico nariše, če je prejet mail verodostojen.Če hočeš da ti to dela, potem predpostavljaš, da je pošiljatelj aploudal javni del svojega ključa ravno na tisti key server, ki ga boš ti nastavil v TB-ju. Skratka ni avtomatizma. FYI, dosti teh javnih key serverjev bazira ravno na LDAP direktoriju. Zdaj ali zadaj teče LDAP ali kaj drugega kot rečeno ni bistveno.
Skratka OP je želel, da o tem ali je neko sporočilo pravilno podpisano "presojata" že kar SMTP strežnika, ki komunicirata med sabo, kar je nesmisel. Poleg tega govori o dveh firmah, ki naj bi si na tem nivoju (torej v izmenjavi ključev) delili zaupanje. V tem kontekstu je ena od variant ravno ta, ki sem jo opisal zgoraj. Lahko pa greš še dlje in vzpostaviš pač domain trust, potem pa sploh ni nobenega čaranja več.
HotBurek ::
Skratka OP je želel, da o tem ali je neko sporočilo pravilno podpisano "presojata" že kar SMTP strežnika, ki komunicirata med sabo, kar je nesmisel.
Meni se to zdi smiselno, da se poten n-klientov ne rabi vsak posebej sam s tem ukvarjati.
Iskal sem, ali obstaja kak standard, kjer na svoji strani objaviš public key-e in je ta lokacija standardna (ali pa vsaj postopek preko DNS query-ja, ki ti da pointer).
Meni se to zdi smiselno, da se poten n-klientov ne rabi vsak posebej sam s tem ukvarjati.
Iskal sem, ali obstaja kak standard, kjer na svoji strani objaviš public key-e in je ta lokacija standardna (ali pa vsaj postopek preko DNS query-ja, ki ti da pointer).
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Ales ::
Skratka OP je želel, da o tem ali je neko sporočilo pravilno podpisano "presojata" že kar SMTP strežnika, ki komunicirata med sabo, kar je nesmisel.
Meni se to zdi smiselno, da se poten n-klientov ne rabi vsak posebej sam s tem ukvarjati.
Ravno končni klient je tisti, ki se s čim takim mora ukvarjati. Ne pa nek servis nekje na poti sporočila.
Nisi dovolj razmislil o vsem skupaj. To s podpisovanjem pošte je dolgo obstoječ "problem", vsaj kar se tiče uporabniku prijaznih rešitev. Kar nekaj zelo pametnih ljudi se je ukvarjalo s tem, rezultat je pa... tak, kot je. In to z razlogom!
Prvo, kar naredi je, da vsaj prebereš vse o tej problematiki, sicer boš odkrival toplo vodo.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | e-mail spoofing s telnet povezavo na port 25 SMTP strežnikaOddelek: Omrežja in internet | 2367 (2076) | BlueRunner |
| » | Večina emailov še vedno spamOddelek: Novice / Varnost | 4767 (3356) | Dragi |
| » | Po menjavi ponudnika problem s pošiljanjem pošteOddelek: Omrežja in internet | 5298 (4687) | Matko |
| » | Pipin odprti termin: Kako zavarovati elektronsko pošto pred prestrezanjem?Oddelek: Novice / Kiberpipa | 5418 (4156) | M.B. |