Как работи електронната поща?

Първо, използвате пощенски потребителски агент или MUA, за да четете и изпращате имейли от вашето устройство (като gmail или приложението за поща на устройства на Apple). Тези програми са активни само когато ги използвате.

Като цяло те комуникират с агент за прехвърляне на поща или MTA (известен също като пощенски сървър, MX хост и обменник на поща), който служи за получаване и съхраняване на имейлите ви.

Имейлите се съхраняват дистанционно, докато не отворите MUA, за да проверите имейла си. Имейлите се доставят от агенти за доставка на поща (MDA), които обикновено са пакетирани с MTA.

Пощата се изпращаше до пощенски сървър чрез SMTP или Simple Mail Transfer Protocol. SMTP е комуникационен протокол за електронна поща.

Дори и сега, докато много собствени системи като Microsoft Exchange и програми за уеб поща като Gmail използват собствени протоколи вътрешно, те използват SMTP за прехвърляне на съобщения извън своите системи (например, ако потребител на Gmail иска да изпрати имейл до клиент на Outlook).

След това пощата ще бъде изтеглена от сървъра с помощта на Post Office Protocol (POP3). POP3 е протокол на ниво приложение, който осигурява достъп чрез мрежа от интернет протокол (IP) на потребителско приложение за връзка с пощенска кутия на пощенски сървър. Той може да се свързва, да извлича съобщения, да ги съхранява на компютъра на клиента и да ги изтрива или запазва на сървъра.

Проектиран е, за да може да управлява временни интернет връзки, като например комутируема връзка (така че просто да се свързва и извлича имейл, когато е свързан, и ви позволява да преглеждате съобщенията, когато сте били офлайн). Това беше по-популярно, когато комутируемият достъп беше по-широко разпространен.

Сега IMAP, протоколът за достъп до интернет съобщения, най-вече замени POP3. IMAP може да позволи на множество клиенти да управляват една и съща пощенска кутия (така че можете да четете имейлите си от вашия работен плот, лаптоп и телефон и т.н. и всичките ви съобщения ще бъдат там, организирани по същия начин).

В крайна сметка уеб пощата замени и двете. Уеб пощата ви позволява да влезете в уебсайт и да получавате съобщения от всяко място или от всяко устройство (да!), Но трябва да сте свързани с интернет, докато го използвате. Ако уебсайтът (като gmail) е вашият MUA, не е необходимо да знаете настройките на SMTP или IMAP сървъра.

Как е защитен имейл?

За съжаление сигурността всъщност не беше вградена в пощенските протоколи от самото начало (както повечето начални интернет протоколи). Сървърите току-що са очаквали да вземат всяко съобщение от всеки и да го предадат на всеки друг сървър, който може да помогне за насочването на съобщението до крайната му цел (получателя в полето до:).

Не е изненадващо, че това стана проблем, когато интернет се разшири от няколко правителствени и изследователски групи в нещо, което повечето от света използват, за да правят по същество всичко. Съвсем скоро имейлите за спам и фишинг станаха (и остават) огромен проблем за всички.

В отговор ние се опитахме да приложим няколко мерки, които пречат на хората да четат чужди съобщения (криптиране) и потвърждаваме, че съобщенията действително идват от предполагаемия подател (удостоверяване).  

Повечето места използват TLS (защита на транспортния слой, заместването на SSL, слой със защитени сокети), криптографски протокол, който осигурява криптиране при транзит. Той осигурява защита, когато съобщението се предава, но не и когато данните са в покой (например, съхранявани на вашия компютър).

Това гарантира, че съобщението не се променя или прослушва, докато пътува от MTA до MTA. Това обаче не потвърждава, че съобщението не е променено по време на пътуването.

Например, ако имейлът преминава през множество пощенски сървъри, преди да достигне крайната си цел, използването на TLS ще гарантира, че е криптиран между сървърите, но всеки сървър може да промени съдържанието на съобщението. За да се справим с това, създадохме SPF, DKIM и DMARC.

SPF (Рамка на политиката за изпращане)

SPF позволява на собственика на домейн (като google.com) да зададе TXT запис в своя DNS, който посочва кои сървъри имат право да изпращат поща от този домейн (за инструкции как да направите това за различни хостинг доставчици вижте това сайт).

Как работи това?

Този запис изброява разрешените устройства (обикновено по IP) и може да завърши с една от следните опции:

-all = Ако проверката не успее (източникът на имейла не е едно от изброените устройства), резултатът е HardFail. Повечето пощенски системи ще маркират тези съобщения като спам.

? all = = Ако проверката не успее (източникът на имейла не е едно от изброените устройства), резултатът е неутрален. Това обикновено се използва за тестване, а не за производствени домейни.

~ all = Ако проверката не успее (източникът на имейла не е едно от изброените устройства), резултатът е SoftFail. Това означава, че това съобщение е подозрително, но не е непременно известно лошо. Някои пощенски системи ще маркират тези съобщения като спам, но повечето не.

