Dostarczanie z szyfrowaniem: TLS, MTA-STS i DANE

Moduł 5: Reputacja i najwięksi dostawcy poczty · Czas czytania: 10 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili wyjaśnić, jak serwery pocztowe wzajemnie szyfrują połączenia, dlaczego domyślnie nie da się tego wymusić oraz co zmieniają w tym zakresie MTA-STS, TLS-RPT i DANE. Będą Państwo potrafili odnaleźć i odczytać odpowiednie rekordy.

Kluczowe pojęcia: STARTTLS między serwerami, szyfrowanie oportunistyczne, atak typu downgrade, MTA-STS (RFC 8461), rekord _mta-sts, plik zasad (policy file), tryb testing/enforce/none, TLS-RPT (RFC 8460), rekord _smtp._tls, DANE dla SMTP (RFC 7672), rekord TLSA, DNSSEC

Dwa rodzaje połączeń

W lekcji 1.4 mowa była o połączeniu między Państwa programem pocztowym a serwerem pocztowym Państwa dostawcy: port 587 ze STARTTLS lub port 465 z bezpośrednim TLS, z logowaniem. Nad tym połączeniem mają Państwo pełną kontrolę. Program wie, jakiego serwera się spodziewa, sprawdza certyfikat i odmawia połączenia, jeśli coś się nie zgadza.

Ta lekcja dotyczy kolejnego etapu: połączenia między serwerem wysyłającym a serwerem odbierającym, na porcie 25. Ono przebiega inaczej.

Oportunistycznie: szyfrowanie, gdy to możliwe

Gdy serwer dostarcza pocztę, łączy się z MX odbiorcy. Po EHLO sprawdza, czy serwer odbiorcy oferuje STARTTLS. Jeśli tak, przechodzi na połączenie szyfrowane. Jeśli nie, dostarcza wiadomość po prostu bez szyfrowania.

Nazywa się to szyfrowaniem oportunistycznym: szyfrowanie, gdy to możliwe, w przeciwnym razie bez niego. Zazwyczaj też serwer wysyłający nie sprawdza certyfikatu zbyt rygorystycznie. Przeterminowany lub samodzielnie wygenerowany certyfikat nie jest wówczas powodem do przerwania połączenia.

Dlaczego tak jest? Ponieważ poczta zawsze musi działać, również ze starszymi serwerami. Nadawca nie może wiedzieć, czy odbiorca powinien obsługiwać TLS. To umożliwia dwa rodzaje ataków:

1. Downgrade. Ktoś, kto może zmieniać ruch sieciowy po drodze, usuwa słowo STARTTLS z odpowiedzi odbiorcy. Nadawca sądzi, że nie ma szyfrowania, i dostarcza wiadomość bez szyfrowania. Atakujący czyta treść wiadomości.
2. Fałszywy MX. Ktoś, kto potrafi sfałszować odpowiedzi DNS, podaje własny serwer jako MX. Ponieważ certyfikat nie jest sprawdzany, nadawca niczego nie zauważa.

Obecnie niemal wszystkie duże serwery pocztowe szyfrują połączenia, a Gmail wymaga od nadawców stosowania TLS (lekcja 5.3). Jednak „zazwyczaj szyfrowane” to coś innego niż „zawsze i z właściwym serwerem”. Na to istnieją dwa rozwiązania: MTA-STS i DANE. Oba konfigurowane są przez odbiorcę: w ten sposób informują Państwo, że poczta do Państwa domeny zawsze musi być szyfrowana i dostarczana do serwera z ważnym certyfikatem.

MTA-STS: zasady za pomocą strony internetowej

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) składa się z dwóch elementów.

Rekordu TXT informującego, że istnieją określone zasady:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

Oraz pliku zasad w stałym miejscu, dostępnego przez https z ważnym certyfikatem:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Sprytne rozwiązanie: nadawca zapamiętuje zasady na czas określony w max_age. Atakujący, który później usunie słowo STARTTLS lub poda fałszywy MX, zostanie wówczas zdemaskowany: zasady mówią, że szyfrowanie jest obowiązkowe i które serwery są prawidłowe. Przy pierwszym połączeniu (zanim zasady są znane) MTA-STS nie chroni; to znany słaby punkt.

Rzeczywistym przykładem jest gmail.com: rekord TXT _mta-sts.gmail.com istnieje, a plik zasad pod adresem https://mta-sts.gmail.com/.well-known/mta-sts.txt ma ustawione mode: enforce.

TLS-RPT: raporty o nieudanym szyfrowaniu

Przy MTA-STS ustawionym na enforce poczta może utknąć w kolejce, jeśli coś jest nie tak z certyfikatem. Chcą Państwo o tym wiedzieć. Do tego służy TLS-RPT (RFC 8460):

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"

Nadawcy obsługujący TLS-RPT (między innymi Google i Microsoft) wysyłają wówczas codziennie raport w formacie JSON: ile połączeń się powiodło, a ile nie, wraz z przyczyną (na przykład przeterminowany certyfikat lub nazwa, której nie ma w zasadach). Podobnie jak w przypadku raportów DMARC (lekcja 4.5), można zlecić ich przetwarzanie usłudze raportującej.

Kolejność wdrażania: najpierw TLS-RPT, następnie MTA-STS w trybie testing, kilka tygodni czytania raportów, a dopiero potem enforce. Przypomina to zasadę stopniowego zaostrzania znaną z DMARC.

