Hvordan fungerer e-post?

Først bruker du en e-postbrukeragent eller MUA til å lese og sende e-post fra enheten din (for eksempel gmail eller e-postappen på Apple-enheter). Disse programmene er bare aktive når du bruker dem.

Vanligvis kommuniserer de med en e-postoverføringsagent eller MTA (også kjent som en mailserver, MX-vert og e-postveksler), som tjener til å motta og lagre e-postene dine.

E-post lagres eksternt til du åpner MUA for å sjekke e-posten din. E-post leveres av e-postagenter (MDA), som vanligvis er pakket med MTA.

E-post ble tidligere sendt til en e-postserver ved hjelp av SMTP eller Simple Mail Transfer Protocol. SMTP er en kommunikasjonsprotokoll for e-post.

Selv nå, mens mange proprietære systemer som Microsoft Exchange og webmail-programmer som Gmail bruker sine egne protokoller internt, bruker de SMTP til å overføre meldinger utenfor systemene sine (for eksempel hvis en Gmail-bruker ønsker å sende en e-post til en Outlook-klient).

Mail vil deretter lastes ned fra serveren ved hjelp av Post Office Protocol (POP3). POP3 er en applikasjonslagsprotokoll som gir tilgang via et internettprotokoll (IP) -nettverk for et brukerapplikasjon til å kontakte en postkasse på en postserver. Den kan koble til, hente meldinger, lagre dem på klientens datamaskin og slette eller beholde dem på serveren.

Den var designet for å kunne administrere midlertidige internettforbindelser, for eksempel oppringing (slik at den bare kobler og henter e-post når den er tilkoblet, og lar deg se meldingene når du var offline). Dette var mer populært når oppringt tilgang var mer utbredt.

Nå har IMAP, Internet Message Access Protocol, for det meste erstattet POP3. IMAP kan tillate at flere klienter administrerer den samme postkassen (slik at du kan lese e-posten din fra skrivebordet, den bærbare datamaskinen og telefonen osv., Og alle meldingene dine vil være der, organisert på samme måte).

Til slutt erstattet webmail begge deler. Webmail lar deg logge på et nettsted og motta meldinger hvor som helst eller hvilken som helst enhet (yay!), Men du må være koblet til internett mens du bruker den. Hvis nettstedet (som gmail) er din MUA, trenger du ikke å vite SMTP- eller IMAP-serverinnstillinger.

Hvordan er e-post sikret?

Dessverre var ikke sikkerhet egentlig innebygd i postprotokoller fra begynnelsen (som de fleste internettprotokoller). Serverne forventet bare å ta en melding fra hvem som helst og sende den videre til en hvilken som helst annen server som kan bidra til å rute meldingen til den endelige destinasjonen (mottakeren i til: -feltet).

Ikke overraskende ble dette et problem da internett utvidet seg fra noen få myndigheter og forskningsgrupper til noe det meste av verden bruker for å gjøre i det vesentlige. Ganske snart ble e-post og phishing-e-post (og forblir) et stort problem for alle.

Som svar har vi samlet prøvd å implementere flere tiltak som hindrer folk i å lese andres meldinger (kryptering) og validere at meldinger faktisk kom fra den påståtte avsenderen (godkjenning).  

De fleste steder bruker TLS (transportlagsikkerhet, erstatning for SSL, sikker sokkelag), en kryptografisk protokoll som gir kryptering under transport. Det gir beskyttelse for når meldingen overføres, men ikke når dataene er i ro, (for eksempel å bli lagret på datamaskinen din).

Dette sikrer at en melding ikke blir endret eller snoket på mens den reiser fra MTA til MTA. Dette bekrefter imidlertid ikke at meldingen ikke ble endret under reisen.

For eksempel, hvis e-postmeldingen går gjennom flere e-postservere før den når sitt endelige mål, vil TLS sikre at den blir kryptert mellom serverne, men hver server kan endre innholdet i meldingen. For å løse dette har vi opprettet SPF, DKIM og DMARC.

