SMTP i STARTTLS: szyfrowanie poczty między serwerami

Gdy Twój serwer poczty dostarcza wiadomość do innej domeny, sprawdza rekordy MX odbiorcy i łączy się z jednym z tych serwerów przez SMTP na porcie 25. Sam SMTP przesyła wszystko otwartym tekstem. Szyfrowanie dokłada STARTTLS (RFC 3207): serwery zaczynają rozmowę bez szyfrowania, a potem uzgadniają przełączenie tego samego połączenia na TLS.

To dobrze chroni przed kimś, kto tylko podsłuchuje ruch. Wobec atakującego, który może ruch modyfikować, ochrona jest znacznie słabsza — chyba że domena odbiorcy publikuje MTA-STS lub DANE.

Jak wygląda sesja ze STARTTLS

S: 220 mx1.example.net ESMTP
C: EHLO sender.example.org
S: 250-mx1.example.net
S: 250-PIPELINING
S: 250-SIZE 52428800
S: 250-STARTTLS
S: 250 8BITMIME
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   (negocjacja TLS: wersja, szyfr, certyfikat serwera)
C: EHLO sender.example.org
S: 250-mx1.example.net
S: 250-PIPELINING
S: 250-SIZE 52428800
S: 250 8BITMIME
C: MAIL FROM:<alice@example.org>

1. Serwer wita klienta banerem z kodem 220.
2. Klient wysyła EHLO, a serwer wymienia obsługiwane rozszerzenia. STARTTLS na liście oznacza, że TLS jest dostępny.
3. Klient wysyła STARTTLS, serwer odpowiada 220 i na tym samym połączeniu TCP rusza negocjacja TLS (handshake).
4. Sesja zaczyna się od nowa, już wewnątrz TLS. Obie strony muszą zapomnieć wszystko, czego dowiedziały się przed negocjacją, klient ponownie wysyła EHLO, a serwer nie oferuje już STARTTLS (RFC 3207, sekcja 4.2).

Ten poradnik dotyczy przekazywania poczty między serwerami na porcie 25. Gdy aplikacja albo program pocztowy wysyła pocztę przez serwer swojego dostawcy, korzysta z portu 587 ze STARTTLS albo z portu 465, gdzie TLS działa od pierwszego bajtu — zawsze z uwierzytelnianiem. Dla takiego wysyłania RFC 8314 zaleca ten drugi wariant.

Dlaczego to szyfrowanie „oportunistyczne”

Ani adres e-mail, ani rekord MX nie mówią, czy serwer odbiorcy obsługuje TLS. Nadawcy używają więc TLS, gdy serwer go oferuje, a gdy nie — dostarczają pocztę bez szyfrowania. RFC 3207 wręcz zabrania publicznemu serwerowi MX wymagania STARTTLS, żeby serwery bez TLS nadal mogły do niego dostarczać pocztę.

Taki model to bezpieczeństwo oportunistyczne (RFC 7435): szyfruj zawsze, gdy się da, uwierzytelniaj, gdy to możliwe. RFC 7435 zauważa też, że serwery nadawców często ponawiają próbę bez szyfrowania, gdy negocjacja TLS się nie powiedzie.

Co może zrobić aktywny atakujący

STARTTLS zatrzymuje podsłuch bierny. Atakujący, który może zmieniać ruch między serwerami, ma kilka możliwości, opisanych w RFC 8461 i RFC 7672:

• Usunięcie STARTTLS (stripping). Wszystko przed negocjacją jest niechronione. Wycięcie wiersza 250-STARTTLS z odpowiedzi na EHLO sprawia, że nadawca uznaje TLS za niedostępny i wysyła wiadomość otwartym tekstem.
• Zepsucie negocjacji. Ingerencja w polecenie STARTTLS lub w samą negocjację powoduje błąd, a wielu nadawców wraca wtedy do połączenia bez szyfrowania.
• Przekierowanie połączenia. Bez DNSSEC sfałszowane odpowiedzi DNS na zapytania o MX lub adres kierują nadawcę na serwer atakującego, który chętnie zaoferuje TLS z własnym certyfikatem.
• Podstawienie certyfikatu. Jeśli nadawca nie weryfikuje certyfikatu, pośrednik może sam zakończyć TLS i czytać całą korespondencję.

