MTA-STS i TLS-RPT: szyfrowanie poczty przychodzącej krok po kroku

Problem, który rozwiązuje MTA-STS

Serwery pocztowe szyfrują połączenia poleceniem STARTTLS, ale zwykle robią to "jeśli się da". Nadawca łączy się z Twoim serwerem MX, pyta, czy ten obsługuje szyfrowanie, i dopiero wtedy je włącza. Ktoś, kto siedzi po drodze, może usunąć z odpowiedzi informację o STARTTLS, a wtedy nadawca wyśle wiadomość otwartym tekstem. Nadawca nie ma też skąd wiedzieć, że Twoja domena szyfrowania wymaga, więc nie widzi w tym niczego dziwnego. Bez wymogu szyfrowania odrzucenie poczty byłoby dla nadawcy gorsze niż wysłanie jej otwartym tekstem.

MTA-STS (RFC 8461) daje nadawcy tę wiedzę. Nadawca, który obsługuje MTA-STS, pobiera Twoją politykę przez HTTPS, zapamiętuje ją na czas podany w pliku i przy trybie enforce nie dostarcza poczty do serwera, który nie spełnia warunków. Polityka dotyczy poczty przychodzącej do Twojej domeny. Szyfrowanie poczty, którą Ty wysyłasz, zależy od polityk domen odbiorców.

Audytor sprawdza dwie rzeczy: czy domena publikuje MTA-STS (i jak) oraz czy ma TLS-RPT. Samo szyfrowanie serwera MX (STARTTLS i certyfikat) to osobne sprawdzenie. Metodykę opisuje strona o metodologii.

Trzy elementy MTA-STS

Do działania potrzebujesz wszystkich trzech. Brak któregokolwiek sprawia, że nadawcy nie zastosują polityki albo uznają, że jej nie ma.

1. Rekord TXT w DNS

Nazwa rekordu to _mta-sts.<domena>, na przykład _mta-sts.twojafirma.pl. Wartość:

v=STSv1; id=20261110T090000

• v=STSv1 musi być pierwszym polem.
• id to identyfikator wersji polityki: od 1 do 32 znaków, wyłącznie litery i cyfry (RFC 8461, sekcja 3.1). Może to być data i godzina bez znaków specjalnych, na przykład 20261110090000. Zawsze ma być inny niż poprzedni, ale RFC nie narzuca porządku, więc nie musi rosnąć.
• Rekordy TXT pod tą nazwą, które nie zaczynają się od v=STSv1;, są pomijane. Jeśli po odrzuceniu nie zostaje dokładnie jeden poprawny rekord, nadawca uznaje, że polityki nie ma. Audytor szuka rekordu zaczynającego się od v=STSv1.

2. Plik polityki przez HTTPS

Plik leży pod adresem https://mta-sts.<domena>/.well-known/mta-sts.txt, czyli na osobnym hoście o nazwie mta-sts w Twojej domenie. Format to pary klucz: wartość, po jednej w wierszu. Przykład:

version: STSv1
mode: testing
mx: mail.twojafirma.pl
mx: *.mail-dostawcy.example
max_age: 86400

• version musi mieć wartość STSv1.
• mode to enforce, testing albo none (opis niżej).
• mx to jedna linia na każdy dozwolony serwer poczty. Wpisujesz pełną nazwę hosta albo wzorzec z gwiazdką na początku, który obejmuje tylko pierwszą (lewą) etykietę nazwy (RFC 8461, sekcja 4.1). Nazwy w przykładzie są fikcyjne.
• max_age to czas w sekundach, przez który nadawca może pamiętać politykę. Wartość jest nieujemną liczbą całkowitą, a RFC ustala górny limit na 31557600 (około roku). Liczba 86400 w przykładzie to jedna doba i jest tylko przykładem.
• Nieznane pola są ignorowane, a gdy pole (poza mx) powtarza się, liczy się pierwsze wystąpienie.

3. Ważny certyfikat dla mta-sts.<domena>

Host mta-sts.<domena> musi mieć nazwę w DNS i certyfikat, który jest ważny dla tej nazwy, wystawiony przez zaufany urząd i niewygasły (RFC 8461, sekcja 3.3). Nadawca przyjmuje tylko odpowiedź HTTP 200. Przekierowań (3xx) nie wolno podążać, a odpowiedzi nie wolno brać z pamięci podręcznej HTTP. Typ treści ma być text/plain. Wygasły certyfikat to najczęstszy sposób, w jaki działająca polityka przestaje działać po miesiącach, dlatego odnawianie ustaw automatycznie: co robić, gdy certyfikat wygasł.

Certyfikat serwera MX to inna sprawa niż certyfikat hosta mta-sts. Przy enforce nadawca sprawdza oba: czy nazwa MX pasuje do którejś linii mx i czy MX przedstawia ważny certyfikat dla tej nazwy.

Tryby: testing, enforce i none