DANE: certyfikat w DNS, zabezpieczony przez DNSSEC

DANE (DNS-based Authentication of Named Entities) działa inaczej. W DNS umieszczają Państwo rekord TLSA przy każdym serwerze MX, zawierający odcisk cyfrowy (fingerprint) certyfikatu lub klucza:

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

_25._tcp oznacza: dla SMTP na porcie 25. Trzy liczby określają, jak odczytać wartość. Dla serwerów pocztowych najczęściej stosuje się 3 1 1: „to jest odcisk SHA-256 klucza publicznego dokładnie tego serwera”. Spotyka się też 2 1 1: wtedy zawarty jest odcisk certyfikatu pośredniego.

Nadawca obsługujący DANE widzi rekord TLSA, wymaga szyfrowania i sprawdza, czy certyfikat serwera się zgadza. Jeśli się nie zgadza, nie dostarcza wiadomości.

Dlaczego DANE jest bezpieczne wobec sfałszowanych odpowiedzi DNS? Ponieważ działa wyłącznie z DNSSEC (lekcja 8.1 kursu DNS). Bez ważnego łańcucha DNSSEC rekordy TLSA są ignorowane. To jednocześnie jego próg wejścia: zarówno Państwa domena (dla MX), jak i strefa serwera pocztowego muszą być podpisane.

DANE nie ma słabego punktu „pierwszego razu” jak MTA-STS i jest szeroko stosowane między innymi w Holandii i Niemczech. internet.nl testuje tę funkcję. Microsoft obsługuje DANE dla poczty przychodzącej w Exchange Online. Również serwery MX internet.nl mają rekordy TLSA.

Pułapka: jeśli wymienią Państwo certyfikat serwera pocztowego z DANE na nowy klucz, rekord TLSA musi zostać zmieniony razem z nim, i to wcześniej: najpierw dodać nowy rekord, odczekać do upłynięcia TTL, a dopiero potem zacząć używać nowego klucza. W przeciwnym razie nadawcy stosujący DANE odrzucą Państwa pocztę. Przy 3 1 1 ma to znaczenie tylko wtedy, gdy zmienia się klucz, a nie przy każdym odnowieniu z tym samym kluczem.

MTA-STS czy DANE?

Można stosować oba rozwiązania jednocześnie. RFC 8461 mówi, że nadawca obsługujący DANE powinien dać mu pierwszeństwo, jeśli istnieją ważne rekordy TLSA.

Kto się tym zajmuje?

To ustawienie konfiguruje się dla poczty przychodzącej do Państwa domeny. Jeśli Państwa poczta obsługiwana jest przez firmę hostingową lub usługę pocztową, zależy to od tej strony:

• DANE jest możliwe tylko, jeśli dostawca publikuje rekordy TLSA dla swoich serwerów pocztowych, a Państwa domena ma DNSSEC. Na przykład w WebOké można włączyć DANE w tym samym miejscu co DNSSEC (zob. artykuł internet.nl poniżej); u innych dostawców działa to podobnie lub jest skonfigurowane domyślnie.
• MTA-STS czasem można skonfigurować samodzielnie, ale wtedy mta-sts.example.com musi być stroną internetową z ważnym certyfikatem, a Państwo muszą znać nazwy serwerów MX swojego dostawcy.
• TLS-RPT zawsze mogą Państwo ustawić samodzielnie: to tylko rekord TXT z adresem do raportów.

Dla poczty wychodzącej nie muszą Państwo nic robić: to serwer Państwa dostawcy decyduje, czy respektuje MTA-STS i DANE odbiorców.

Podsumowanie

• Między serwerami pocztowymi TLS jest domyślnie oportunistyczny: szyfrowanie, gdy to możliwe, bez rygorystycznej kontroli certyfikatu. To umożliwia ataki typu downgrade i fałszywy MX.
• MTA-STS: rekord TXT _mta-sts plus plik zasad pod adresem https://mta-sts.<domena>/.well-known/mta-sts.txt; tryb testing lub enforce.
• TLS-RPT: rekord TXT _smtp._tls z adresem do raportów, dla codziennych raportów o nieudanym szyfrowaniu.
• DANE: rekord TLSA pod adresem _25._tcp.<serwer-mx>, działa wyłącznie z DNSSEC i chroni również pierwsze połączenie.
• Wdrażaj tak jak DMARC: najpierw raporty (TLS-RPT, testing), potem zaostrzanie zasad.

Quiz

Zadanie

Zadanie Z5.4: Wyszukiwanie MTA-STS, TLS-RPT i DANE. Proszę wyszukać dla gmail.com rekord MTA-STS i rekord TLS-RPT, otworzyć plik zasad i wpisać tryb (enforce, testing lub none). Następnie proszę wyszukać dla serwera MX domeny internet.nl rekord TLSA pod adresem _25._tcp.<serwer-mx> i wpisać pierwsze trzy liczby jednego z rekordów. Opcjonalnie: te same pytania dla własnej domeny (odpowiedź może brzmieć „brak”). Program sprawdza wszystko na żywo i porównuje wyniki.

Dalsza lektura

Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to podobnie.

• Lista kontrolna Internet.nl
• Czym jest DNSSEC?
• Bezpłatny kurs DNS 8.1: DNSSEC w prostych słowach
• internet.nl, sprawdź swoją pocztę e-mail (niezależny test STARTTLS, DANE i innych): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE dla SMTP)