Jak skonfigurować DANE i rekordy TLSA dla poczty (SMTP)

DANE (DNS-Based Authentication of Named Entities) pozwala opublikować odcisk certyfikatu TLS Twojego serwera pocztowego bezpośrednio w DNS, dzięki czemu serwer wysyłający może zweryfikować certyfikat, zanim przekaże jakąkolwiek pocztę. W przypadku SMTP robisz to za pomocą rekordu TLSA pod adresem _25._tcp.<host-mx>, a całość działa tylko wtedy, gdy dana strefa DNS jest podpisana za pomocą DNSSEC. Ustaw kolejność poprawnie, a powstrzymasz atakujących przed usunięciem STARTTLS lub podstawieniem fałszywego certyfikatu na poczcie przychodzącej.

DANE jest zdefiniowane w RFC 6698, a reguły specyficzne dla SMTP w RFC 7672. Najważniejsza rzecz, którą trzeba zrozumieć, zanim dotkniesz jakiegokolwiek rekordu: DANE jest wiarygodne tylko na tyle, na ile wiarygodne jest DNSSEC. Bez prawidłowego łańcucha podpisów rekord TLSA to zaledwie bajty, które atakujący może nadpisać. Dlatego poniższa kolejność wdrożenia zaczyna się od DNSSEC i nie pomija tego kroku.

Dlaczego DANE istnieje i kiedy z niego korzystać

STARTTLS na porcie 25 jest z założenia oportunistyczne. Serwer wysyłający pyta "czy obsługujesz TLS?", a jeśli odpowiedź zostanie usunięta przez atak typu man-in-the-middle, dostarczanie po cichu wraca do formy niezaszyfrowanej. Nie ma tu również sprawdzenia urzędu certyfikacji, więc nawet gdy TLS zostanie wynegocjowany, certyfikat samopodpisany lub sfałszowany zwykle jest akceptowany. To właśnie tę lukę zamyka DANE.

DANE daje Ci jednocześnie dwie gwarancje. Po pierwsze, sygnalizuje, że TLS jest obowiązkowy dla Twojego hosta MX, więc obniżenie do połączenia niezaszyfrowanego staje się twardym błędem zamiast cichego powrotu do niższego poziomu. Po drugie, przypina dokładny certyfikat lub klucz, który musi zobaczyć serwer wysyłający, więc podstawiony certyfikat zostaje odrzucony. Ponieważ ten pin znajduje się w DNS podpisanym przez DNSSEC, nie da się go sfałszować bez zerwania łańcucha podpisów.

DANE konkuruje z MTA-STS i jednocześnie je uzupełnia. MTA-STS korzysta z webowego PKI oraz pliku polityki hostowanego przez HTTPS, więc działa bez DNSSEC, ale ufa urzędom certyfikacji. DANE wymaga DNSSEC, ale w ogóle nie ufa urzędom certyfikacji. Wielu dojrzałych nadawców publikuje oba rozwiązania. Aby podjąć decyzję na podstawie porównania obok siebie, przeczytaj MTA-STS a DANE.

Krok 1: potwierdź, że DNSSEC jest podpisany od początku do końca

To krok, na którym potyka się niemal każda pierwsza próba. Nie wystarczy, że rejestrator pokazuje zielony przełącznik DNSSEC. Łańcuch podpisów musi być kompletny od korzenia aż do dokładnej nazwy hosta niosącej rekord TLSA, czyli do Twojego celu MX, a nie tylko do domeny organizacyjnej.

Muszą zostać zwalidowane dwie strefy:

• Domena, która przechowuje Twój rekord MX (na przykład example.com).
• Strefa, która przechowuje samą nazwę hosta MX (na przykład mail.example.com, która może być delegowaną subdomeną lub nawet zupełnie inną domeną).

Jeśli Twój MX wskazuje na nazwę hosta, której strefa nie jest podpisana, DANE jest martwe od samego początku, bez względu na to, jak doskonały jest Twój rekord TLSA. Sprawdź łańcuch za pomocą walidującego resolvera:

dig +dnssec mail.example.com A

Szukaj flagi ad (Authenticated Data) w nagłówku odpowiedzi. Brak flagi ad oznacza, że odpowiedź nie została zwalidowana, więc napraw DNSSEC, zanim pójdziesz dalej. Możesz też potwierdzić, że rekord DS jest obecny u rodzica, odpytując dig DS example.com i sprawdzając, czy Twój rejestrator go opublikował. Podpisana strefa bez rekordu DS u rodzica jest niezwalidowana.