• testing: nadawca stosuje politykę do sprawdzenia, ale poczta jest dostarczana także wtedy, gdy warunki nie są spełnione. Jeśli nadawca obsługuje TLS-RPT, wyśle raport o błędach (RFC 8461, sekcja 5). To tryb do wdrożenia i obserwacji.
• enforce: nadawca nie dostarcza poczty do serwera, który nie pasuje do listy mx, nie ma ważnego certyfikatu albo nie obsługuje STARTTLS. Wiadomość jest wtedy traktowana jak niedostarczona czasowo i ponawiana.
• none: domena jest traktowana tak, jakby nie miała aktywnej polityki. Służy do wyłączenia MTA-STS (opis niżej).

Audytor ocenia tryb tak: enforce to wynik dobry, testing to ostrzeżenie z zaleceniem przejścia na enforce po okresie testów, a polityka bez poprawnego trybu (brak linii mode albo inna wartość) to ostrzeżenie "Polityka MTA-STS bez poprawnego trybu (mode)". Brak rekordu daje komunikat "Brak MTA-STS - szyfrowanie przy odbiorze poczty nie jest wymuszane".

Bezpieczna kolejność wdrożenia

1. Upewnij się, że każdy serwer MX z Twojego DNS obsługuje STARTTLS i ma ważny certyfikat na nazwie z rekordu MX. Sprawdzisz to w darmowym audycie. Gdy poczta stoi u dużego dostawcy, wpisy mx w polityce podaje jego dokumentacja.
2. Włącz TLS-RPT (sekcja niżej), żeby od początku dostawać raporty.
3. Utwórz host mta-sts.<domena> z certyfikatem i opublikuj plik polityki w trybie testing. Na początek wybierz krótki max_age, żeby błąd w polityce nie został zapamiętany na długo.
4. Dodaj rekord TXT _mta-sts z pierwszym id.
5. Przez kilka tygodni czytaj raporty TLS-RPT. RFC nie podaje wymaganego czasu testów, to Twoja decyzja. Szukaj błędów typu sts-policy-invalid, certificate-host-mismatch czy starttls-not-supported.
6. Gdy raporty są czyste, zmień w pliku mode na enforce, podnieś max_age do wartości, którą uznasz za rozsądną (limit RFC to 31557600), i zmień id w rekordzie TXT.

Zmiana polityki to zmiana id

Nadawcy trzymają politykę w pamięci przez czas max_age i odświeżają ją, gdy zobaczą w DNS inny id. Same zmiany w pliku bez zmiany id nie są wykrywane od razu. RFC zaleca kolejność (sekcja 8.1): najpierw zaktualizuj plik polityki, potem zmień id w rekordzie TXT, żeby nadawca nie zapamiętał starej polityki pod nowym id. Stare wersje polityki zostaw dostępne do wygaśnięcia TTL rekordu TXT.

Dotyczy to też nowego serwera MX. Dopisz jego linię mx do pliku i zmień id przed przełączeniem poczty, bo przy enforce nadawca, który pamięta starą listę, nie dostarczy poczty na nowy serwer.

Jak wyłączyć MTA-STS

Samo usunięcie rekordu nie wystarcza, bo nadawcy dalej pamiętają politykę przez max_age. Według RFC (sekcja 8.3): opublikuj politykę z trybem none i krótkim max_age (RFC podaje przykład jednej doby), zmień id, poczekaj aż wygasną wcześniej zapamiętane polityki, i dopiero wtedy usuń rekord i plik.

Najczęstsze błędy

• Brak hosta mta-sts albo certyfikatu. Rekord TXT jest, ale pliku nie da się pobrać. Audytor pisze wtedy "Rekord MTA-STS jest, ale polityki nie da się pobrać" z nazwą błędu, a nadawcy zachowują się tak, jakby polityki nie było, albo (gdy mają ją w pamięci) stosują starą.
• Polityka zwraca inny kod niż 200. Audytor pisze "Rekord MTA-STS jest, ale polityka zwraca HTTP" z numerem kodu. Tak samo zachowują się nadawcy: tylko 200 jest poprawną odpowiedzią.
• Przekierowanie zamiast pliku. Host mta-sts odsyła na inny adres (na przykład z http na https albo na inną domenę), bo serwer WWW ma ogólną regułę przekierowań. Nadawca nie podąża za przekierowaniami, a Audytor też nie, więc zobaczysz kod 301 albo 302. Plik musi być serwowany bezpośrednio pod właściwym adresem HTTPS.
• Zły typ treści. RFC mówi, że nadawca powinien sprawdzać, czy odpowiedź ma typ text/plain. Plik serwowany jako text/html albo application/octet-stream może zostać odrzucony. Audytor tej cechy osobno nie ocenia, ale warto ją sprawdzić w nagłówkach odpowiedzi.
• Linie mx nie obejmują wszystkich serwerów MX. To błąd, który Audytor opisuje najostrzej. Przy trybie enforce jest to błąd: "Polityka MTA-STS (enforce) nie obejmuje serwera poczty ... nadawcy, którzy ją stosują, nie dostarczą poczty na ten serwer". Przy testing jest to ostrzeżenie z zaleceniem poprawy przed przejściem na enforce. Typowa przyczyna: dodany zapasowy MX albo zmiana dostawcy poczty bez aktualizacji pliku. Wzorzec z gwiazdką obejmuje tylko jedną etykietę, więc *.twojafirma.pl nie pasuje do a.b.twojafirma.pl.
• Zbyt krótki max_age. Gdy wartość jest rzędu minut, nadawca niemal nie pamięta polityki i atakujący, który blokuje pobieranie pliku, ma otwartą drogę. W enforce ma sens dłuższy czas, w tygodniach lub więcej (RFC 8461, sekcja 3.3: spodziewane są wartości od tygodni wzwyż). Krótki czas zostaw na etap testów.
• Zbyt długi max_age bez uzasadnienia. Wartość blisko limitu 31557600 oznacza, że błędną politykę nadawcy zapamiętają na prawie rok. Dopóki nie masz czystych raportów i stabilnego certyfikatu na hoście mta-sts, trzymaj czas krótki.
• Zmiana pliku bez zmiany id. Nadawcy mogą długo używać starej wersji.

