Krótko mówiąc, MTA-STS to sposób na dalszą ochronę wiadomości e-mail przed przechwyceniem (tj. atakami typu man-in-the-middle, czyli MitM) podczas przesyłania między serwerami pocztowymi. Częściowo rozwiązuje dotychczasowe problemy architektoniczne protokołów e-mail i jest opisany w stosunkowo nowym standardzie RFC 8461. Mail.ru jest pierwszą dużą usługą pocztową w RuNet, która implementuje ten standard. I jest to opisane bardziej szczegółowo pod nacięciem.
Jaki problem rozwiązuje MTA-STS?
Historycznie rzecz biorąc, protokoły e-mail (SMTP, POP3, IMAP) przesyłały informacje w postaci zwykłego tekstu, co umożliwiało ich przechwycenie, na przykład podczas uzyskiwania dostępu do kanału komunikacyjnego.
Jak wygląda mechanizm dostarczania listu od jednego użytkownika do drugiego:
Historycznie rzecz biorąc, atak MitM był możliwy we wszystkich miejscach, w których krąży poczta.
RFC 8314 wymaga użycia protokołu TLS pomiędzy aplikacją użytkownika poczty (MUA) a serwerem poczty. Jeśli Twój serwer i aplikacje pocztowe, których używasz, są zgodne z RFC 8314, oznacza to (w dużej mierze) wyeliminowanie możliwości ataków typu Man-in-the-Middle pomiędzy użytkownikiem a serwerami pocztowymi.
Przestrzeganie ogólnie przyjętych praktyk (standaryzowanych przez RFC 8314) eliminuje atak w pobliżu użytkownika:
Serwery pocztowe Mail.ru były zgodne z RFC 8314 jeszcze przed przyjęciem standardu, który tak naprawdę przechwytuje już przyjęte praktyki i nie musieliśmy konfigurować niczego dodatkowego. Jeśli jednak Twój serwer pocztowy w dalszym ciągu pozwala użytkownikom na korzystanie z niepewnych protokołów, pamiętaj o wdrożeniu zaleceń tego standardu, ponieważ Najprawdopodobniej przynajmniej niektórzy z Twoich użytkowników korzystają z poczty bez szyfrowania, nawet jeśli je obsługujesz.
Klient pocztowy zawsze współpracuje z tym samym serwerem pocztowym tej samej organizacji. Możesz także zmusić wszystkich użytkowników do bezpiecznego łączenia się, a następnie uniemożliwić technicznie połączenie się niezabezpieczonym użytkownikom (jest to dokładnie to, czego wymaga RFC 8314). Czasami jest to trudne, ale wykonalne. Ruch pomiędzy serwerami pocztowymi jest jeszcze bardziej skomplikowany. Serwery należą do różnych organizacji i często są używane w trybie „ustaw i zapomnij”, co uniemożliwia jednoczesne przejście na bezpieczny protokół bez przerywania łączności. SMTP od dawna udostępnia rozszerzenie STARTTLS, które umożliwia serwerom obsługującym szyfrowanie przejście na TLS. Jednak osoba atakująca, która ma możliwość wpływania na ruch, może „wyciąć” informację o obsłudze tego polecenia i zmusić serwery do komunikacji przy użyciu protokołu zwykłego tekstu (tzw. atak na obniżenie wersji). Z tego samego powodu STARTTLS zwykle nie sprawdza ważności certyfikatu (niezaufany certyfikat może chronić przed pasywnymi atakami, a to nie jest gorsze niż wysłanie wiadomości w postaci zwykłego tekstu). Dlatego STARTTLS chroni jedynie przed biernym podsłuchiwaniem.
MTA-STS częściowo eliminuje problem przechwytywania listów pomiędzy serwerami pocztowymi, gdy atakujący ma możliwość aktywnego wpływania na ruch. Jeśli domena odbiorcy publikuje politykę MTA-STS, a serwer nadawcy obsługuje MTA-STS, wiadomość e-mail zostanie wysłana wyłącznie za pośrednictwem połączenia TLS, tylko do serwerów określonych w polityce i tylko po weryfikacji certyfikatu serwera.
Dlaczego częściowo? MTA-STS działa tylko wtedy, gdy obie strony zadbały o wdrożenie tego standardu, a MTA-STS nie chroni przed scenariuszami, w których atakujący będzie w stanie uzyskać ważny certyfikat domeny od jednego z publicznych urzędów certyfikacji.
Jak działa MTA-STS
odbiorca
- Konfiguruje obsługę STARTTLS z ważnym certyfikatem na serwerze pocztowym.
- Publikuje politykę MTA-STS poprzez HTTPS; do publikacji wykorzystuje się np. specjalną domenę mta-sts i specjalną, dobrze znaną ścieżkę
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Polityka zawiera listę serwerów pocztowych (mx), które mają prawo odbierać pocztę dla tej domeny. - Publikuje specjalny rekord TXT _mta-sts w DNS z wersją polityki. Kiedy polityka ulegnie zmianie, ten wpis musi zostać zaktualizowany (jest to sygnał dla nadawcy, aby ponownie zapytał o politykę). Na przykład,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Nadawca
Nadawca żąda rekordu DNS _mta-sts i jeśli jest dostępny, wysyła żądanie polityki poprzez HTTPS (sprawdzając certyfikat). Powstała polityka jest buforowana (na wypadek, gdyby atakujący zablokował do niej dostęp lub sfałszował rekord DNS).
Podczas wysyłania poczty sprawdzane jest, czy:
- serwer, na który dostarczana jest poczta, znajduje się w polityce;
- serwer przyjmuje pocztę przy użyciu protokołu TLS (STARTTLS) i posiada ważny certyfikat.
Zalety MTA-STS
MTA-STS wykorzystuje technologie, które są już wdrożone w większości organizacji (SMTP+STARTTLS, HTTPS, DNS). Do wdrożenia po stronie odbiorcy nie jest wymagana żadna specjalna obsługa oprogramowania dla standardu.
Wady MTA-STS
Konieczne jest monitorowanie ważności certyfikatu serwera WWW i poczty, zgodności nazw i terminowego odnawiania. Problemy z certyfikatem spowodują brak możliwości dostarczenia poczty.
Po stronie nadawcy wymagany jest MTA obsługujący zasady MTA-STS; obecnie MTA-STS nie jest domyślnie obsługiwany w MTA.
MTA-STS korzysta z listy zaufanych głównych urzędów certyfikacji.
MTA-STS nie chroni przed atakami, w których atakujący wykorzystuje ważny certyfikat. W większości przypadków MitM w pobliżu serwera oznacza możliwość wystawienia certyfikatu. Taki atak można wykryć za pomocą funkcji Przejrzystość certyfikatu. Dlatego ogólnie MTA-STS ogranicza, ale nie eliminuje całkowicie, możliwość przechwytywania ruchu.
Ostatnie dwa punkty sprawiają, że MTA-STS jest mniej bezpieczny niż konkurencyjny standard DANE dla SMTP (RFC 7672), ale za to bardziej niezawodny technicznie, tj. w przypadku MTA-STS istnieje małe prawdopodobieństwo, że list nie zostanie doręczony ze względu na problemy techniczne spowodowane wdrożeniem standardu.
Konkurencyjny standard - DANE
DANE używa DNSSEC do publikowania informacji o certyfikatach i nie wymaga zaufania do zewnętrznych urzędów certyfikacji, co jest znacznie bezpieczniejsze. Jednak stosowanie DNSSEC znacznie częściej prowadzi do awarii technicznych, jak wynika ze statystyk z kilku lat użytkowania (chociaż generalnie można zaobserwować pozytywny trend w niezawodności DNSSEC i jego wsparciu technicznym). Aby zaimplementować DANE w SMTP po stronie odbiorcy, obecność DNSSEC dla strefy DNS jest obowiązkowa, a prawidłowa obsługa NSEC/NSEC3 jest niezbędna dla DANE, z którym występują problemy systemowe w DNSSEC.
Jeśli DNSSEC nie jest poprawnie skonfigurowany, może to skutkować niepowodzeniem dostarczania poczty, jeśli strona wysyłająca obsługuje DANE, nawet jeśli strona odbierająca nic o tym nie wie. Dlatego pomimo tego, że DANE jest starszym i bezpieczniejszym standardem i jest już obsługiwany w niektórych programach serwerowych po stronie nadawcy, tak naprawdę jego penetracja pozostaje niewielka, wiele organizacji nie jest gotowych na jego wdrożenie ze względu na konieczność wdrożenia DNSSEC, znacznie spowolniło to wdrażanie DANE przez te wszystkie lata, kiedy standard istniał.
DANE i MTA-STS nie kolidują ze sobą i mogą być używane razem.
O co chodzi z obsługą MTA-STS w Mail.ru Mail?
Mail.ru od dłuższego czasu publikuje politykę MTA-STS dla wszystkich głównych domen. Aktualnie wdrażamy część kliencką standardu. W chwili pisania tego tekstu zasady stosowane są w trybie nieblokującym (jeśli doręczenie jest blokowane przez politykę, list zostanie dostarczony przez „zapasowy” serwer bez stosowania polityk), wówczas tryb blokowania zostanie wymuszony dla małej części wychodzącego ruchu SMTP, stopniowo dla 100% ruchu. Obsługiwane jest egzekwowanie zasad.
Kto jeszcze popiera ten standard?
Jak dotąd zasady MTA-STS publikują około 0.05% aktywnych domen, ale mimo to chronią już duży wolumen ruchu pocztowego, ponieważ Standard obsługują najwięksi gracze - Google, Comcast i częściowo Verizon (AOL, Yahoo). Wiele innych usług pocztowych ogłosiło, że obsługa standardu zostanie wdrożona w najbliższej przyszłości.
Jak to na mnie wpłynie?
Nie, chyba że Twoja domena opublikuje zasady MTA-STS. Jeśli opublikujesz tę politykę, e-maile użytkowników Twojego serwera pocztowego będą lepiej chronione przed przechwyceniem.
Jak wdrożyć MTA-STS?
Wsparcie MTA-STS po stronie odbiorcy
Wystarczy opublikować politykę poprzez HTTPS i zapisać w DNS, skonfigurować ważny certyfikat z jednego z zaufanych CA (możliwe jest szyfrowanie) dla STARTTLS w MTA (STARTTLS jest obsługiwany we wszystkich nowoczesnych MTA), bez specjalnego wsparcia ze strony Wymagane jest MTA.
Krok po kroku wygląda to tak:
- Skonfiguruj STARTTLS w używanym MTA (postfix, exim, sendmail, Microsoft Exchange itp.).
- Upewnij się, że używasz ważnego certyfikatu (wydanego przez zaufany urząd certyfikacji, nie wygasł, temat certyfikatu jest zgodny z rekordem MX dostarczającym pocztę dla Twojej domeny).
- Skonfiguruj rekord TLS-RPT, za pośrednictwem którego będą dostarczane raporty aplikacji zasad (przez usługi obsługujące wysyłanie raportów TLS). Przykładowy wpis (dla domeny example.com):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Ten wpis instruuje nadawców poczty, aby wysyłali raporty statystyczne dotyczące użycia TLS w SMTP
[email protected].Monitoruj raporty przez kilka dni, aby upewnić się, że nie ma błędów.
- Opublikuj politykę MTA-STS za pośrednictwem protokołu HTTPS. Polityka jest publikowana w postaci pliku tekstowego z terminatorami wierszy CRLF według lokalizacji.
https://mta-sts.example.com/.well-known/mta-sts.txtPrzykładowa polityka:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Pole Wersja zawiera wersję polityki (obecnie
STSv1), Mode ustawia tryb stosowania polityki, testowanie — tryb testowy (polityka nie jest stosowana), wymuszanie — tryb „walki”. Najpierw opublikuj politykę w trybie: testowanie, jeśli nie ma problemów z polityką w trybie testowym, po chwili możesz przejść do trybu: wymuszanie.W mx określona jest lista wszystkich serwerów pocztowych, które mogą przyjmować pocztę dla Twojej domeny (każdy serwer musi mieć skonfigurowany certyfikat pasujący do nazwy określonej w mx). Max_age określa czas buforowania polityki (gdy zapamiętana polityka zostanie zastosowana, nawet jeśli atakujący zablokuje jej dostarczanie lub uszkodzi rekordy DNS w czasie buforowania, możesz zasygnalizować potrzebę ponownego zażądania polityki, zmieniając DNS mta-sts nagrywać).
- Opublikuj rekord TXT w DNS:
_mta-sts.example.com. TXT “v=STS1; id=someid;”W polu identyfikatora można zastosować dowolny identyfikator (na przykład znacznik czasu). Kiedy polityka ulegnie zmianie, powinna ona zostać zmieniona, co pozwala nadawcom zrozumieć, że muszą ponownie zażądać polityki zapisanej w pamięci podręcznej (jeśli identyfikator jest inny niż identyfikator buforowany).
Obsługa MTA-STS po stronie nadawcy
Póki co jest z nią źle, bo... świeży standard.
- Exim - brak wbudowanej obsługi, istnieje skrypt innej firmy
- Postfix - nie ma wbudowanej obsługi, istnieje skrypt strony trzeciej, który jest szczegółowo opisany na Habré
Jako posłowie o „obowiązkowym TLS”
Ostatnio organy regulacyjne zwracają uwagę na bezpieczeństwo poczty elektronicznej (i to dobrze). Na przykład DMARC jest obowiązkowy dla wszystkich agencji rządowych w Stanach Zjednoczonych i jest coraz bardziej wymagany w sektorze finansowym, gdzie penetracja standardu sięga 90% w obszarach regulowanych. Obecnie niektóre organy regulacyjne wymagają wdrożenia „obowiązkowego TLS” dla poszczególnych domen, ale mechanizm zapewnienia „obowiązkowego TLS” nie jest zdefiniowany i w praktyce ustawienie to często jest wdrażane w sposób, który nawet w minimalnym stopniu nie chroni przed realnymi atakami, które już mają miejsce przewidziane w mechanizmach takich jak DANE czy MTA-STS.
Jeżeli regulator wymaga wdrożenia „obowiązkowego TLS” z osobnymi domenami, jako najodpowiedniejszy mechanizm polecamy rozważyć MTA-STS lub jego częściowy analog, eliminuje to konieczność dokonywania bezpiecznych ustawień dla każdej domeny z osobna. Jeśli masz trudności z wdrożeniem klienckiej części MTA-STS (dopóki protokół nie uzyska szerokiego wsparcia, najprawdopodobniej tak się stanie), możemy polecić następujące podejście:
- Opublikuj politykę MTA-STS i/lub rekordy DANE (DANE ma sens tylko wtedy, gdy w Twojej domenie jest już włączone DNSSEC, a MTA-STS w każdym przypadku), ochroni to ruch w Twoim kierunku i wyeliminuje potrzebę zwracania się do innych usług pocztowych aby skonfigurować obowiązkowy TLS dla Twojej domeny, jeśli usługa pocztowa obsługuje już MTA-STS i/lub DANE.
- W przypadku dużych usług e-mail zaimplementuj „analogowy” MTA-STS poprzez osobne ustawienia transportu dla każdej domeny, co naprawi MX używany do przekazywania poczty i będzie wymagać obowiązkowej weryfikacji certyfikatu TLS dla niego. Jeśli domeny publikują już politykę MTA-STS, prawdopodobnie można to zrobić bezboleśnie. Samo włączenie obowiązkowego TLS dla domeny bez naprawiania przekaźnika i weryfikacji dla niego certyfikatu jest nieskuteczne z punktu widzenia bezpieczeństwa i nie wnosi nic do istniejących mechanizmów STARTTLS.
Źródło: www.habr.com