Jako cyfrowa technologia komunikacyjna poczta e-mail nadal dominuje, a jej użycie stale rośnie. W moim poprzednim poście podkreśliłem wiele jego zalet, ale także nawiązałem do pewnych słabości, których większość użytkowników jest całkowicie nieświadoma.

W tym poście przyjrzymy się tym słabościom bardziej szczegółowo, a konkretnie sposobowi przesyłania wiadomości e-mail między serwerami. Podkreślimy również, w jaki sposób można zaradzić tym niedociągnięciom poprzez częstsze przyjmowanie ustalonych rozszerzeń tradycyjnych protokołów poczty e-mail (np. DANE).

Jak zawsze, ten artykuł jest oparty na moich osobistych badaniach i praktyce w tej dziedzinie, ale dzielenie się wiedzą to współpraca, więc proszę o komentarz lub opinię.

Wstęp

Aby ułatwić zrozumienie, wyróżnię trzy główne fazy nawiązywania połączeń między serwerami pocztowymi.

Wykrywanie serwera pocztowego odbiorców , czyli proces odkrywania, który serwer pocztowy ma przyjmować pocztę dla danej domeny odbiorców.

Połączenie z serwerem pocztowym odbiorców, po zidentyfikowaniu właściwego serwera pocztowego, proces łączenia się z nim i zabezpieczenie połączenia odpowiednim szyfrowaniem (tzw. TLS).

Weryfikacja , czy serwer pocztowy odbiorców jest rzeczywiście właściwy, czy możemy być pewni, że nawiązaliśmy bezpieczne połączenie z legalnym serwerem domeny adresatów.

Wykrywanie serwera pocztowego odbiorców

Najczęściej osiąga się to poprzez wyszukiwanie DNS rekordów MX (Mail Exchange), które wskazują na jeden lub więcej adresów IP serwerów pocztowych, które mają odbierać pocztę dla domeny odbiorców. Istnieją jednak inne mechanizmy, takie jak MTA-STS, rekordy SRV, a nawet rekordy A. Poniżej omówimy niektóre elementy MTA-STS, ale nie podejście do rekordów SRV/A (chociaż mają one te same słabości).

Wykrywanie serwerów pocztowych opiera się na DNS , a zdecydowana większość zapytań DNS nadal opiera się na pakietach UDP, a zatem są one bezpołączeniowe i niezaszyfrowane, dzięki czemu stosunkowo łatwo jest zarówno przechwycić, jak i wstrzyknąć sfałszowane odpowiedzi.

Chociaż istnieją implementacje DNS, które wykorzystują TCP, TLS, a nawet DNS przez HTTPS , są one raczej rzadkie, ale zmniejszają możliwość przechwycenia i wstrzyknięcia między klientem a serwerem.

Chociaż wdrożenie protokołu TCP/TLS koncentruje się na poprawie lub zabezpieczeniu połączenia, same w sobie nie zapewniają mechanizmu zapewniającego, że dane, odpowiedzi na zapytania DNS, są autentyczne i nie zostały naruszone.

W tym miejscu wkracza DNSSEC , zapewnia oparte na zaufaniu podejście do podpisu cyfrowego, które zapewnia, że ​​wszelkie odpowiedzi DNS dla domen z włączoną funkcją DNSSEC mogą zostać zweryfikowane kryptograficznie jako autentyczne i autorytatywne.

A co z DANEM?

• DANE wymaga DNSSEC dla wszystkich wyszukiwań DNS, co skutecznie ogranicza to ryzyko.

• MTA-STS publikuje serwery pocztowe, autorytatywne dla domeny, wymieniając je w pliku zasad MTA-STS hostowanym na serwerze WWW. Chociaż połączenie z samym serwerem WWW może być HTTPS (z weryfikacją certyfikatu), nie wymaga to, aby wyszukiwanie DNS tego serwera WWW było bezpieczne.
• MTA-STS nie nakazuje używania DNSSEC, w rzeczywistości rozumiem, że jedną z jego „cech projektowych” było to, że nie był zależny od DNSSEC.

• Wykrywanie serwera pocztowego domen odbiorców jest zależne od DNS, który bez DNSSEC nie daje pewności co do otrzymanych odpowiedzi.
• DANE nakazuje stosowanie DNSSEC, więc jako rozszerzenie SMTP jest to najskuteczniejszy mechanizm zapewniający ochronę przed tym ryzykiem.
• MTA-STS nie wymaga stosowania DNSSEC i pomimo hostowania zasad na serwerze zabezpieczonym HTTPS, nadal opiera się na tradycyjnym wyszukiwaniu DNS.
• Jednak MTA-STS można wdrożyć z DNSSEC, co znacznie ograniczyłoby to ryzyko. To byłaby moja rekomendacja, jeśli jesteś w trakcie wdrażania MTA-STS.

Świat przeszedł na HTTPS w mgnieniu oka. Obecnie bardzo rzadko można znaleźć jakąkolwiek witrynę internetową, która nie obsługuje protokołu HTTPS (nawet taką, która nie przyjmuje danych karty kredytowej). Jednak e-mail nie odnotował takiej samej zmiany w zakresie bezpieczeństwa i nadal opiera się na czymś, co nazywamy „oportunistycznym TLS”. W oportunistycznym TLS serwery najpierw nawiążą niezabezpieczone połączenie, a następnie spróbują wynegocjować i uaktualnić połączenie do TLS, ale z radością będą kontynuować bez TLS, jeśli z jakiegokolwiek powodu nie mogą się zgodzić.

