Kuidas e-post töötab?

Esiteks kasutate e-posti kasutajaagenti või MUA-d oma seadmest e-posti lugemiseks ja saatmiseks (nt gmail või Apple'i seadmete meilirakendus). Need programmid on aktiivsed ainult siis, kui te neid kasutate.

Üldiselt suhtlevad nad e-posti aadressi või MTA-ga (tuntud ka kui meiliserver, MX-host ja postivahetaja), mis on teie e-kirjade vastuvõtmiseks ja säilitamiseks.

E-kirju hoitakse e-posti kontrollimiseks eemalt, kuni MUA avate. E-kirjad edastatakse postisaadetiste (MDA) kaudu, mis on tavaliselt pakendatud koos MTA-ga.

Varem saadeti kiri meiliserverisse, kasutades SMTP-d või lihtsat kirjade edastamise protokolli. SMTP on e-posti suhtlusprotokoll.

Isegi praegu, kui paljud varalised süsteemid nagu Microsoft Exchange ja veebimeili programmid nagu Gmail kasutavad oma protokolle sisemiselt, kasutavad nad SMTP-d sõnumite edastamiseks väljaspool oma süsteemi (näiteks kui Gmaili kasutaja soovib saata meilisõnumi Outlooki kliendile).

Seejärel laaditakse kiri serverist alla postkontoriprotokolli (POP3) abil. POP3 on rakenduskihi protokoll, mis võimaldab kasutajarakendusel Interneti-protokolli (IP) võrgu kaudu juurdepääsu meiliserveri postkastiga ühenduse võtmiseks. Sellega saab ühendust luua, sõnumeid hankida, neid kliendi arvutisse salvestada ja serveris kustutada või säilitada.

See oli loodud selleks, et oleks võimalik hallata ajutisi Interneti-ühendusi, näiteks sissehelistamist (nii et see ühendaks ühenduse ja ühendaks lihtsalt e-posti ning võimaldaks teil võrguühenduseta olevaid kirju vaadata). See oli populaarsem, kui sissehelistamine oli laiemalt levinud.

Nüüd on Interneti-sõnumipääsuprotokoll IMAP enamasti asendanud POP3. IMAP võimaldab mitmel kliendil hallata sama postkasti (nii et saate lugeda oma e-posti oma töölaualt, sülearvutist, telefonist jne ja kõik teie sõnumid on seal, korraldatuna samal viisil).

Lõpuks asendas veebimeil mõlemad. Veebipost võimaldab teil veebisaidile sisse logida ja sõnumeid vastu võtta kõikjalt või mis tahes seadmest (jah!), Kuid selle kasutamise ajal peate olema ühendatud Internetiga. Kui veebisait (nt gmail) on teie MUA, ei pea te teadma SMTP ega IMAP serveri seadeid.

Kuidas e-post on turvatud?

Kahjuks ei olnud turvalisus algusest peale tegelikult postiprotokollidesse sisse ehitatud (nagu enamik algavaid Interneti-protokolle). Serverid eeldasid just, et nad võtavad kelleltki mis tahes sõnumi ja edastavad selle mis tahes muule serverile, mis võiks aidata sõnumit suunata selle lõppsihtkohta (saaja väljale:).

Pole üllatav, et sellest sai teema, kui Internet laienes mõnest valitsuse ja uurimisrühma hulgast selliseks, mida enamik maailma sisuliselt kõike teeb. Üsna pea muutusid (ja jäävad) rämpspostist ja andmepüügimeilidest kõigi jaoks suured probleemid.

Vastuseks oleme püüdnud ühiselt rakendada mitmeid meetmeid, mis takistavad inimestel teiste sõnumeid lugema (krüpteerimine) ja kinnitavad, et sõnumid pärinesid väidetavalt saatjalt (autentimine).  

Enamik kohti kasutab krüptograafilist protokolli TLS (transpordikihi turvalisus, SSL-i asendamine, turvaliste pistikupesade kiht), mis võimaldab krüptimist transiidi ajal. See kaitseb sõnumi edastamise ajal, kuid mitte siis, kui andmed on puhkeasendis (näiteks teie arvutisse salvestatud).

See tagab, et sõnumit ei muudeta ega nuhita selle ajal, kui see MTA-st MTA-sse sõidab. See aga ei kinnita, et sõnumit reisi ajal ei muudetud.

Näiteks kui e-kiri läbib enne lõpliku sihtkohta jõudmist mitu meiliserverit, tagab TLS-i kasutamine, et see on serverite vahel krüptitud, kuid iga server võib sõnumi sisu muuta. Selle lahendamiseks oleme loonud SPF, DKIM ja DMARC.

SPF (saatja poliitika raamistik)

SPF lubab domeeni (nt google.com) omanikul seada oma DNS-is TXT-kirje, mis ütleb, millistel serveritel on lubatud sellest domeenist kirju saata (juhised selle kohta, kuidas seda teha mitmete hostimisteenuste pakkujate jaoks, vaadake seda sait).

Kuidas see töötab?

Selles kirjes on loetletud lubatud seadmed (tavaliselt IP-ga) ja need võivad lõppeda ühe järgmistest valikutest:

-all = Kui kontroll ebaõnnestub (e-posti allikas ei kuulu loetletud seadmete hulka), on tulemuseks HardFail. Enamik postisüsteeme märgib need kirjad rämpspostiks.

? all = = Kui kontroll ebaõnnestub (e-posti allikas ei kuulu loetletud seadmete hulka), on tulemus neutraalne. Seda kasutatakse tavaliselt testimiseks, mitte tootmisdomeenide jaoks.

~ kõik = Kui kontroll ebaõnnestub (e-posti allikas ei kuulu loetletud seadmete hulka), on tulemuseks SoftFail. See tähendab, et see kiri on kahtlane, kuid pole tingimata teadaolev halb. Mõni meilisüsteem märgistab need kirjad rämpspostiks, kuid enamus mitte.

SPF-päised võivad serveritele endile abiks olla, kuna nad töötlevad sõnumeid. Näiteks kui server asub võrgu servas, teab ta, et vastuvõetud sõnumid peaksid tulema saatja SPF-kirje serveritest. See aitab serveritel rämpspostist kiiremini lahti saada. Kuigi see kõlab suurepäraselt, on SPF-iga kahjuks mõned suured probleemid.

  1. SPF ei ütle meiliserverile, mida sõnumiga teha - see tähendab, et sõnum võib ebaõnnestuda SPF-i kontrollimisel ja ikkagi kohale toimetada.
  2. SPF-kirje ei vaata kasutaja nähtavat aadressi, vaid tagasitulekut. Põhimõtteliselt on see samaväärne kirjaga kirjutatud tagastusaadressiga. See ütleb kirjaga tegelevatele postiserveritele, kuhu sõnum tagastada (ja see on salvestatud e-posti päistesse - peamiselt tehnilise teabe serverid kasutavad e-posti töötlemiseks).

    See tähendab, et võin sisestada aadressi kõik, mida tahan, ja see ei mõjuta SPF-i kontrolli. Tegelikult võib häkker mõlema e-posti aadressi suhteliselt võltsida. Kuna krüptimist pole, ei saa SPF-i päiseid täielikult usaldada.

  3. SPF-i andmeid tuleb pidevalt ajakohastada, mis võib olla keeruline suurtes pidevalt muutuvates organisatsioonides.
  4. Edastamine katkestab SPF. Seda seetõttu, et kui e-posti aadressilt, näiteks google.com, saadetakse e-posti aadressile [email protected], jääb ümbriku saatja muutumatuks (saatja aadress ütleb endiselt google.com). Vastuvõttev meiliserver arvab, et väidab end olevat aadressilt google.com, kuid pärineb aadressilt bobsburgers.com, seega nurjub SPF-i kontroll (kuigi kirjad pärinevad tegelikult aadressilt google.com).

SPF-i kohta lisateabe saamiseks vaadake neid artikleid. Siin saate kontrollida, kas konkreetses domeenis on konfigureeritud SPF- ja DMARC-kirjed.

DKIM (domeeninimede tuvastatud meil)

DKIM sarnaneb SPF-iga. See kasutab TXT-kirjeid ka saatva domeeni DNS-is ja pakub teatavat sõnumi enda autentimist. See püüab kontrollida, kas sõnumeid ei muudetud transiidi ajal.

Kuidas see töötab?

Saatev domeen genereerib avaliku / privaatse võtme paari ja paneb avaliku võtme domeeni DNS TXT kirjesse (kui te ei tea, mis on avaliku / privaatse võtme paar, vaadake seda artiklit krüptograafia kohta).

Seejärel kasutavad domeeni meiliserverid (välispiiril - serverid, mis saadavad kirju väljaspool domeeni (nt gmail.com-ist outlook.com-i)) privaatvõtme abil kogu sõnumiosa, sealhulgas päised.

Allkirja genereerimine nõuab tavaliselt teksti räsimist ja krüptimist (selle protsessi kohta lisateabe saamiseks vaadake seda artiklit).

Vastuvõtvad meiliserverid kasutavad DNS TXT-kirje avalikku võtit allkirja dekrüpteerimiseks ning seejärel räsivad kirja ja asjakohased päised (kõik päised, mis loodi siis, kui kiri oli saatja infrastruktuuris - näiteks kui mitu gmaili serverit töötlesid e-kirja enne seda saadeti väliselt aadressile outlook.com).

Seejärel kontrollib server, kas need kaks räsimist sobivad. Kui nad seda teevad, on sõnum tõenäoliselt muutmata (välja arvatud juhul, kui keegi on saatja privaatvõtit ohustanud) ja väidetavalt saatjalt seaduslikult. Kui räsid ei ühti, pole sõnum kas väidetavalt saatjalt või seda on muudetud mõni teine ​​transiidiserver või mõlemad.

DKIM teeb ühe konkreetse ülesande juures väga head tööd - vastates küsimusele „kas seda e-kirja muudeti väidetava saatja kaudu?” See on aga kõik, mida ta teeb. See ei ütle teile, kuidas käituda meilidega, mis selle testi ebaõnnestuvad, milline server võib sõnumit muuta või milliseid muudatusi tehti.  

DKIM-i kasutavad ka mõned Interneti-teenuse pakkujad või Interneti-teenuse pakkujad teie domeeni maine kindlakstegemiseks (kas saadate palju rämpsposti? Kas teil on vähe seotust? Kui sageli teie e-kirjad põrkavad?).

DKIM-i kohta lisateabe saamiseks vaadake seda artiklit. DKIM-kirje saate kinnitada siin.

DMARC (domeenipõhine sõnumi autentimine, aruandlus ja vastavus)

DMARC on sisuliselt juhised postiserveritele SPF- ja DKIM-kirjete käsitsemise kohta. See ei tee ise ühtegi testi, kuid ütleb meiliserveritele, kuidas käituda SPF ja DKIM-i kontrollidega.

Osalevad Interneti-teenuse pakkujad vaatavad avaldatud DMARC-kirjeid ja määravad nende abil kindlaks, kuidas DKIM-i või SPF-i ebaõnnestumistega toime tulla. Nii võib näiteks levinud bränd avaldada DMARC-kirje, mis ütleb, et kui DKIM või SPF ebaõnnestub, loobuge sõnumist.

Sageli saadavad Interneti-teenuse pakkujad teile ka aruandeid teie domeeni tegevuse kohta koos e-posti allikaga ja sellega, kas see läbis / ebaõnnestus DKIM / SPF. See tähendab, et näete, kui inimesed petavad (väidetavalt saadavad) teie domeeni või muudavad teie sõnumeid.

DMARC-i juurutamiseks peate looma DMARC-kirje, mis põhineb teie vajadustel (alates teie e-posti liikluse jälgimisest kuni kõigi teie e-posti allikate välja selgitamiseni kuni toimingute palumiseni, näiteks DKIM-i või SPF-i ebaõnnestunud meilide tagasilükkamine). Selle kohta saate lisateavet siin ja siin.

DMARCi kohta lisateabe saamiseks vaadake seda artiklit. Siin saate kontrollida, kas konkreetses domeenis on konfigureeritud SPF- ja DMARC-kirjed.

Tõmba otsad kokku

Ükski neist turvameetmetest pole täiuslik, kuid koos teevad nad korraliku töö, aidates meil parandada e-posti süsteemide turvalisust kogu maailmas.

Mida rohkem organisatsioone neid meetmeid võtab (kas kasutades avatud lähtekoodiga rakendusi või maksab toote eest), seda parem on kõigil. Pärast protokolli või toote väljatöötamist lisatud turvalisus on tavaliselt kallim, vähem efektiivne ja seda on raskem rakendada kui toote sisseehitatud turvalisus.

Kuid enamik protokolle, millele praegune internet tugineb, olid mõeldud varase Interneti jaoks - väikesele entusiastide, teadlaste ja valitsuse rühmale - mitte ülemaailmne võrk, kus haldame hooneid, nutiseadmeid, ühistransporti, tuumajaamu (!), ja nii edasi.

Seega, kui Internet on jätkuvalt laienenud, peame jätkama kohanemist ja uute viiside väljatöötamist, et kindlustada süsteemid, millele toetume.