Zwykle nikt tego nie zauważa: poczta dochodzi jak zawsze.

Weryfikacja certyfikatów w praktyce

Przeglądarka odrzuca certyfikat, który nie pasuje do nazwy strony. Oportunistyczny SMTP na ogół tego nie robi — z powodów opisanych w RFC 7672, sekcja 1.3:

• nadawca nie ma wiarygodnej nazwy do porównania — nazwa hosta MX pochodzi z DNS, który bez DNSSEC można sfałszować;
• wiele serwerów odbiorczych używa certyfikatów samopodpisanych albo wystawionych przez prywatne CA, więc serwery nadawców rzadko są skonfigurowane do weryfikacji;
• skoro nic nie mówi nadawcy, jakiego certyfikatu się spodziewać, odrzucanie takich certyfikatów kończyłoby się tylko odbiciem poczty albo powrotem do połączenia bez szyfrowania — a to gorsze niż szyfrowanie bez uwierzytelnienia (RFC 7435).

Przy samym STARTTLS certyfikat samopodpisany albo z niepasującą nazwą zwykle więc nadal daje szyfrowanie — ale bez ochrony przed aktywnym atakującym. Mimo to utrzymuj ważny certyfikat: wymaga go MTA-STS, a RFC 7435 odnotowuje, że część nadawców akceptuje certyfikaty samopodpisane, ale nie wygasłe — i wtedy przechodzi na połączenie bez szyfrowania.

Rozwiązania: MTA-STS i DANE

Oba mechanizmy pozwalają domenie odbiorcy ogłosić: „tu jest TLS i tak należy go uwierzytelnić”. Nadawcy, którzy je obsługują, odmawiają wtedy dostarczenia przez połączenie zdegradowane lub podstawione.

	MTA-STS (RFC 8461)	DANE (RFC 7672)
Publikacja	Rekord TXT _mta-sts.<domena> i plik polityki pod https://mta-sts.<domena>/.well-known/mta-sts.txt	Rekordy TLSA pod _25._tcp.<host MX>
Podstawa zaufania	Publiczne urzędy certyfikacji (CA)	DNSSEC
Certyfikat musi	Prowadzić do zaufanego CA, być ważny i zawierać nazwę hosta MX	Pasować do rekordu TLSA
Główne ograniczenie	Pierwszy kontakt: nadawcy bez zapamiętanej polityki można uniemożliwić jej pobranie	Wymaga stref podpisanych DNSSEC i nadawców weryfikujących DNSSEC
Łagodny start	mode: testing	Rekordy TLSA tylko dla części hostów MX

Domena ogłasza MTA-STS rekordem TXT, który podaje wersję polityki:

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

Plik polityki pod adresem https://mta-sts.example.com/.well-known/mta-sts.txt wymienia nazwy hostów MX, które mogą przyjmować pocztę, i określa, jak długo nadawcy mają pamiętać politykę:

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

Rekord DANE przypina klucz serwera. RFC 7672 zaleca postać 3 1 1 — skrót SHA-256 klucza publicznego serwera — i przy niej nazwy w certyfikacie oraz data jego wygaśnięcia nie mają znaczenia; liczy się klucz opublikowany w DNS (sekcja 3.1.1):

_25._tcp.mx1.example.net.  3600  IN  TLSA  3 1 1 <skrót SHA-256 klucza publicznego>

Oba mechanizmy mogą działać razem; nadawca obsługujący oba nie może pozwolić, by wynik MTA-STS przeważył nad nieudaną weryfikacją DANE. Niezależnie od wyboru dodaj rekord TLS-RPT (RFC 8460), żeby nadawcy zgłaszali Ci nieudane połączenia TLS. Konfigurację krok po kroku opisuje poradnik MTA-STS i TLS-RPT.

Wersje TLS

RFC 8996 wycofuje TLS 1.0 i 1.1: nie wolno ich używać. Aktualne dobre praktyki z RFC 9325 wymagają obsługi TLS 1.2 i zalecają TLS 1.3, wybierany zawsze, gdy obie strony go obsługują. MTA-STS również wymaga od uczestniczących serwerów obsługi TLS 1.2 lub nowszego (RFC 8461, sekcja 7.2).