SPF заглавията могат да бъдат полезни за самите сървъри, тъй като те обработват съобщения. Например, ако сървърът е на ръба на мрежата, той знае, че съобщенията, които получава, трябва да идват от сървъри в записа на SPF на подателя. Това помага на сървърите да се отърват от спама по-бързо. Макар това да звучи чудесно, за съжаление има няколко основни проблема със SPF.

  1. SPF не казва на пощенския сървър какво да прави със съобщението - което означава, че съобщението може да се провали при проверка на SPF и все пак да бъде доставено.
  2. Записът на SPF не гледа адреса „от“, който потребителят вижда, а „пътя на връщане“. По принцип това е еквивалентът на адреса за връщане, който пишете в писмо. Той казва на пощенските сървъри, които обработват писмото, къде да върнат съобщението (и то се съхранява в заглавките на имейлите - по същество сървърите за техническа информация използват за обработка на имейли).

    Това означава, че мога да поставя каквото пожелая в адреса от: и това няма да повлияе на проверката на SPF. Всъщност и двата имейл адреса могат да бъдат сравнително подправени от хакер. Тъй като няма включено криптиране, заглавките на SPF не могат да бъдат напълно надеждни.

  3. Записите на SPF трябва постоянно да се актуализират, което може да бъде трудно в големи, постоянно променящи се организации.
  4. Препращане прекъсва SPF. Това е така, защото ако имейл от, да речем google.com, бъде препратен от [email protected], подателят на плика остава непроменен (адресът от from все още казва google.com). Получаващият пощенски сървър смята, че твърди, че е от google.com, но идва от bobsburgers.com, така че не успява да провери SPF (въпреки че пощата всъщност идва от google.com).

За повече четене на SPF разгледайте тези статии. Можете да проверите дали определен домейн има конфигурирани SPF и DMARC записи тук.

DKIM (DomainKeys Identified Mail)

DKIM е подобен на SPF. Той използва TXT записи и в DNS на изпращащия домейн и осигурява известно удостоверяване на самото съобщение. Той се опитва да осигури потвърждение, че съобщенията не са били променяни при транспортиране.

Как работи това?

Изпращащият домейн генерира двойка публичен / частен ключ и поставя публичния ключ в DNS TXT записа на домейна (ако не знаете какво представлява двойката публичен / частен ключ, вижте тази статия за криптографията).

След това пощенските сървъри на домейна (на външната граница - сървърите, които изпращат поща извън домейна (напр. От gmail.com до outlook.com)) използват частния ключ, за да генерират подпис на цялото тяло на съобщението, включително хедъри.

Генерирането на подпис обикновено изисква хеширането и криптирането на текста (за повече подробности относно този процес вижте тази статия).

Получаващите пощенски сървъри използват публичния ключ в DNS TXT записа, за да дешифрират подписа и след това хешират съобщението и съответните заглавки (всички заглавки, създадени, докато пощата е била в инфраструктурата на подателя - например ако множество gmail сървъри са обработили имейла преди него е изпратено външно до outlook.com).

След това сървърът ще провери дали двете хешове съвпадат. Ако го направят, съобщението вероятно е непроменено (освен ако някой не е компрометирал личния ключ на подателя) и законно от предполагаемия подател. Ако хешовете не съвпадат, съобщението или не е от предполагаемия подател, или е било променено от друг транзитен сървър, или и двете.

DKIM върши много добра работа при една много специфична задача - отговаряйки на въпроса „този имейл ли е бил променен по време на транспортиране или не от предполагаемия подател?“. Това обаче е всичко, което прави. Не ви казва как да се справяте с имейли, които не са успели при този тест, кой сървър може да е променил съобщението или какви промени са направени.  

DKIM се използва и от някои доставчици на интернет услуги или доставчици на интернет услуги, за да определят репутацията на вашия домейн (изпращате ли много спам? Имате ли ниска ангажираност? Колко често имейлите ви отскачат?).

За повече четене на DKIM разгледайте тази статия. Можете да проверите DKIM запис тук.

DMARC (Удостоверяване на съобщения на базата на домейн, отчитане и съответствие)

DMARC е по същество инструкции за пощенски сървъри как да се справят със SPF и DKIM записи. Той не извършва собствени тестове, но казва на пощенските сървъри как да се справят с проверките, които SPF и DKIM извършват.

Участващите доставчици на интернет услуги ще разгледат публикуваните записи на DMARC и ще ги използват, за да определят как да се справят с DKIM или SPF се провалят. Така например, често подправена марка може да публикува DMARC запис, който казва, че ако DKIM или SPF не успеят, пуснете съобщението.

Често доставчиците на интернет също ще ви изпращат отчети за активността на вашия домейн с източник на имейла и дали той е преминал / не е успял DKIM / SPF. Това означава, че ще можете да видите кога хората подправят (претендират да изпращат) вашия домейн или променят вашите съобщения.

За да внедрите DMARC, трябва да създадете DMARC запис, въз основа на вашите нужди (от наблюдение на вашия имейл трафик, за да разберете какви са всичките ви имейл източници до искане да се предприемат действия, като отхвърляне на всички имейли, които се провалят DKIM или SPF). Можете да научите повече за това тук и тук.

За повече четене на DMARC разгледайте тази статия. Можете да проверите дали определен домейн има конфигурирани SPF и DMARC записи тук.

Увийте

Нито една от тези мерки за сигурност не е перфектна, но заедно вършат прилична работа, като ни помагат да подобрим сигурността на имейл системите в световен мащаб.

Колкото повече организации приемат тези мерки (или използвайки внедряване с отворен код, или плащайки за продукт), толкова по-добре ще бъдат всички. Сигурността, добавена след разработване на протокол или продукт, обикновено е по-скъпа, по-малко ефективна и по-трудна за изпълнение, отколкото е вградената в продукта сигурност.

Повечето протоколи, на които разчита настоящият интернет обаче, са създадени за ранния интернет - за малка група ентусиасти, учени и държавни служители - а не за световна мрежа, в която управляваме сгради, интелигентни устройства, обществен транспорт, ядрени централи (!), и така нататък.

Поради това, тъй като интернет продължава да се разширява, трябва да продължим да се адаптираме и да разработваме нови начини за осигуряване на системите, на които разчитаме.