TLS-RPT: raporty o szyfrowaniu

TLS-RPT (RFC 8460) to uzupełnienie MTA-STS. Nadawcy, którzy go obsługują, raz na dobę wysyłają do Ciebie zbiorczy raport o tym, jak poszły ich połączenia z Twoimi serwerami. Rekord to TXT pod nazwą _smtp._tls.<domena>:

v=TLSRPTv1; rua=mailto:[email protected]

• v=TLSRPTv1 to wersja, rua to adres odbioru raportów. Obsługiwane są dwa schematy: mailto: i https:, a kilka adresów oddziela się przecinkami.
• Raporty są plikami JSON, zwykle skompresowanymi gzip (typy treści application/tlsrpt+json i application/tlsrpt+gzip), dostarczanymi e-mailem lub przez HTTPS POST. Okres raportu to zwykle pełna doba UTC.
• Raport zawiera typ polityki (sts dla MTA-STS, tlsa dla DANE albo no-policy-found), liczbę udanych i nieudanych sesji oraz przyczyny błędów, między innymi: starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid. Przy każdym błędzie podany jest adres IP nadawcy i nazwa serwera MX.
• Drobne, chwilowe błędy (zajęta sieć, przekroczenie czasu TCP) nie muszą być raportowane.

Włącz TLS-RPT przed enforce, bo to jedyny sposób, by zobaczyć, czyja poczta nie przeszłaby po przełączeniu: nadawcy, którzy mają kłopot z Twoim certyfikatem, wyliczą się w raportach z trybu testing. Bez raportów enforce włączasz na ślepo. Dobrze, by adres w rua był osobną skrzynką lub aliasem, bo raportów przybywa. Audytor sprawdza tylko obecność rekordu zaczynającego się od v=TLSRPTv1. Wynik dobry brzmi "TLS-RPT: raporty o problemach z szyfrowaniem są wysyłane", a przy braku rekordu: "Brak TLS-RPT (raporty o błędach TLS przy dostarczaniu)". Nie sprawdza, czy adres w rua działa, więc wyślij sobie próbę i zajrzyj do skrzynki po dobie.

TLS-RPT działa niezależnie od MTA-STS. Możesz mieć sam rekord TLS-RPT, żeby widzieć błędy TLS u nadawców, nawet bez polityki.

Gdzie hostować plik polityki

Plik ma kilka linii i prawie nigdy się nie zmienia, więc nie potrzebujesz osobnego serwera.

• Własny serwer WWW. Dodaj wirtualny host dla mta-sts.<domena> z certyfikatem (może być automatycznie odnawiany) i plikiem w katalogu .well-known. Wyłącz dla tego hosta ogólne przekierowania i upewnij się, że plik ma typ text/plain.
• Usługa statycznego hostingu (strony statyczne, przechowywanie plików z własną domeną). Warunek jest jeden: musi obsłużyć nazwę mta-sts.<domena> z ważnym certyfikatem i oddać plik bezpośrednio, bez przekierowania, z kodem 200 i typem text/plain. Sprawdź to po wdrożeniu poleceniem pobierającym nagłówki i treść.
• Dostawca poczty lub DNS. Część dostawców publikuje politykę za Ciebie albo ma gotowy przycisk. Sprawdź w panelu, czy to jest, i które linie mx wpisuje. Nie zakładaj, że tak jest.

Hostujący serwer nie musi stać obok serwera poczty. Wręcz lepiej, żeby awaria jednego nie wyłączała obu. Plik pobierają serwery nadawców z internetu, więc host mta-sts musi być osiągalny publicznie.

Powiązane poradniki

MTA-STS chroni szyfrowanie transportu, a nie autentyczność nadawcy. Za to odpowiadają DKIM i DMARC. Sprawdź cały stan poczty swojej domeny w darmowym audycie.

Źródła

• RFC 8461, SMTP MTA Strict Transport Security (MTA-STS): rfc-editor.org/rfc/rfc8461
• RFC 8460, SMTP TLS Reporting: rfc-editor.org/rfc/rfc8460