Ponieważ organizacje w coraz większym stopniu polegają na poczcie elektronicznej jako podstawowym środku komunikacji, nie można przecenić znaczenia wzmocnienia tych kanałów przed potencjalnymi zagrożeniami. Transport Layer Security (TLS) zapewnia poufność i integralność danych przesyłanych przez sieci.

Kilka protokołów pomaga szyfrować kanały wiadomości SMTP, aby uniemożliwić cyberatakom przechwytywanie komunikacji e-mail. Należą do nich STARTTLS, DANE i MTA-STS. Jednakże, gdy próby szyfrowania nie powiodą się podczas korzystania z tych protokołów, wiadomość e-mail może nie zostać dostarczona. TLS-RPT (jak opisano w RFC 8460) zapewnia mechanizm informacji zwrotnej do zgłaszania tych niepowodzeń dostarczalności.

Zdecydowanie zalecamy używanie TLS-RPT w połączeniu z MTA-STS protokół. Zrozummy, jak te protokoły współpracują ze sobą, aby wzmocnić bezpieczeństwo poczty e-mail.

Co to jest TLS-RPT?

TLS-RPT (Transport Layer Security Reporting) to standard zgłaszania problemów z dostarczaniem wiadomości e-mail, gdy nie są one szyfrowane za pomocą TLS. Jego znaczenie w uwierzytelnianiu wiadomości e-mail idzie w parze z powodem włączenia szyfrowania TLS dla wiadomości e-mail.

Szyfrowanie TLS zapewnia bezpieczne dostarczanie każdej wysłanej wiadomości e-mail. W przypadku, gdy połączenie nie jest bezpieczne, wiele razy wiadomości e-mail mogą nie zostać dostarczone. TLS-RPT umożliwia właścicielom domen monitorowanie dostarczania wiadomości e-mail i awarii połączeń. Raporty mogą zawierać informacje na temat:

Problemy z obsługą zasad MTA-STS
Przyczyna i typ niepowodzenia dostawy
Adres IP agentów transferu poczty wysyłających i odbierających wiadomości e-mail
Całkowita liczba udanych i nieudanych sesji połączeń TLS

Zapewnia to widoczność kanałów e-mail i możliwość szybszego przeciwdziałania wyzwaniom związanym z dostarczalnością.

Jak działa raportowanie TLS?

W komunikacji e-mail SMTP szyfrowanie TLS jest "oportunistyczne". Oznacza to, że jeśli nie można wynegocjować szyfrowanego kanału, wiadomość e-mail jest nadal wysyłana w formacie niezaszyfrowanym (zwykły tekst). W rzeczywistości, prawie 4 dekady temu, protokoły poczty elektronicznej SMTP nie obsługiwały szyfrowania TLS. Musiało ono zostać wprowadzone później w postaci polecenia STARTTLS.

Polecenie STARTTLS jest wydawane tylko w komunikacji SMTP, jeśli obie strony obsługują szyfrowanie TLS. W przeciwnym razie wiadomość e-mail zostanie wysłana w postaci zwykłego tekstu.

Aby pozbyć się oportunistycznego szyfrowania w SMTP, wprowadzono MTA-STS (RFC 8461). Protokół MTA-STS zapewnia szyfrowanie wiadomości e-mail przed ich dostarczeniem. Serwer poczty e-mail lub Mail Transfer Agent (MTA) negocjuje z serwerem odbierającym, aby sprawdzić, czy obsługuje on polecenie STARTTLS. Jeśli tak, wiadomość e-mail jest szyfrowana za pomocą TLS i dostarczana. W przeciwnym razie dostarczenie nie powiedzie się.

Przyczyn niepowodzenia szyfrowania TLS może być kilka. Oprócz braku wsparcia dla szyfrowania po obu stronach, bardziej złowieszcze powody, takie jak atak SMTP downgrade, mogą prowadzić do niepowodzenia połączenia TLS. Dzięki włączonemu MTA-STS atakujący nie są w stanie dostarczyć wiadomości w postaci zwykłego tekstu, gdy połączenie nie powiedzie się.

Ale właściciele domen chcieliby wiedzieć o nieudanej dostawie. Raportowanie TLS (TLS-RPT) to protokół, który powiadomi Cię o tym. W przypadku niepowodzenia dostawy otrzymasz raport TLS w formacie pliku JSON na adres e-mail zdefiniowany w rekordzie TLS-RPT.