SPF (Sender Policy Framework)

SPF tillater eieren av et domene (som google.com) å sette en TXT-post i DNS-en som angir hvilke servere som har lov til å sende e-post fra det domenet (for instruksjoner om hvordan du gjør dette for en rekke vertsleverandører, sjekk ut dette nettstedet).

Hvordan virker dette?

Denne posten viser enhetene (vanligvis etter IP) som er tillatt, og kan ende i ett av følgende alternativer:

-all = Hvis sjekken mislykkes (kilden til e-posten er ikke en av de oppførte enhetene), blir resultatet en HardFail. De fleste e-postsystemer vil merke disse meldingene som spam.

? all = = Hvis sjekken mislykkes (kilden til e-posten er ikke en av listene), er resultatet nøytralt. Dette brukes vanligvis til testing, ikke produksjonsdomener.

~ all = Hvis sjekken mislykkes (kilden til e-posten er ikke en av de oppførte enhetene), blir resultatet en SoftFail. Dette betyr at denne meldingen er mistenkelig, men ikke nødvendigvis en kjent dårlig. Noen e-postsystemer vil merke disse meldingene som spam, men de fleste vil ikke.

SPF-overskrifter kan være nyttige for serverne selv, ettersom de behandler meldinger. For eksempel hvis en server er i utkanten av et nettverk, vet den at meldinger den mottar skal komme fra servere i avsenderens SPF-post. Dette hjelper servere å kvitte seg med spam raskere. Selv om dette høres bra ut, er det dessverre noen få store problemer med SPF.

  1. SPF forteller ikke en e-postserver hva de skal gjøre med meldingen - noe som betyr at en melding kan mislykkes i en SPF-sjekk og fortsatt leveres.
  2. En SPF-post ser ikke på "fra" -adressen som brukeren ser, den ser på "returveien". Dette tilsvarer i utgangspunktet returadressen du skriver på et brev. Den forteller e-postservere som håndterer brevet hvor de skal returnere meldingen (og den er lagret i e-postoverskriftene - hovedsakelig teknisk informasjon som servere bruker til å behandle e-post).

    Det betyr at jeg kan sette hva jeg vil i fra: -adressen, og det vil ikke påvirke SPF-sjekken. Faktisk kan begge disse e-postadressene forfalskes relativt av en hacker. Fordi det ikke er noen kryptering involvert, kan ikke SPF-overskrifter være helt klarerte.

  3. SPF-poster må holdes oppdatert, noe som kan være vanskelig i store organisasjoner som endrer seg.
  4. Videresending bryter SPF. Dette er fordi hvis en e-post fra, for eksempel google.com, blir videresendt av [email protected], forblir konvoluttavsenderen uendret (fra-adressen står fortsatt google.com). Den mottatte e-postserveren mener at den hevder å være fra google.com, men kommer fra bobsburgers.com, så den mislykkes SPF-sjekken (selv om e-posten faktisk kommer fra google.com).

For mer lesing om SPF, sjekk ut disse artiklene. Du kan sjekke om et bestemt domene har SPF- og DMARC-poster konfigurert her.

DKIM (DomainKeys Identified Mail)

DKIM ligner SPF. Den bruker også TXT-poster i senderdomenets DNS, og det gir noen autentisering av selve meldingen. Den prøver å gi bekreftelse på at meldinger ikke ble endret under transport.

Hvordan virker dette?

Det sendende domenet genererer et offentlig / privat nøkkelpar og plasserer den offentlige nøkkelen i domenets DNS TXT-post (hvis du ikke vet hva et offentlig / privat nøkkelpar er, sjekk ut denne artikkelen om kryptografi).

Deretter bruker domenets e-postservere (på den ytre grensen - serverne som sender e-post utenfor domenet (f.eks. Fra gmail.com til outlook.com)) den private nøkkelen til å generere en signatur av hele meldingsdelen, inkludert topptekster.

