SMTP TLS Downgrade: 92% luka za DMARC

Atak SMTP TLS downgrade zdejmuje szyfrowanie z wiadomości e-mail w trakcie transmisji, a większość domen nie potrafi go zablokować. Klasyczne szyfrowanie SMTP jest oportunistyczne: serwery oferują STARTTLS, ale jeśli atakujący znajdujący się na trasie usunie tę ofertę, serwer wysyłający po cichu przechodzi na cleartext zamiast odmówić wysyłki. Jedynymi rekordami, które czynią TLS obowiązkowym, są MTA-STS i DANE. Rozwiązaliśmy publiczny DNS dla Tranco top 25 000 witryn i odczytaliśmy te rekordy dla 18 012 domen odbierających pocztę. Wynik jest wyraźnie rozdwojony. Uwierzytelnianie jest powszechne: 79,3% publikuje DMARC, a 55,2% je egzekwuje. Egzekwowanie szyfrowania transmisji jest rzadkością: tylko 3,3% publikuje politykę MTA-STS, 3,6% publikuje rekord DANE, a jedynie 6,5% publikuje którekolwiek z nich. Zestawiając te dwie liczby, luka jest uderzająca: spośród domen egzekwujących DMARC, 92% nie publikuje ani MTA-STS, ani DANE, więc ich poczta jest uwierzytelniona przeciw podszywaniu, ale wciąż podatna na downgrade w trakcie transmisji.
Czym faktycznie jest atak SMTP TLS downgrade
Komunikacja SMTP między serwerami pocztowymi zaczyna się w postaci jawnego tekstu. Serwer odbierający ogłasza swoje możliwości, a jeśli obsługuje szyfrowanie, wymienia STARTTLS wśród nich. Serwer wysyłający wydaje wtedy STARTTLS, i obie strony negocjują sesję TLS. Słabość tkwi w słowie oportunistyczne. Jeśli funkcja STARTTLS nie jest ogłoszona, albo negocjacja TLS się nie powiedzie, albo certyfikat nie przejdzie walidacji, historyczne domyślne zachowanie nie polega na przerwaniu. Polega na wysłaniu poczty mimo to w postaci jawnej, w oparciu o założenie, że dostarczenie wiadomości liczy się bardziej niż jej zaszyfrowanie.
To domyślne zachowanie jest tym, co wykorzystuje atakujący. Przeciwnik z pozycją na trasie sieciowej, operator u dostawcy tranzytu, ktoś, kto przejął router, aktor państwowy na granicy, obserwuje początkową wymianę jawnego tekstu i usuwa linię STARTTLS z listy możliwości odbiorcy, zanim dotrze ona do nadawcy. Nadawca, nie widząc oferty szyfrowania, dostarcza wiadomość w postaci jawnej. To jest właśnie STARTTLS stripping i jest to downgrade, a nie złamanie: nic nie zostaje złamane, protokół po prostu zostaje skierowany z powrotem do swojego niezaszyfrowanego wariantu awaryjnego. Wiadomość, jej załączniki i wszelka treść resetu hasła czy faktury podróżują po łączu w postaci jawnej. Społeczność operacyjna APNIC ma zwięzły opis tego mechanizmu (SMTP downgrade attacks and MTA-STS), jeśli potrzebujesz spojrzenia na poziomie pakietów.
Dwa standardy zamykają tę furtkę. MTA-STS (RFC 8461) pozwala domenie opublikować politykę mówiącą w praktyce: „dla mojej poczty przychodzącej TLS z ważnym certyfikatem jest wymagany, nie przechodź na wariant awaryjny”. Nadawca, który pobrał i zapisał tę politykę w pamięci podręcznej, odmówi połączenia po zdjęciu STARTTLS zamiast je zdowngrade'ować. DANE dla SMTP (RFC 7672) spełnia to samo zadanie, publikując w DNS rekord TLSA uwierzytelniony przez DNSSEC, który przypina, jaki certyfikat musi przedstawić serwer pocztowy. Każde z tych rozwiązań zamienia cichy downgrade w odmowę dostarczenia. Żadne z nich nie jest włączone domyślnie i to jest cała historia stojąca za poniższymi liczbami.
Dlaczego DMARC tu nie pomaga
Warto być tu precyzyjnym, bo te dwa problemy są ciągle mylone. DMARC, SPF i DKIM to uwierzytelnianie. Pozwalają odbiorcy zdecydować, czy widoczny adres From jest prawdziwy, a DMARC mówi odbiorcy, co zrobić, gdy nie jest. Tak właśnie powstrzymuje się kogoś przed podszyciem się pod twoją domenę. Zmierzyliśmy tę warstwę we wcześniejszym wpisie o luce między publikowaniem a egzekwowaniem DMARC, i ma to znaczenie. Ale uwierzytelnianie i szyfrowanie są ortogonalne. DMARC działa na tym, za kogo wiadomość się podaje. Atak downgrade działa na warstwie transportowej niosącej wiadomość. Można przejść każdą kontrolę uwierzytelniania z pełnym powodzeniem i nadal mieć połączenie zdjęte do postaci jawnej, bo DMARC nigdy nie miał żadnego zdania na temat transportu.
Więc domena na poziomie p=reject z idealnie zestrojonymi SPF i DKIM rozwiązała problem podszywania się i nie zrobiła nic w sprawie przechwytywania. Poczta, która dociera, jest w sposób dowodliwy od właściwego nadawcy i była czytelna dla każdego na trasie. To jest właśnie nieporozumienie, które ten pomiar ma skorygować: zielona kontrola DMARC to nie zamek na kopercie.
Dane: uwierzytelniona, nie zaszyfrowana
Oto obraz przyjęcia standardów wśród 18 012 domen odbierających pocztę w próbie. Słupek uwierzytelniania jest wysoki. Dwa słupki, które faktycznie powstrzymują downgrade, to ledwie zaczątki.
Poniżej rozbite mechanizmy bezpieczeństwa transportu wraz z tym, co daje każdy z nich. Przeczytaj dwa ostatnie wiersze razem: sumując MTA-STS i DANE, tylko niewielka mniejszość domen pocztowych ma jakiekolwiek egzekwowanie przeciw downgrade'owi, a niemal żadna nie stosuje obu naraz.
| Kontrola | Domeny | Udział | Co to daje poczcie w trakcie transmisji |
|---|---|---|---|
| Rekord polityki MTA-STS | 588 | 3.3% | Informuje nadawców, że TLS jest wymagany, odmawia połączenia po zdjęciu szyfrowania |
| DANE TLSA na hoście MX | 641 | 3.6% | Przypina certyfikat serwera przez DNSSEC, odmawia downgrade'u |
| Raportowanie TLS-RPT | 711 | 3.9% | Raportuje nieudane lub zdowngrade'owane dostawy TLS, nie blokuje |
| Jakiekolwiek egzekwowanie (MTA-STS lub DANE) | 1,166 | 6.5% | Co najmniej jedna kontrola mogąca odmówić downgrade'u |
| Zarówno MTA-STS, jak i DANE | 63 | 0.3% | Pas i szelki, chroni ścieżki pierwszego kontaktu i DNSSEC |
Jeden szczegół w tej tabeli warto zatrzymać na chwilę. DANE (3,6%) jest nieznacznie częstszy niż MTA-STS (3,3%), co przeczy zwykłemu założeniu, że MTA-STS wygrał, bo nie wymaga DNSSEC. Te dwa rozwiązania ledwo się nakładają: tylko 0,3% domen pocztowych publikuje oba. W praktyce są to dwa obozy. Dostawcy i strefy krajowe, które już podpisują DNSSEC, skłaniają się ku DANE, wszyscy inni, którzy w ogóle się tym przejmują, skłaniają się ku MTA-STS, a suma obu wysiłków wciąż pozostawia 93,5% domen pocztowych bez jakiegokolwiek egzekwowania.
Luka 92%
Liczba warta zapamiętania to zestawienie krzyżowe. Spośród 9 945 domen egzekwujących DMARC na poziomie quarantine lub reject, 9 192, czyli 92%, nie publikuje ani polityki MTA-STS, ani rekordu DANE. To nie są maruderzy, którzy zignorowali bezpieczeństwo poczty. To domeny, które wykonały trudniejszą, bardziej widoczną pracę doprowadzenia DMARC do egzekwowania, a potem zatrzymały się jedną warstwę za wcześnie. Uznały, że sfałszowany nadawca jest niedopuszczalny, co jest słuszne, jednocześnie zostawiając właściwą wiadomość czytelną w trakcie transmisji dla każdego, kto jest w stanie zdjąć sesję.
Spójrzmy na to z fotela atakującego, bo to ten fotel decyduje, czy dana kontrola ma znaczenie. Załóżmy, że chcesz odczytać lub zmienić pocztę płynącą do celu, a nie ją sfałszować. Szukasz pozycji na trasie i domeny, która pozwoli się zdowngrade'ować. Sprawdzasz DNS celu tak samo jak my. Jeśli domena publikuje politykę MTA-STS w trybie enforce albo rekord DANE w podpisanej strefie, serwer wysyłający, który to respektuje, odmówi przekazania ci sesji w postaci jawnej, a twój downgrade zawiedzie już u nadawcy. Jeśli domena nie publikuje żadnego z nich, co opisuje 92% zbioru egzekwującego i 93,5% wszystkich domen pocztowych, oportunistyczny STARTTLS jest regułą, a zdjęcie zwraca postać jawną. Postawa DMARC, którą widzisz w tym samym zapytaniu DNS, niczego tu nie zmienia. I tak nigdy nie planowałeś sfałszować nadawcy. Planowałeś odczytać pocztę.
To, co czyni tę liczbę wartą przytoczenia, to sposób jej powstania. Jest to niezależny pomiar pasywny, a nie telemetria dostawcy. Nie raportowaliśmy poczty odfiltrowanej przez jakiś nasz produkt i nie ekstrapolowaliśmy na podstawie strumienia przychodzącego jednego dostawcy. Odczytaliśmy publiczne rekordy polityk, które czyta każdy serwer wysyłający w internecie, dla ustalonej próby w ustalonym dniu. Wcześniejsze badania przyjęcia dochodzą do tych samych wniosków z innych punktów obserwacji: niezależne trackery, takie jak URIports MTA-STS survey, pokazują przyjęcie na poziomie niskich pojedynczych procentów, powoli rosnące, co zgadza się z tym, co widzimy w surowym DNS.
Jak sprawdzić i naprawić własną domenę
Nie potrzebujesz narzędzia ani rejestracji. Zapytanie DNS to pasywny odczyt rekordów, które i tak są publiczne, więc możesz uruchomić te polecenia dla własnej domeny już teraz.
- Sprawdź MTA-STS. Uruchom
dig TXT _mta-sts.yourdomain.com +short. Rekord zaczynający się odv=STSv1oznacza, że ogłaszasz politykę. Jeśli jest pusty, nie masz MTA-STS. Zauważ, że rekord jedynie wskazuje na politykę; plik polityki podhttps://mta-sts.yourdomain.com/.well-known/mta-sts.txtmusi mówićmode: enforce, żeby faktycznie blokować, niemode: testing. - Sprawdź DANE. Najpierw znajdź swoje serwery pocztowe za pomocą
dig MX yourdomain.com +short, a następnie dla każdego hosta MX uruchomdig TLSA _25._tcp.that-mx-host +short. Rekord TLSA oznacza, że DANE jest w grze. DANE waliduje się wyłącznie w strefie podpisanej DNSSEC, więc potwierdź podpisywanie za pomocądig DS yourdomain.com +short. - Włącz raportowanie. Opublikuj rekord TLS-RPT (RFC 8460) pod adresem
_smtp._tls.yourdomain.com, żeby nieudane negocjacje i downgrade'y były raportowane z powrotem do ciebie zamiast pozostawać niewidoczne. To niczego nie blokuje, ale dzięki temu dowiadujesz się, że downgrade w ogóle się dzieje.
Jeśli zarówno zapytanie MTA-STS, jak i TLSA wracają puste, twoja poczta przychodząca jest chroniona przed podszywaniem i wystawiona na przechwytywanie. Rozwiązaniem jest opublikowanie polityki MTA-STS w trybie enforce, rekordu DANE TLSA w podpisanej strefie, albo obu naraz. Zrobienie któregokolwiek z nich stawia cię w nielicznej mniejszości. Wyczucie potrzebne do wdrożenia tego bez zepsucia legalnego doręczania to to samo wyczucie, które stoi za wiedzą, które z twoich innych wystawionych kontroli faktycznie mają znaczenie, co jest właśnie sensem czytania powierzchni ataku tak, jak robi to atakujący, zamiast ufać zielonym ptaszkom.
Czego to nie dowodzi
Uczciwe ograniczenia, bo liczba bez zastrzeżeń to marketing.
- Tranco rankinguje według zagregowanej popularności, nie ruchu. Lista Tranco łączy kilka rankingów dostawców, żeby być stabilna i trudna do manipulacji, ale nie jest spisem ruchu sieciowego. Traktuj te liczby jako jeden uczciwy wycinek popularnej sieci, nie cały internet.
- MTA-STS jest mierzony na poziomie sygnału DNS. Uznaliśmy domenę za posiadającą MTA-STS, jeśli publikuje rekord
_mta-sts. Celowo nie pobieraliśmy pliku polityki, co oznaczałoby kontakt z hostingiem webowym domeny, więc nie możemy odróżnićmode: enforceodmode: testing. Odsetek faktycznie egzekwujących jest więc na poziomie lub poniżej 3,3%, co czyni lukę szerszą, nie węższą. - DANE jest mierzony przez obecność TLSA. Sprawdziliśmy obecność rekordu TLSA na hostach MX, do pięciu na domenę. Opublikowany rekord sygnalizuje intencję i konfigurację; nie weryfikowaliśmy łańcucha DNSSEC ani tego, czy każdy nadawca go waliduje, więc traktuj 3,6% jako sufit poprawnie działającego DANE.
- To jest migawka. DNS zmienia się codziennie. Te liczby opisują 11 sierpnia 2026, nie trend, choć zgadzają się z niezależnymi badaniami pokazującymi niskie i powoli rosnące przyjęcie.
- Egzekwowanie w transmisji wciąż zależy od nadawcy. MTA-STS i DANE pomagają tylko wtedy, gdy serwer wysyłający je respektuje. Publikujący robi to, co należy, ogłaszając politykę; nadawca, który ją ignoruje, wciąż może zdowngrade'ować połączenie. Rekordy są niezbędne, ale same w sobie niewystarczające.
Najczęściej zadawane pytania
Czym jest atak STARTTLS downgrade?
To sytuacja, w której atakujący na trasie sieciowej między dwoma serwerami pocztowymi usuwa ofertę przejścia na TLS z jawnotekstowego początku sesji SMTP. Ponieważ oportunistyczny STARTTLS przechodzi na cleartext, gdy TLS nie jest oferowany, nadawca dostarcza wtedy pocztę bez szyfrowania, a atakujący może ją odczytać lub zmienić. MTA-STS i DANE zamykają tę furtkę, informując nadawcę, że TLS jest wymagany.
Czy SMTP jest domyślnie szyfrowany w trakcie transmisji?
Nie w sposób niezawodny. Większość serwerów oferuje STARTTLS, ale klasyczny SMTP TLS jest oportunistyczny: jeśli oferta jest nieobecna albo certyfikat nie przejdzie walidacji, nadawca po cichu przechodzi na cleartext. Szyfrowanie ma miejsce, gdy nic nie zakłóca połączenia, ale aktywny atakujący może je zdjąć. Tylko 6,5% zmierzonych przez nas domen pocztowych czyni TLS obowiązkowym za pomocą MTA-STS lub DANE.
Czy DMARC szyfruje pocztę w trakcie transmisji?
Nie. DMARC, wraz z SPF i DKIM, uwierzytelnia nadawcę, dzięki czemu odbiorca może wykryć sfałszowany adres From. Nie mówi nic o tym, czy połączenie jest szyfrowane. Domena może egzekwować DMARC na poziomie p=reject i nadal mieć swoją pocztę dostarczaną w postaci jawnej po downgrade'zie. W naszej próbie 92% domen egzekwujących DMARC nie publikowało ani MTA-STS, ani DANE.
Czy MTA-STS zapobiega atakom TLS downgrade?
Tak, to jest jego zadanie. MTA-STS publikuje politykę informującą serwery wysyłające, że twoja domena wymaga TLS z ważnym certyfikatem, więc nadawca, który zapisał tę politykę w pamięci podręcznej, odmawia połączenia po zdjęciu szyfrowania zamiast przechodzić na wariant awaryjny. Jedynym ograniczeniem jest trust-on-first-use: nadawca, który nigdy nie pobrał twojej polityki, nie jest jeszcze objęty ochroną, i tu właśnie DANE, zakotwiczone w DNSSEC, jest mocniejsze.
Jaka jest różnica między MTA-STS a DANE?
Oba wymuszają TLS na przychodzącym SMTP, ale zakotwiczają zaufanie inaczej. MTA-STS opiera się na systemie certyfikatów webowych plus trust-on-first-use i nie wymaga DNSSEC. DANE publikuje rekord TLSA uwierzytelniony przez DNSSEC, co usuwa lukę pierwszego użycia, ale wymaga podpisanej strefy. W naszym spisie zostały przyjęte na niemal tym samym niskim poziomie, 3,3% i 3,6%, a tylko 0,3% domen pocztowych opublikowało oba.
Jaki procent domen wdrożył MTA-STS?
W naszym sierpniowym spisie z 2026 roku listy Tranco top 25 000, spośród 18 012 domen odbierających pocztę, 3,3% opublikowało rekord MTA-STS. DANE był na poziomie 3,6%, a TLS-RPT na 3,9%. Licząc dowolną z kontroli egzekwowania, 6,5% wymaga TLS w transmisji, wobec 79,3% publikujących DMARC.
Jak sprawdzić, czy moja własna domena jest odporna na downgrade SMTP?
Uruchom dig TXT _mta-sts.yourdomain.com +short i szukaj v=STSv1, oraz dig TLSA _25._tcp.your-mx-host +short dla każdego hosta MX. Jeśli oba są puste, twoja poczta przychodząca opiera się na oportunistycznym STARTTLS i może zostać zdowngrade'owana. Opublikowanie polityki MTA-STS w trybie enforce albo rekordu DANE w podpisanej strefie zamyka tę lukę.
Powiązana lektura
- Czy p=none wystarczy? Publikowanie DMARC to nie to samo, co jego egzekwowanie. Warstwa uwierzytelniania, obok której stoi ten wpis.
- Jak bardzo najbardziej ruchliwe domeny świata są wystawione na podszywanie się pod pocztę? Kwestia obecności po stronie ochrony przed podszywaniem.
- Ile czołowych domen ogranicza, kto może wystawiać ich certyfikaty? Ta sama metoda pasywnego DNS, zastosowana do rekordów CAA.
Nie wiesz, co twoja poczta ujawnia na łączu?
Nasz check za $100 czyta twoją zewnętrzną powierzchnię ataku tak, jak robi to atakujący, w zakresie, który zweryfikowałeś jako swoją własność i autoryzowałeś na piśmie, z operatorem seniorem przy odczycie wyników. To, czy twoja poczta może zostać zdowngrade'owana w trakcie transmisji, to jedna z pierwszych rzeczy, na które patrzymy.
Zamów check za $100