Krok 2: wygeneruj skrót TLSA z działającego certyfikatu STARTTLS

Pobierz certyfikat, który Twój serwer faktycznie prezentuje na porcie 25, a nie kopię z panelu sterowania. Użyj OpenSSL wobec działającej usługi:

openssl s_client -connect mail.example.com:25 -starttls smtp \
 -servername mail.example.com < /dev/null 2>/dev/null \
 | openssl x509 -pubkey -noout \
 | openssl pkey -pubin -outform DER \
 | openssl dgst -sha256 -binary \
 | xxd -p -u | tr -d '\n'

To polecenie wyodrębnia certyfikat, izoluje SubjectPublicKeyInfo i tworzy jego skrót SHA-256. Wypisany łańcuch szesnastkowy pisany wielkimi literami to pole danych Twojego rekordu TLSA. Haszowanie klucza publicznego (selektor 1) zamiast pełnego certyfikatu (selektor 0) to trwalszy wybór, ponieważ odnowienie certyfikatu z tą samą parą kluczy nie zmienia rekordu.

Krok 3: wybierz usage, selektor i typ dopasowania

Rekord TLSA ma cztery pola: usage selector matching-type data. W przypadku SMTP RFC 7672 ogranicza Cię do dwóch wartości usage, a reszta wyboru wynika z tego.

Usage: 3 (DANE-EE) kontra 2 (DANE-TA)

• Usage 3, DANE-EE, przypina bezpośrednio certyfikat lub klucz jednostki końcowej. Serwer wysyłający dopasowuje certyfikat liścia Twojego serwera do rekordu i całkowicie ignoruje łańcuch urzędu certyfikacji. To zalecane ustawienie domyślne dla niemal każdego, ponieważ jest proste i nie ma znaczenia, czy Twój certyfikat jest publicznie zaufany.
• Usage 2, DANE-TA, przypina punkt zaufania (certyfikat pośredni lub prywatny urząd certyfikacji). Liść musi łączyć się w łańcuch aż do tego punktu zaufania. Używaj tego tylko wtedy, gdy prowadzisz własny urząd certyfikacji lub często rotujesz certyfikaty liścia pod stabilnym certyfikatem pośrednim.

Wartości usage 0 i 1, które nakładają się na publiczne PKI, nie są używane w DANE dla SMTP. Nie publikuj ich.

Selektor i typ dopasowania

• Selektor 1 wybiera SubjectPublicKeyInfo (klucz publiczny). Selektor 0 wybiera pełny certyfikat. Wybierz 1, aby odnowienia certyfikatu z tym samym kluczem nie psuły DANE.
• Typ dopasowania 1 to SHA-256, czyli dokładnie to, co wygenerowało powyższe polecenie OpenSSL. Typ dopasowania 2 to SHA-512, a 0 oznacza pełne dane bez skrótu. Użyj 1.

A zatem standardowy rekord, który niemal każdy powinien opublikować, to 3 1 1, po którym następuje skrót.

Krok 4: opublikuj rekord TLSA pod adresem _25._tcp

Nazwa rekordu jest budowana z portu i protokołu poprzedzających nazwę hosta MX. Dla portu 25 przez TCP na mail.example.com nazwą właściciela jest _25._tcp.mail.example.com. Opublikuj go w strefie, która faktycznie kontroluje tę nazwę hosta:

_25._tcp.mail.example.com. IN TLSA 3 1 1 <64-char-sha256-hex>

Jeśli masz więcej niż jeden host MX, każdy z nich potrzebuje własnego rekordu TLSA pod własną nazwą _25._tcp. Powszechną i zalecaną praktyką jest publikowanie dwóch rekordów TLSA na host podczas wymiany certyfikatu: jednego dla obecnego klucza i jednego dla nadchodzącego, tak aby walidacja nigdy nie miała luki. Odzwierciedla to podejście z nakładaniem się kluczy z harmonogramu rotacji kluczy DKIM i jest to bezpieczny sposób zmiany kluczy w ramach DANE.

Krok 5: zwaliduj, zanim mu zaufasz