Generering av en signatur krever vanligvis at teksten blir hash og kryptert (for mer informasjon om denne prosessen, sjekk ut denne artikkelen).

Mottak av e-postservere bruker den offentlige nøkkelen i DNS TXT-posten til å dekryptere signaturen og deretter hash meldingen og relevante overskrifter (eventuelle overskrifter som ble opprettet mens e-posten var inne i avsenderens infrastruktur - for eksempel hvis flere gmail-servere behandlet e-posten før den ble sendt eksternt til outlook.com).

Serveren vil da sjekke for å sikre at de to hashene stemmer overens. Hvis de gjør det, er meldingen sannsynligvis uendret (med mindre noen har kompromittert avsenderens private nøkkel) og legitimt fra den påståtte avsenderen. Hvis hasjene ikke stemmer overens, er meldingen ikke fra den påståtte avsenderen, eller den ble endret av en annen server under transport, eller begge deler.

DKIM gjør en veldig god jobb med en veldig spesifikk oppgave - å svare på spørsmålet "ble denne e-postadressen endret under transport eller ikke fra den påståtte avsenderen?". Det er imidlertid alt det gjør. Det forteller deg ikke hvordan du skal håndtere e-post som ikke klarer denne testen, hvilken server som kan ha endret meldingen eller hvilke endringer som ble gjort.  

DKIM brukes også av noen Internett-leverandører, eller Internett-leverandører, for å fastslå omdømmet til domenet ditt (sender du mye spam? Har du lite engasjement? Hvor ofte sprette e-postene dine?).

For mer lesing på DKIM, sjekk ut denne artikkelen. Du kan validere en DKIM-post her.

DMARC (domenebasert meldingsautentisering, rapportering og samsvar)

DMARC er i hovedsak instruksjoner for e-postservere om hvordan du håndterer SPF- og DKIM-poster. Den utfører ingen egne tester, men den forteller e-postservere hvordan de skal håndtere kontrollene som SPF og DKIM utfører.

Deltakende Internett-leverandører vil se på publiserte DMARC-poster og bruke dem til å bestemme hvordan de skal håndtere DKIM eller SPF mislykkes. Så for eksempel kan et ofte spoofed merke publisere en DMARC-post som sier at hvis DKIM eller SPF mislykkes, kan du slippe meldingen.

Ofte vil Internett-leverandører også sende rapporter om domenets aktivitet til deg med e-postkilden og om den passerte / mislyktes DKIM / SPF. Dette betyr at du får se når folk spoofing (påstås å sende fra) domenet ditt eller endrer meldingene dine.

For å implementere DMARC, må du opprette en DMARC-post, basert på dine behov (fra å overvåke e-posttrafikken din for å finne ut hva alle e-postkildene dine er til å be om handlinger, som å avvise e-post som ikke klarer DKIM eller SPF). Du kan lære mer om å gjøre det her og her.

For mer lesing om DMARC, sjekk ut denne artikkelen. Du kan sjekke om et bestemt domene har SPF- og DMARC-poster konfigurert her.

Pakk opp

Ingen av disse sikkerhetstiltakene er perfekte, men sammen gjør de en anstendig jobb med å hjelpe oss med å forbedre sikkerheten til e-postsystemer over hele verden.

Jo flere organisasjoner som vedtar disse tiltakene (enten ved å bruke open source-implementeringer eller betale for et produkt), desto bedre har alle det. Sikkerhet som legges til etter at en protokoll eller et produkt er utviklet, er vanligvis dyrere, mindre effektiv og vanskeligere å implementere enn det innebygd sikkerhet i produktet.

Imidlertid var de fleste protokollene som det nåværende internett er avhengig av designet for det tidlige internett - for en liten gruppe entusiaster, forskere og myndigheter - ikke et verdensomspennende nettverk som vi driver bygninger med, smarte enheter, kollektivtransport, atomkraftverk. (!), og så videre.

Når internett fortsetter å utvide seg, må vi derfor fortsette å tilpasse og utvikle nye måter å sikre systemene vi stoler på.