Prawdziwy problem polega na tym, że „Opportunistic TLS” początkowo otwiera niezabezpieczone połączenie i aktualizuje je do TLS (inicjowane metodą STARTTLS). Dlatego stosunkowo łatwo jest przechwycić takie połączenie i uniemożliwić aktualizację do TLS poprzez maskowanie obsługi STARTTLS ze zdalnego serwera. Oportunistyczne serwery pocztowe TLS będą następnie kontynuować wymianę wiadomości e-mail bez opieki i uwagi. Co gorsza, ani nadawca, ani odbiorcy nie byliby choćby w najmniejszym stopniu świadomi, że tak się stało.

Obie strony w połączeniu TLS wykorzystują certyfikaty PKI, które mogą być również wykorzystywane do zapewnienia dodatkowego poziomu zaufania, że ​​strony rzeczywiście są tymi, za które się podają, i które można niezależnie zweryfikować za pomocą kotwicy zaufania . Jednak biorąc pod uwagę, jak łatwo jest uzyskać certyfikaty od dostawców takich jak LetsEncrypt, staje się to mniej niezawodne.

W praktyce zdecydowana większość serwerów pocztowych obsługuje jakąś formę TLS, więc istnieje duże prawdopodobieństwo, że Twoja wiadomość e-mail została zaszyfrowana podczas przechodzenia przez Internet do miejsca docelowego. Nie dotyczy to jednak ryzyka ataku MITM maskującego obsługę TLS i zezwalającego na niezaszyfrowane połączenia.

A co z MTA-STS?

• MTA-STS rozwiązuje to ryzyko poprzez (i zakładając, że nie jesteś w trybie „testowania”) pośrednio wymagając ustanowienia połączenia TLS w celu wymiany wiadomości e-mail.

• DANE wymusza niejawny wymóg połączenia TLS, a tym samym ogranicza to ryzyko.

• Oportunistyczny TLS opiera się na niezaszyfrowanym połączeniu w celu ustalenia możliwości uaktualnienia do TLS, a zatem jest podatny na atak MITM.
• Zarówno DANE, jak i MTA-STS domyślnie wymagają połączenia TLS przed wymianą wiadomości e-mail, więc skutecznie zapewniają ustanowienie przynajmniej podstawowego połączenia TLS.
• Sam TLS nie wystarczy, aby zasugerować, że połączenie jest wystarczająco zabezpieczone/szyfrowane. Wiele protokołów i zestawów szyfrów zaimplementowanych w TLS jest uważanych za niepewne (brute forcable). Jest to temat sam w sobie, który omówimy w późniejszym artykule.

Jest to prawdopodobnie krok w procesie ustanawiania bezpiecznego połączenia między serwerami pocztowymi. Jednak moim zdaniem jest to tak ważny element, że zasługuje na osobną sekcję.

Uznając zależność od poprzednich faz, niezbędne staje się dalsze sprawdzanie, czy serwer, z którym się łączymy, jest rzeczywiście serwerem autorytatywnym dla domeny odbiorców. Poprzednia faza opisywała ustanawianie połączenia TLS, które może obejmować weryfikację certyfikatu lub nie. Jednak generalnie wszystko, co zwykle robi weryfikacja certyfikatu, polega na sprawdzeniu, czy dana nazwa hosta jest zgodna z nazwą hosta wyszczególnioną w certyfikacie na serwerze zdalnym i opcjonalnie, czy można ją powiązać z kotwicą zaufania.

DANE idzie o krok dalej, publikując rekord TLSA zabezpieczony DNSSEC, który zawiera odcisk palca (i metodę weryfikacji) dla danego certyfikatu serwera pocztowego. Zapewnia to niezawodną i ostateczną weryfikację, która kategorycznie zapewnia, że ​​serwer, z którym się łączysz, przedstawia określony certyfikat rozpoznawany przez administratora DNS.

A co z DANEM?

• Weryfikacja certyfikatu serwera na podstawie rekordu TLSA zabezpieczonego DNSSEC jest nieodłącznym elementem DANE i stanowi ostateczną pieczęć zatwierdzenia w celu zapewnienia połączenia.

• MTA-STS nie idzie tak daleko, jego celem jest zapewnienie, że połączenie TLS jest obowiązkowe i nie obejmuje sprawdzania uprawnień serwerów pocztowych.

Moim zdaniem nie ma racjonalnego powodu, dla którego te słabości miałyby pozostać nienaruszone u większości dostawców usług pocztowych. Technologia istnieje, aby im sprostać i jest stosunkowo łatwa do wdrożenia w dzisiejszych czasach. Zakładam, że brak świadomości ze strony konsumentów usuwa wiele zachęt dla dostawców usług pocztowych do wdrażania tych technologii.

MTA-STS zapewnia kilka kluczowych ulepszeń w kwestiach związanych z oportunistycznym TLS, ale nie posuwa się wystarczająco daleko, aby wyeliminować wszystkie słabości. Dodanie DNSSEC do MTA-STS zmniejsza niektóre zagrożenia i byłoby moją rekomendacją (jeśli DANE nie jest dla ciebie opcją).

DANE zapewnia jednak kompleksowe rozwiązanie słabych punktów omówionych w tym artykule. Jeśli rozważasz zarówno MTA-STS, jak i DANE, ale chcesz wybrać tylko jeden, to DANE byłby moją rekomendacją.

Na całym świecie zarejestrowanych jest około 365 milionów nazw domen, a tylko 3,7 miliona domen ma wdrożony DANE (około 1%).

Jeśli spojrzymy na największych dostawców poczty, zauważymy, że Gmail wdrożył MTA-STS, ale jeszcze nie wdrożył DANE ani nawet DNSSEC.

Podobnie Microsoft wdrożył MTA-STS w Exchange Online w tym roku i ogłosił zamiar oferowania DANE w przyszłości, ale prawdopodobnie minie jeszcze kilka lat, zanim będą obsługiwać go zarówno w ruchu wychodzącym, jak i przychodzącym.