Publiczny serwer MX powinien oferować TLS 1.2 i 1.3. Jeśli negocjuje tylko 1.0 lub 1.1, przestarzała jest biblioteka TLS albo oprogramowanie serwera poczty. RFC 9325, sekcja 5.2 dodaje zastrzeżenie dla protokołów oportunistycznych: zbyt surowe ustawienia mogą prowadzić do połączeń bez szyfrowania, a to gorsze niż przestarzała wersja TLS. Bardzo stary nadawca, który nie potrafi użyć TLS 1.2, zwykle dostarczy pocztę do Twojego MX bez szyfrowania, a nie zrezygnuje z dostarczenia — zanim wyłączysz stare wersje, sprawdź w logach serwera poczty, czy takie połączenia się zdarzają.

Co pokazuje test SMTP i TLS

Narzędzie Test SMTP i TLS łączy się z serwerami MX Twojej domeny na porcie 25 — tak jak serwer nadawcy — i pokazuje:

• baner — czy serwer odpowiada i jakim powitaniem;
• odpowiedź na EHLO i oferowane rozszerzenia;
• czy serwer oferuje STARTTLS i czy przejście na TLS się udaje;
• wynegocjowaną wersję TLS;
• certyfikat — czy obejmuje nazwę hosta MX i kiedy wygasa.

Po negocjacji TLS narzędzie kończy sesję i nie wysyła poczty: nie wysyła MAIL FROM ani RCPT TO, więc nie mówi nic o istnieniu skrzynek.

Wynik	Skutek	Co zrobić
Brak STARTTLS w odpowiedzi na EHLO	Cała przychodząca poczta płynie bez szyfrowania; MTA-STS nie może działać w trybie enforce	Włącz TLS w serwerze poczty i zainstaluj certyfikat
STARTTLS jest oferowany, ale negocjacja się nie udaje	Nadawcy ponawiają próbę bez szyfrowania albo odkładają dostarczenie	Sprawdź certyfikat, klucz i ustawienia TLS
Negocjowany tylko TLS 1.0 lub 1.1	Przestarzałe oprogramowanie; aktualni nadawcy odrzucają te wersje, więc TLS się nie zestawia	Zaktualizuj bibliotekę TLS i serwer poczty; włącz TLS 1.2 i 1.3
Certyfikat nie obejmuje nazwy hosta MX	Weryfikacja MTA-STS się nie powiedzie	Uzyskaj certyfikat, którego SAN zawiera nazwę hosta MX
Certyfikat wygasł lub zaraz wygaśnie	Weryfikacja MTA-STS się nie powiedzie; część nadawców przejdzie na połączenie bez szyfrowania	Odnów go, najlepiej automatycznie

Jeśli Twoją pocztę obsługuje zewnętrzny dostawca, za hosty MX i ich certyfikaty odpowiada on, ale MTA-STS i TLS-RPT dla swojej domeny możesz opublikować samodzielnie. Politykę sprawdzisz narzędziem Sprawdzanie MTA-STS, a rekord raportów — narzędziem Sprawdzanie TLS-RPT.

Dlaczego port 25 może być u Ciebie zablokowany

Test z laptopa często kończy się, zanim SMTP w ogóle wystartuje. Wielu dostawców internetu domowego i mobilnego blokuje wychodzące połączenia na port 25, żeby zainfekowane komputery nie rozsyłały spamu; to samo robią platformy chmurowe: Amazon EC2 domyślnie blokuje port 25 do adresów publicznych, Google Compute Engine — do miejsc docelowych poza siecią VPC, a Azure — dla większości typów subskrypcji. Przekroczenie czasu połączenia z Twojej sieci nie oznacza więc, że serwer MX nie działa. Użyj naszego narzędzia albo testuj z serwera, który może nawiązywać połączenia wychodzące na port 25:

openssl s_client -starttls smtp -connect mx1.example.net:25 -crlf -servername mx1.example.net -verify_hostname mx1.example.net -brief

Opcja -brief pokazuje wersję protokołu i to, czy certyfikat przeszedł weryfikację dla tej nazwy hosta. Jeśli Twoja aplikacja musi wysyłać pocztę z takiej sieci, przekazuj ją do serwera pośredniczącego (relay) na port 587 lub 465 z uwierzytelnianiem, zamiast dostarczać bezpośrednio na port 25.