Krótko mówiąc, MTA-STS to sposób na dodatkową ochronę wiadomości przed przechwyceniem (tj. atakiem człowiek-w-środku, znanym również jako MitM) podczas przesyłania między serwerami pocztowymi. Częściowo rozwiązuje dziedziczone problemy architektoniczne protokołów poczty elektronicznej i jest opisany w stosunkowo nowym standardzie RFC 8461. Mail.ru to pierwsza duża usługa pocztowa w Runecie, która wdrożyła ten standard. O szczegółach opowiemy poniżej.
Jakie problemy rozwiązuje MTA-STS?
Historycznie, protokoły poczty elektronicznej (SMTP, POP3, IMAP) przesyłały informacje w otwartym formacie, co umożliwiało ich przechwytywanie, na przykład podczas dostępu do kanału komunikacyjnego.
Jak wygląda mechanizm dostarczania wiadomości od jednego użytkownika do drugiego:
Historycznie, atak MitM mógł mieć miejsce w każdym miejscu, gdzie przesyłana była poczta.
Standard RFC 8314 wymaga obowiązkowego stosowania TLS pomiędzy programem pocztowym użytkownika (MUA) a serwerem pocztowym. Jeśli Twój serwer i używane aplikacje pocztowe są zgodne z RFC 8314, to (w dużej mierze) wyeliminowałeś możliwość ataków człowiek-w-środku między użytkownikiem a serwerami pocztowymi.
Przestrzeganie powszechnie przyjętych praktyk (standardy RFC 8314) eliminują atak w pobliżu użytkownika:
Serwery pocztowe Mail.ru były zgodne z RFC 8314 już przed przyjęciem standardu, w rzeczywistości tylko dokumentował on już przyjęte praktyki, więc nie musieliśmy nic dodatkowo konfigurować. Jednak jeśli Twój serwer pocztowy wciąż pozwala użytkownikom korzystać z niebezpiecznych protokołów, koniecznie wdroż zalecenia tego standardu, ponieważ prawdopodobnie przynajmniej część Twoich użytkowników korzysta z poczty bez szyfrowania, nawet jeśli je wspierasz.
Klient pocztowy zawsze łączy się z tym samym serwerem pocztowym tej samej organizacji. Można wymusić na wszystkich użytkownikach bezpieczne połączenie, a następnie sprawić, że niemożliwe będzie połączenie w sposób niesekretny (to właśnie wymaga RFC 8314). To czasami bywa trudne, ale wykonalne. Ruch między serwerami pocztowymi jest jeszcze bardziej skomplikowany. Serwery należą do różnych organizacji i często działają w trybie 'postaw i zapomnij', co uniemożliwia jednoczesne przełączenie na bezpieczny protokół bez zakłóceń. W SMTP już od dłuższego czasu istnieje rozszerzenie STARTTLS, pozwalające serwerom wspierającym szyfrowanie przełączyć się na TLS. Jednak atakujący, który ma możliwość wpływania na ruch, może 'wyciąć' informacje o wsparciu tej komendy i zmusić serwery do komunikowania się za pomocą zwykłego tekstowego protokołu (tzw. atak downgrade — atak na obniżenie wersji protokołu). Z tego samego powodu dla STARTTLS zazwyczaj nie sprawdza się zgodności certyfikatu (niewiarygodny certyfikat może chronić przed pasywnymi atakami, co nie jest gorsze niż wysłanie wiadomości w czystym tekście). Dlatego STARTTLS chroni tylko przed pasywnym podsłuchiwaniem.
MTA-STS częściowo rozwiązuje problem przechwytywania wiadomości między serwerami pocztowymi, kiedy atakujący ma możliwość aktywnego wpływania na ruch. Jeśli domena odbiorcy publikuje politykę MTA-STS, a serwer nadawcy wspiera MTA-STS, będzie wysyłać wiadomości tylko przez połączenie 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 ma możliwość uzyskania ważnego certyfikatu domeny w jednym z publicznych CA.
Jak działa MTA-STS
Odbiorca
- Ustala wsparcie dla STARTTLS z ważnym certyfikatem na serwerze pocztowym.
- Publikuje politykę MTA-STS przez HTTPS, do publikacji używa się specjalnej domeny mta-sts oraz specjalnej ścieżki well-known, na przykład
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Polityka zawiera listę serwerów pocztowych (mx) mających prawo odbierać pocztę dla tej domeny. - Publikuje specjalny wpis TXT _mta-sts w DNS z wersją polityki. Przy zmianie polityki ten wpis musi być zaktualizowany (sygnalizuje to nadawcy konieczność ponownego zażądania polityki). Na przykład,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Nadawca
Nadawca żąda wpisu DNS _mta-sts, a w przypadku jego obecności wykonuje żądanie polityki przez HTTPS (sprawdzając certyfikat). Otrzymana polityka jest buforowana (na wypadek, gdyby atakujący zablokował do niej dostęp lub podmienił wpis DNS).
Podczas wysyłania poczty sprawdzane jest, że:
- serwer, na który dostarczana jest poczta, znajduje się w polityce;
- serwer akceptuje pocztę z użyciem TLS (STARTTLS) i ma 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). Aby zrealizować to po stronie odbiorcy, nie jest wymagana specjalna obsługa programowa standardu.
Wady MTA-STS
Należy monitorować ważność certyfikatu serwera WWW i pocztowego, zgodność nazw oraz terminowe aktualizacje. Problemy z certyfikatem mogą prowadzić do niemożności dostarczenia poczty.
Po stronie nadawcy wymagana jest MTA z obsługą polityk MTA-STS, w chwili obecnej „prosto z pudełka” MTA-STS nie jest obsługiwane w MTA.
MTA-STS wykorzystuje listę zaufanych głównych CA.
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ść wydania certyfikatu. Taki atak może być wykryty dzięki Certificate Transparency. Dlatego ogólnie, MTA-STS łagodzi, ale nie eliminuje całkowicie możliwości przechwycenia ruchu.
Dwa ostatnie punkty sprawiają, że MTA-STS jest mniej bezpieczny niż konkurencyjny standard DANE dla SMTP (RFC 7672), ale bardziej technicznie niezawodny, tzn. dla MTA-STS jest niskie prawdopodobieństwo, że wiadomość nie zostanie dostarczona z powodu problemów technicznych spowodowanych wdrożeniem standardu.
Konkurencyjny standard — DANE
DANE wykorzystuje DNSSEC do publikacji informacji o certyfikatach i nie wymaga zaufania do zewnętrznych centrów certyfikacji, co jest znacznie bezpieczniejsze. Jednak stosowanie DNSSEC znacznie częściej prowadzi do awarii technicznych, jeśli opierać się na statystykach z kilku lat użycia (choć w zakresie niezawodności DNSSEC i jego wsparcia technicznego w ogóle obserwuje się pozytywną dynamikę). Aby wdrożyć DANE w SMTP po stronie odbiorcy, posiadanie DNSSEC dla strefy DNS jest obowiązkowe, a dla DANE istotne jest poprawne wsparcie NSEC/NSEC3, z którym w DNSSEC są problemy systemowe.
Jeśli DNSSEC jest skonfigurowane błędnie, może to prowadzić do odmów dostarczenia poczty, jeśli strona wysyłająca wspiera DANE, nawet jeśli strona odbierająca nic o nim nie wie. Dlatego mimo że DANE jest starszym i bardziej bezpiecznym standardem oraz jest już wspierane w niektórych programach serwerowych po stronie nadawcy, to faktycznie jego penetracja pozostaje niewielka, wiele organizacji nie jest gotowych na jego wdrożenie z powodu konieczności implementacji DNSSEC, co znacznie hamowało wdrażanie DANE przez wszystkie te lata, w których standard istnieje.
DANE i MTA-STS nie konfliktują ze sobą i mogą być używane razem.
Jak wygląda wsparcie MTA-STS w Mail.ru?
Mail.ru już od dłuższego czasu publikuje politykę MTA-STS dla wszystkich głównych domen. Obecnie zajmujemy się wdrażaniem klienta standardu. Na moment pisania tego artykułu polityki są stosowane w trybie nieblokującym (jeśli dostarczenie jest zablokowane przez politykę, wiadomość zostanie dostarczona przez „zapasowy” serwer bez stosowania polityk), a następnie zostanie wprowadzony tryb blokujący dla małej części wychodzącego ruchu SMTP, stopniowo dla 100% ruchu będzie wspierane stosowanie polityk.
Kto jeszcze wspiera standard?
Obecnie polityki MTA-STS publikuje około 0,05% aktywnych domen, jednakże już chronią one dużą część ruchu pocztowego, ponieważ standard wspierają dużej graczy – Google, Comcast oraz częściowo Verizon (AOL, Yahoo). Wiele innych usług pocztowych zadeklarowało, że wsparcie standardu zostanie wdrożone w najbliższej przyszłości.
Jak to wpłynie na mnie?
Żadne, jeśli Twoja domena nie publikuje polityki MTA-STS. Jeśli opublikujesz politykę, wiadomości dla 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ę przez HTTPS oraz wpisy w DNS, skonfigurować ważny certyfikat od jednego z zaufanych certyfikatorów (możesz użyć Let’s Encrypt) dla STARTTLS w MTA (STARTTLS jest wspierane w nowoczesnych MTA), specjalne wsparcie ze strony MTA nie jest wymagane.
Krok po kroku, wygląda to tak:
- Skonfiguruj STARTTLS w używanym MTA (postfix, exim, sendmail, Microsoft Exchange itd.).
- Upewnij się, że używasz ważnego certyfikatu (wydanego przez zaufany CA, niewygasły, temat certyfikatu odpowiada wpisowi MX, na który dostarczana jest poczta dla Twojej domeny).
- Skonfiguruj zapis TLS-RPT, na który będą dostarczane raporty o zastosowaniu polityk (usługami wspierającymi wysyłanie raportów TLS). Przykład zapisu (dla domeny example.com):
smtp._tls.example.com. 300 IN TXT „v=TLSRPTv1;rua=mailto:tlsrpt@example.com”Ten zapis instruuje nadawców poczty, aby wysyłali statystyczne raporty dotyczące użycia TLS w SMTP na adres
tlsrpt@exmple.com.Monitoruj raporty przez kilka dni, upewnij się, że nie ma błędów.
- Opublikuj politykę MTA-STS przez HTTPS. Polityka publikowana jest jako plik tekstowy z terminatorami linii CRLF pod podanym adresem.
https://mta-sts.example.com/.well-known/mta-sts.txtPrzykład polityki:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Pole version zawiera wersję polityki (obecnie to
STSv1), Mode określa tryb zastosowania polityki, testing — tryb testowy (polityka nie jest stosowana), enforce — tryb 'produkcyjny'. Najpierw opublikuj politykę w trybie: testing, jeśli nie znajdziesz problemów w trybie testowym, po pewnym czasie możesz przełączyć się na tryb: enforce.W mx określana jest lista wszystkich serwerów pocztowych, które mogą przyjmować pocztę dla Twojej domeny (każdy serwer musi mieć skonfigurowany certyfikat, odpowiadający nazwie podanej w mx). Max_age określa czas pamięci podręcznej polityki (jedna raz zapamiętana polityka będzie stosowana nawet jeśli atakujący zablokuje jej wydanie lub uszkodzi wpisy DNS w czasie pamięci podręcznej, sygnalizować potrzebę ponownego zapytania polityki można przez zmianę zapisu mta-sts w DNS).
- Opublikuj w DNS wpis TXT:
_mta-sts.example.com. TXT “v=STS1; id=someid;”W polu id można używać dowolnego identyfikatora (na przykład znacznika czasu), a przy zmianie polityki powinien on być zmieniany, co pozwala nadawcom zrozumieć, że należy ponownie zażądać zbuforowanej polityki (jeśli identyfikator różni się od zbuforowanego).
Wsparcie MTA-STS po stronie nadawcy
Na razie jest z tym słabo, ponieważ standard jest świeży.
- Exim — brak wbudowanego wsparcia, dostępny jest zewnętrzny skrypt
- Postfix — brak wbudowanego wsparcia, jest zewnętrzny skrypt, o którym szczegółowo napisano na Habra
Na zakończenie o "obowiązkowym TLS"
Ostatnio regulatorzy zwracają uwagę na bezpieczeństwo poczty (i to dobrze). Na przykład DMARC jest obowiązkowy dla wszystkich instytucji rządowych w USA i coraz częściej wymaga się go w sektorze finansowym, w regulowanych obszarach penetracja standardu sięga 90%. Obecnie niektórzy regulatorzy wymagają wdrożenia "obowiązkowego TLS" dla oddzielnych domen, ale sposób zapewnienia "obowiązkowego TLS" nie jest określony, a w praktyce ta konfiguracja jest często wdrażana w sposób, który nawet minimalnie nie chroni przed rzeczywistymi atakami, które już przewidziano w takich mechanizmach jak DANE lub MTA-STS.
Jeśli regulator wymaga wdrożenia "obowiązkowego TLS" dla oddzielnych domen, zalecamy rozważenie MTA-STS lub jego częściowego odpowiednika jako najbardziej odpowiedniego mechanizmu, który eliminuje potrzebę dokonywania bezpiecznych konfiguracji dla każdej domeny osobno. Jeśli masz problemy z realizacją części klienta MTA-STS (dopóki protokół nie uzyskał szerokiego wsparcia, prawdopodobnie będą), można polecić takie podejście:
- Opublikuj politykę MTA-STS i/lub rekordy DANE (DANE ma sens dodawać tylko jeśli dla twojej domeny już włączono DNSSEC, a MTA-STS w każdym razie), to zabezpieczy ruch w twoją stronę i uwolni od konieczności proszenia innych usług pocztowych o skonfigurowanie obowiązkowego TLS dla twojej domeny, jeśli usługa pocztowa już wspiera MTA-STS i/lub DANE.
- Dla dużych usług pocztowych zaimplementuj „odpowiednik” MTA-STS poprzez oddzielne ustawienia transportu dla każdej domeny, które określą MX używany do przekazywania poczty i będą wymagały obowiązkowej weryfikacji certyfikatu TLS. Jeśli domeny już publikują politykę MTA-STS, można to prawdopodobnie zrobić bez problemów. Samo włączenie obowiązkowego TLS dla domeny bez określenia relaya i weryfikacji certyfikatu jest nieefektywne pod względem bezpieczeństwa i nic nie wnosi do istniejących mechanizmów STARTTLS.
Źródło: habr.com
