MTA-STS i TLS-RPT – jak wymusić szyfrowane dostarczanie poczty

Problem: STARTTLS da się „zdjąć”

Gdy jeden serwer pocztowy doręcza wiadomość drugiemu, łączy się otwartym tekstem i prosi o przejście na szyfrowanie poleceniem STARTTLS – ale tylko wtedy, gdy odbiorca je oferuje. Jeśli oferty brakuje albo certyfikat jest nieważny, większość nadawców i tak doręcza wiadomość, bez szyfrowania. Dzięki temu poczta płynie nawet między źle skonfigurowanymi serwerami, ale atakujący, który może ingerować w połączenie, ma ułatwione zadanie: wystarczy, że usunie wiersz STARTTLS z odpowiedzi odbiorcy albo podsunie nadawcy własny serwer (np. fałszując odpowiedź MX), i może czytać każdą wiadomość. Nadawca niczego nie zauważy.

SPF, DKIM i DMARC nic tu nie pomogą: uwierzytelniają nadawcę wiadomości. MTA-STS chroni transport poczty przychodzącej do Twojej domeny.

Jak działa MTA-STS

Publikujesz dwie rzeczy. Krótki rekord TXT ogłasza, że domena ma politykę, a sama polityka to plik tekstowy na serwerze WWW, pobierany przez HTTPS. W tym tkwi sedno: certyfikat hosta z polityką potwierdza, że polityka naprawdę pochodzi od Ciebie – bez potrzeby wdrażania DNSSEC.

1. Zanim nadawca obsługujący MTA-STS doręczy pocztę do Twojej domeny, sprawdza rekord _mta-sts.firma.pl.
2. Jeśli rekord istnieje, a nadawca nie ma aktualnej kopii polityki, pobiera https://mta-sts.firma.pl/.well-known/mta-sts.txt i zapamiętuje ją na max_age sekund.
3. Potem doręcza pocztę tylko do serwerów MX pasujących do wierszy mx: polityki, przez TLS, z certyfikatem ważnym dla nazwy serwera MX. W trybie enforce, gdy którykolwiek z tych warunków nie jest spełniony, w ogóle nie doręcza poczty do tego serwera.

Krok 1: plik polityki

Polityka leży pod stałym adresem: host mta-sts. plus Twoja domena, ścieżka /.well-known/mta-sts.txt. To zwykły plik tekstowy z wierszami klucz: wartość:

version: STSv1
mode: testing
mx: mx1.dostawca.example
mx: mx2.dostawca.example
max_age: 604800

Serwer WWW musi spełnić kilka ścisłych wymagań – każde z nich to częsty powód, dla którego polityka jest ignorowana:

• Certyfikat musi być ważny dla samej nazwy mta-sts.firma.pl i wystawiony przez publicznie zaufany urząd certyfikacji – certyfikat tylko dla firma.pl albo www się nie liczy.
• Plik musi zostać zwrócony bezpośrednio z kodem HTTP 200. Nadawcom nie wolno podążać za przekierowaniami, więc przekierowanie z mta-sts.firma.pl na stronę główną wszystko psuje.
• Serwuj go jako text/plain – nadawcy mają sprawdzać typ zawartości. RFC przewiduje końce wierszy CRLF.

Krok 2: rekord TXT

_mta-sts.firma.pl.  3600  IN  TXT  "v=STSv1; id=20261026"

id to oznaczenie wersji złożone z 1–32 liter i cyfr. Nadawcy porównują je z identyfikatorem polityki, którą mają w pamięci – jeśli się zmienił, pobierają politykę od nowa. Zmieniaj go za każdym razem, gdy zmieniasz plik polityki (zwykle wpisuje się datę lub znacznik czasu), i to w tej kolejności: najpierw plik, potem rekord, żeby nikt nie pobrał starego pliku pod nowym identyfikatorem. Nie zapomnij też o stronie WWW: nazwa mta-sts.firma.pl potrzebuje własnego rekordu A/AAAA (lub CNAME) wskazującego serwer z plikiem.

Serwery MX muszą mieć ważne certyfikaty

Ten punkt łatwo przeoczyć. Przy egzekwowanej polityce nadawca odmówi doręczenia do serwera MX, którego certyfikat wygasł, jest samopodpisany albo wystawiony na inną nazwę. Zanim przełączysz się na enforce, upewnij się, że każdy host z rekordów MX przedstawia publicznie zaufany certyfikat obejmujący jego własną nazwę i że każdy jest wpisany w wierszach mx: polityki. Jeśli Twoja poczta jest hostowana, zapytaj o to dostawcę: polityka w trybie enforce wskazująca serwery, których certyfikat nie pasuje do nazwy, odcięłaby Cię od poczty od nadawców obsługujących MTA-STS.

Tryby: testing, enforce i none

Bezpieczne wdrożenie