Dlaczego potrzebujesz raportowania SMTP TLS?

Właściciele domen muszą być na bieżąco z wiadomościami e-mail.

Problemy z dostarczaniem spowodowane awariami szyfrowania TLS dla wiadomości e-mail wysyłanych z domeny obsługującej MTA-STS. Raportowanie TLS umożliwia to poprzez dostarczanie tych informacji. TLS-RPT

Aby otrzymywać raporty zwrotne, które podkreślają typ polisy i
Aby zidentyfikować przyczynę błędów szyfrowania TLS
Aby uzyskać widoczność w kanałach e-mail
Aby naprawić problemy z dostawą

Kroki konfiguracji TLS-RPT

Możesz włączyć raportowanie TLS dla swojej domeny, tworząc rekord TXT dla TLS-RPT i publikując go w DNS. Rekord ten musi być opublikowany w subdomenie smtp.tls.yourdomain.com

Krok 1: Wybór narzędzia do generowania rekordów TLS-RPT

Możesz zarejestrować się w PowerDMARC za darmo i skorzystać z naszego generatora rekordów TLS-RPT, aby utworzyć swój rekord.

Krok 2: Wprowadź swój adres e-mail do raportowania

Wprowadź adres e-mail, na który chcesz otrzymywać raporty SMTP TLS.

Krok 3: Opublikowanie rekordu TLS w systemie DNS

Możesz skontaktować się z rejestratorem domeny, aby utworzyć nowy rekord TXT dla TLS-RPT. Jeśli zarządzasz własnym DNS, edytuj ustawienia DNS, aby uwzględnić rekord.

Przykład rekordu TLS-RPT

Składnia: v=TLSRPTv1; rua=mailto:[email protected];

Rozbijmy 2 składniki dostarczonego rekordu raportowania TLS:

v=TLSRPTv1: Ten znacznik określa wersję używanego protokołu TLS-RPT. W tym przypadku, "TLSRPTv1" oznacza pierwszą wersję protokołu.
rua=mailto:[email protected]: rua oznacza "Reporting URI(s) for Aggregate Data". Ten znacznik określa, gdzie serwer pocztowy odbiorcy powinien wysyłać zagregowane raporty TLS.

Można skonfigurować więcej niż jedno miejsce docelowe do odbierania raportów. W przypadku wielu miejsc docelowych należy oddzielić każdy wpis przecinkiem (,). Możesz użyć "maito:", aby określić adres e-mail dla tego kroku lub poinstruować MTA, aby przesyłał raporty za pośrednictwem POST do adresów URL punktów końcowych, używając "https:" w polu rua=. Jeśli używasz "https:" , upewnij się, że pole definiuje adres URL do serwera WWW obsługującego protokół HTTPS z ważnym certyfikatem. Zarówno "mailto:", jak i "https:" mogą być również używane w jednym rekordzie, oddzielone przecinkiem.

Przykład: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

Uwaga: W praktyce należy zastąpić "yourdomain.com" rzeczywistą nazwą domeny, w której chcesz otrzymywać te raporty.

Format raportowania TLS

Raporty TLS są wysyłane w formacie JSON. Poniżej znajduje się przykład tego, jak może wyglądać raport JSON TLS:

{

"organization-name": "Organization Inc.",

“date-range”: {

"start-datetime": “2020-10-22T00:00:00Z”,

"end-datetime": “2020-10-22T23:59:59Z”

"contact-info": "[email protected]",

"report-id": “2020-10-22T00:00:00Z_domain.com”,

"policies": [

{

“policy”: {

"typ polityki": "sts",

"policy-string": [

"version: STSv1",

"tryb: testowanie",

"mx: mx.domain.com",

"mx: mx2.domain.com",

"mx: mx3.domain.com",

"max_age: 604800"

"policy-domain": "domain.com"

“summary”: {

"total-successful-session-count": 15,

"total-failure-session-count": 0

}

Oto podział głównych pól w tym raporcie JSON TLS:

Pola	Opis
organizacja	Organizacja domeny, która jest właścicielem rekordu TLS-RPT.
e-mail	Adres e-mail, na który wysyłane są raporty zbiorcze.
begin_date	Data rozpoczęcia okresu sprawozdawczego.
end_date	Data zakończenia okresu sprawozdawczego.
polityki	Tablica obiektów zasad opisujących zasady stosowane w okresie sprawozdawczym.
polityka	Zawiera informacje o zastosowanej polityce.
policy_type	Określa typ polityki
policy_string	Określa ciąg znaków powiązany z polityką
tryb	Określa tryb polityki MTA-STS (wymuszanie/testowanie).
podsumowanie	Zawiera podsumowanie informacji o sesjach, których próbowano użyć.
total_successful_session_count	Całkowita liczba pomyślnie nawiązanych sesji TLS.
total_failure_session_count	Całkowita liczba niepowodzeń sesji TLS.
failure_details	Tablica obiektów, które dostarczają szczegółowych informacji o określonych awariach.
powód	Ciąg znaków wskazujący przyczynę niepowodzenia (np. "certificate_expired").
liczyć	Liczba sesji, które zakończyły się niepowodzeniem z określonego powodu.

Przyczyny i typy błędów szyfrowania TLS

Kwestie związane z certyfikatami

Typy awarii	Powody	Możliwe sugestie dotyczące rozwiązywania problemów
certificate_expired	Certyfikat przedstawiony przez zdalny serwer przekroczył datę wygaśnięcia. To czyni go niewiarygodnym do szyfrowania.	Odnów swój certyfikat.
certificate_not_valid_yet	Certyfikat przedstawiony przez zdalny serwer nie jest jeszcze ważny. Może to być spowodowane nieprawidłowym czasem serwera lub przedwczesnym użyciem certyfikatu.	Skontaktuj się z dostawcą certyfikatu.
certificate_revoked	Certyfikat przedstawiony przez zdalny serwer został unieważniony przez urząd certyfikacji ze względów bezpieczeństwa.	Skontaktuj się z dostawcą certyfikatu.
no_valid_signature	Łańcuch certyfikatów przedstawiony przez zdalny serwer nie jest zaufany przez serwer lub klienta poczty nadawcy, co wskazuje na potencjalne zagrożenie bezpieczeństwa.	Skontaktuj się z dostawcą certyfikatu.
unsupported_certificate	Certyfikat przedstawiony przez zdalny serwer wykorzystuje algorytmy szyfrowania lub długości kluczy, które nie są obsługiwane przez serwer pocztowy nadawcy, uniemożliwiając bezpieczne połączenie.	Skontaktuj się z dostawcą certyfikatu.

Niezgodność nazwy hosta i tożsamości

Typ awarii	Powód	Możliwe sugestie dotyczące rozwiązywania problemów
hostname_mismatch	Nazwa hosta określona w certyfikacie serwera nie jest zgodna z nazwą hosta serwera, z którym próbuje się połączyć serwer pocztowy nadawcy. Wskazuje to na możliwy atak typu man-in-the-middle lub problem z konfiguracją.	Sprawdź rekordy MX w pliku zasad MTA-STS, aby upewnić się, że są one zgodne z rekordem MX dla domeny.

Uścisk dłoni i kwestie związane z protokołem

Typy awarii	Powody	Możliwe sugestie dotyczące rozwiązywania problemów
handshake_failure	Wystąpił błąd podczas początkowego procesu uzgadniania TLS między serwerem pocztowym nadawcy a serwerem pocztowym odbiorcy, uniemożliwiając ustanowienie bezpiecznego kanału.	Należy dwukrotnie sprawdzić, czy połączenie SMTP STARTTLS zostało nawiązane. Może być kilka przyczyn przyczyniających się do niepowodzeń szyfrowania, takich jak brak wsparcia dla STARTTLS lub atak TLS downgrade.

Kwestie polityki MTA-STS

Typy awarii	Powody	Możliwe sugestie dotyczące rozwiązywania problemów
mta_sts_policy_not_found	Ten błąd występuje, gdy serwer pocztowy nadawcy nie może znaleźć polityki MTA-STS dla domeny odbiorcy.	Przejrzyj plik zasad MTA-STS. Sprawdź swój rekord MTA-STS, aby upewnić się, że został opublikowany poprawnie.
mta_sts_policy_invalid	Ten błąd występuje, gdy polityka MTA-STS znaleziona w DNS dla domeny odbiorcy jest nieprawidłowa, zawiera błędy lub nie jest zgodna ze specyfikacją MTA-STS.	Przejrzyj plik zasad MTA-STS. Określ odpowiedni tryb polityki MTA-STS. Może to być Brak, Wymuszanie lub Testowanie. Instruuje to serwery wysyłające, jak obsługiwać wiadomości e-mail, które są poddawane błędom walidacji polityki MTA-STS. Dowiedz się więcej o trybach polityki tutaj.
mta_sts_policy_fetch_error	Ten błąd występuje, gdy serwer pocztowy nadawcy napotyka błąd podczas próby pobrania polityki MTA-STS z rekordów DNS domeny odbiorcy.	Sprawdź poprawność rekordów MTA-STS w DNS, aby upewnić się, że składnia rekordu jest poprawna.
mta_sts_connection_failure	Ten błąd występuje, gdy serwer pocztowy nadawcy próbuje nawiązać bezpieczne połączenie przy użyciu MTA-STS, ale kończy się niepowodzeniem z powodów takich jak niezaufane certyfikaty, nieobsługiwane zestawy szyfrów lub inne problemy z TLS.	Sprawdź ważność certyfikatu i upewnij się, że jest on zgodny z najnowszym standardem TLS.
mta_sts_invalid_hostname	Ten błąd występuje, gdy nazwa hosta serwera pocztowego odbiorcy, określona w polityce MTA-STS, nie jest zgodna z rzeczywistą nazwą hosta serwera.	Sprawdź rekordy MX w pliku zasad MTA-STS, aby upewnić się, że są one zgodne z rekordem MX dla domeny.

Uproszczone raportowanie SMTP TLS z PowerDMARC

Raportowanie SMTP TLS w PowerDMARC ma na celu poprawę bezpieczeństwa przy jednoczesnym ułatwieniu życia dzięki hostowanej usłudze.

Przetłumaczone raporty TLS

Złożone raporty TLS-RPT JSON są konwertowane na uproszczone informacje, które można przejrzeć w kilka sekund lub przeczytać szczegółowo.

Problemy z autowykrywaniem

Platforma PowerDMARC wskazuje i podkreśla napotkany problem, dzięki czemu można go rozwiązać bez marnowania czasu.

Nie ma jednej rzeczy, którą lubię w platformie PowerDMARC, mają łatwy w użyciu i zrozumiały układ z czymś, co nazwałbym pełnymi funkcjami pozwalającymi na hostowaną kontrolę DMARC, spłaszczanie SPF, możliwość łatwego rozszerzania SPF w celu sprawdzenia specyfiki rekordu, a nawet pełne wsparcie dla MTA-STS i TLS-RPT!

Dylan B (Właściciel firmy)

Często zadawane pytania dotyczące zabezpieczeń warstwy transportowej

1. Co oznacza skrót TLS?

TLS to skrót od Transport Layer Security.

2. Kto wydaje certyfikaty TLS?

Urzędy certyfikacji (CA) mogą wydawać certyfikaty TLS. Proces wydawania certyfikatu obejmuje weryfikację tożsamości posiadacza certyfikatu. Po pomyślnej identyfikacji wydawany jest certyfikat.

3. Dlaczego potrzebuję certyfikatu TLS?

Certyfikaty TLS odgrywają kluczową rolę w zabezpieczaniu komunikacji w Internecie. Pomagają one szyfrować poufne informacje wymieniane między komunikującymi się serwerami internetowymi. Niektóre z jego najczęstszych zastosowań obejmują zabezpieczanie komunikacji e-mail i HTTPS.

4. Jaki jest obecny standard TLS?

TLS 1.3 jest najnowszą wersją Transport Layer Security. TLS-RPT może być zaimplementowany przy użyciu dowolnej wersji TLS. Może to obejmować starsze wersje protokołu lub przyszłe wersje. Wersja jest zwykle określana na podstawie kryteriów, takich jak możliwości komunikujących się serwerów.

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC

Yunes jest liderem zespołu operacyjnego w PowerDMARC z wiedzą ekspercką w zakresie uwierzytelniania i bezpieczeństwa poczty elektronicznej. Yunes jest certyfikowanym przez Microsoft Azure Administrator Associate z certyfikatami CompTIA A+ i wieloma innymi.

Najnowsze posty autorstwa Yunes Tarada (zobacz wszystkie)

Yahoo Japan wymusza przyjęcie DMARC dla użytkowników w 2025 roku - 17 stycznia 2025 r.
Botnet MikroTik wykorzystuje błędne konfiguracje SPF do rozprzestrzeniania złośliwego oprogramowania - 17 stycznia 2025 r.
Nieuwierzytelniona poczta DMARC jest zabroniona [ROZWIĄZANE] - 14 stycznia 2025 r.

Co to jest raportowanie SMTP TLS?