Nigdy nie zakładaj, że opublikowany rekord działa. Odpytaj go i potwierdź zarówno dane, jak i walidację DNSSEC:

dig +dnssec _25._tcp.mail.example.com TLSA

Potwierdź, że flaga ad jest ustawiona, a skrót zgadza się z tym, który wygenerowałeś. Do pełnego testu od początku do końca, który faktycznie otwiera połączenie SMTP i sprawdza certyfikat względem rekordu, użyj walidatora DANE, takiego jak narzędzie Sys4 dane-check lub internetowy checker DANE SMTP. Zielony wynik tam oznacza, że wysyłający MTA, na przykład Postfix z smtp_tls_security_level = dane, wymusi Twój pin.

Możesz skierować SPFWise na swoją domenę, aby potwierdzić, że otaczająca konfiguracja (podpisany DNSSEC, osiągalny MX, obecny TLS) jest zdrowa przed dodaniem DANE i po jego dodaniu.

Pułapka, która psuje większość pierwszych prób

Najczęstszą przyczyną awarii jest niezgodność między certyfikatem, który prezentuje serwer, a skrótem w DNS. Zdarza się to najczęściej, gdy Twój certyfikat odnawia się automatycznie (na przykład przez Let's Encrypt) z nową parą kluczy, a nic nie aktualizuje rekordu TLSA. W chwili, gdy nowy certyfikat wchodzi do użytku, każdy nadawca wymuszający DANE odrzuca Twoją pocztę, ponieważ pin już się nie zgadza.

Rozwiązaniem jest proces, a nie pojedynczy rekord. Albo odnawiaj z tym samym kluczem w każdym cyklu, albo zautomatyzuj wymianę, która publikuje nowy skrót 3 1 1, czeka na wygaśnięcie TTL, podmienia certyfikat, a następnie usuwa stary rekord. Traktuj rekord TLSA jako część cyklu życia certyfikatu, a nie jako wpis, który ustawiasz raz i zapominasz. Drugą najczęstszą awarią jest ta związana z DNSSEC z Kroku 1: niepodpisana strefa hosta MX, która czyni cały rekord bezwartościowym.

Najczęściej zadawane pytania

Czy potrzebuję DNSSEC do DANE?

Tak, absolutnie. DANE nie ma żadnej wartości bezpieczeństwa bez DNSSEC, ponieważ rekord TLSA jest wiarygodny tylko wtedy, gdy jego odpowiedź DNS jest kryptograficznie podpisana i zwalidowana. Jeśli strefa przechowująca nazwę hosta MX jest niepodpisana, serwer wysyłający w ogóle nie użyje rekordu TLSA, a atakujący mógłby go sfałszować lub usunąć. Podpisz strefę i potwierdź flagę ad, zanim cokolwiek opublikujesz.

Jaka jest różnica między usage 3 a usage 2 w rekordzie TLSA?

Usage 3 (DANE-EE) przypina własny certyfikat jednostki końcowej lub klucz publiczny Twojego serwera i całkowicie ignoruje łańcuch urzędu certyfikacji, co jest zalecanym ustawieniem domyślnym dla SMTP. Usage 2 (DANE-TA) przypina punkt zaufania, taki jak prywatny urząd certyfikacji lub certyfikat pośredni, a prezentowany liść musi łączyć się w łańcuch aż do niego. Większość operatorów powinna używać 3 1 1, chyba że prowadzą własny urząd certyfikacji.

Gdzie dokładnie trafia rekord TLSA?

Pod adres _25._tcp.<host-mx>, w strefie DNS, która kontroluje tę nazwę hosta. Jest on powiązany z celem MX, a nie z Twoją główną domeną. Jeśli Twój rekord MX wskazuje na mail.example.com, rekord TLSA znajduje się pod adresem _25._tcp.mail.example.com. Każdy host MX, który obsługujesz, potrzebuje własnego rekordu.

Powinienem używać DANE czy MTA-STS?

Jeśli możesz, używaj obu. DANE daje silniejsze gwarancje, ponieważ nie polega na urzędach certyfikacji, ale wymaga DNSSEC. MTA-STS działa bez DNSSEC, lecz ufa webowemu PKI oraz plikowi polityki HTTPS. Publikowanie obu obejmuje nadawców, którzy obsługują którykolwiek z mechanizmów. Pełne porównanie znajdziesz w MTA-STS a DANE.