1. Najpierw skonfiguruj TLS-RPT (następna sekcja), żeby dostawać informacje o błędach.
2. Opublikuj politykę w trybie testing z krótkim max_age, np. jedną dobą (86400) – wtedy ewentualne pomyłki szybko znikną z pamięci nadawców.
3. Przez kilka tygodni czytaj raporty TLS i poprawiaj to, co w nich wychodzi.
4. Przełącz się na enforce, wydłuż max_age do kilku tygodni lub więcej (RFC 8461 zakłada wartości „rzędu tygodni lub dłuższe”; 1209600 to dwa tygodnie) i zmień id.

Długi max_age ma znaczenie dla bezpieczeństwa. Nadawca jest chroniony dopiero wtedy, gdy ma Twoją politykę w pamięci, a moment jej pobierania to właśnie chwila, w której atakujący mógłby ją zablokować. Im dłużej polityka żyje w pamięci, tym mniej takich chwil.

Wyłączanie MTA-STS

Nie usuwaj po prostu rekordu i pliku: nadawcy stosowaliby zapamiętaną politykę aż do jej wygaśnięcia. RFC 8461 (sekcja 8.3) zaleca opublikowanie polityki z mode: none i krótkim max_age, zmianę id, odczekanie, aż wygasną wszystkie wcześniej udostępnione polityki, i dopiero wtedy usunięcie obu elementów.

Zmiana dostawcy poczty

Przy egzekwowanej polityce dopisz serwery MX nowego dostawcy do wierszy mx: (i zmień id) zanim zmienisz rekordy MX – inaczej nadawcy ze starą polityką w pamięci odmówią doręczania do nowych serwerów. Stare wpisy usuń po zakończeniu przeprowadzki. Resztę kroków opisuje poradnik o rekordach MX.

TLS-RPT – raporty o szyfrowanym doręczaniu

SMTP TLS Reporting (RFC 8460) to standard towarzyszący: publikujesz adres, a nadawcy, którzy go obsługują, wysyłają Ci codzienny raport o swoich połączeniach z Twoją domeną – ile sesji TLS się udało, które się nie powiodły i dlaczego. Raporty obejmują błędy MTA-STS i DANE, a także zwykłe problemy ze STARTTLS, a gdy wszystko działa, pełnią rolę sygnału „wszystko w porządku”.

_smtp._tls.firma.pl.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:raporty-tls@firma.pl"

• rua przyjmuje adresy mailto: i adresy URL https:; można podać kilka, oddzielonych przecinkami.
• Raporty mają format JSON, zwykle są skompresowane gzipem i obejmują jedną dobę UTC. Pisane są dla programów, więc skrzynka, do której nikt nie zagląda, na niewiele się zda – przekazuj je do narzędzia, które je przetwarza, albo przynajmniej przeglądaj je w trakcie wdrożenia.
• Wśród typów błędów zobaczysz m.in. starttls-not-supported, certificate-expired, certificate-host-mismatch, validation-failure, a w przypadku MTA-STS – sts-policy-fetch-error.
• TLS-RPT dotyczy tylko poczty wysyłanej do Ciebie, więc możesz go opublikować niezależnie od tego, kto hostuje Twoją pocztę – raporty trafiają na wskazany przez Ciebie adres.

DANE jako alternatywa

DANE dla SMTP (RFC 7672) rozwiązuje ten sam problem inaczej: zamiast polityki przez HTTPS publikujesz rekord TLSA z odciskiem klucza serwera MX, pod nazwą w rodzaju _25._tcp.mx.firma.pl. Rekordowi można ufać, bo jest podpisany DNSSEC – dlatego DANE wymaga DNSSEC zarówno w Twojej domenie, jak i w strefie każdego serwera MX. Tam, gdzie DNSSEC jest dostępny, DANE nie ma słabości pierwszego pobrania polityki, jaką ma MTA-STS; tam, gdzie go nie ma, MTA-STS powstał właśnie po to, żeby się bez niego obejść. Oba mechanizmy mogą działać jednocześnie – nadawca obsługujący oba nie może pozwolić, żeby MTA-STS „przegłosował” nieudaną weryfikację DANE. Przy hostowanej poczcie DANE jest możliwy tylko wtedy, gdy dostawca publikuje rekordy TLSA dla swoich serwerów MX.

MTA-STS a AnyMail

AnyMail nie hostuje plików polityki MTA-STS dla domen klientów, dlatego na stronie konfiguracji DNS nie ma kroku MTA-STS. TLS-RPT możesz natomiast opublikować w każdej chwili – to zwykły rekord TXT wskazujący wybrany przez Ciebie adres. Narzędzie do sprawdzania domeny pokazuje, czy domena ma rekordy MTA-STS i TLS-RPT, w jakim trybie jest polityka i czy jej wiersze mx: obejmują serwery MX domeny; te wyniki są informacyjne i nie wpływają na ocenę.