• Zaloguj się
  • Zarejestruj się
  • Kontakt z nami
PowerDMARC
  • Cechy
    • PowerDMARC
    • Hostowany DKIM
    • PowerSPF
    • PowerBIMI
    • PowerMTA-STS
    • PowerTLS-RPT
    • PowerAlerts
  • Usługi
    • Usługi wdrożeniowe
    • Usługi zarządzane
    • Usługi pomocnicze
    • Korzyści z usług
  • Wycena
  • Power Toolbox
  • Partnerzy
    • Program Reseller
    • Program MSSP
    • Partnerzy technologiczni
    • Partnerzy branżowi
    • Znajdź partnera
    • Zostań partnerem
  • Zasoby
    • DMARC: Co to jest i jak działa?
    • Karty katalogowe
    • Studia przypadków
    • DMARC w Twoim kraju
    • DMARC według branż
    • Wsparcie
    • Blog
    • Szkolenie DMARC
  • O
    • Nasza firma
    • Klienci
    • Kontakt z nami
    • Zarezerwuj demo
    • Wydarzenia
  • Menu Menu

Co to jest raportowanie SMTP TLS?

Blogi
Czym jest raportowanie SMTP-TLS?

TLS Reporting to mechanizm odwrotnego sprzężenia zwrotnego, który pomaga właścicielom domen znaleźć problemy z dostarczaniem wiadomości e-mail z najwyższą dokładnością. Działa on w połączeniu z MTA-STS i zapewnia dane śledzenia odesłanych wiadomości e-mail, które nie zostały dostarczone z powodu nieudanego uzgadniania TLS.

Co oznacza raportowanie TLS?

TLS Reporting (TLS-RPT) to standard raportowania problemów z dostarczaniem wiadomości e-mail, które występują, gdy wiadomość e-mail nie jest szyfrowana za pomocą TLS. Obsługuje protokół MTA-STS, który jest używany do zagwarantowania, że każda wiadomość e-mail wysłana do domeny zostanie zaszyfrowana TLS.

  • Szyfrowanie TLS zapewnia bezpieczne dostarczanie każdej wysłanej wiadomości e-mail. Atakujący może jednak podjąć próbę downgrade'u SMTP, czyli ataku polegającego na wysłaniu wiadomości e-mail bez szyfrowania, co pozwala na odczytanie lub manipulowanie zawartością. MTA-STS zwalcza to poprzez konieczność szyfrowania wszystkich wiadomości e-mail przed ich wysłaniem do użytkownika. Jeśli atakujący spróbuje wykonać downgrade SMTP, wiadomość e-mail nie zostanie w ogóle wysłana.
  • TLS-RPT umożliwia Tobie, właścicielowi domeny, otrzymywanie raportów o każdym emailu, który nie został zaszyfrowany i nie został do Ciebie wysłany. Możesz wtedy zidentyfikować źródło problemu i naprawić problemy z dostawą.

Jak działa raportowanie TLS?

Jak działa raportowanie TLS?

Raportowanie TLS (TLS-RPT) jest używane do obsługi protokołu MTA-STS, który zapewnia, że wiadomości e-mail są szyfrowane przed dostarczeniem. Normalnie, Twój serwer pocztowy lub Mail Transfer Agent (MTA) negocjuje z serwerem odbiorczym, czy obsługuje on komendę STARTTLS. Jeśli tak, poczta zostaje zaszyfrowana za pomocą TLS i dostarczona do odbierającego MTA.

Atakujący może w tym momencie próbować ataku SMTP downgrade, który polega na zablokowaniu negocjacji pomiędzy MTA wysyłającym i odbierającym. Serwer wysyłający myśli, że odbiorca nie obsługuje komendy STARTTLS i wysyła e-mail bez szyfrowania TLS, umożliwiając atakującemu podgląd lub manipulację treścią e-maila.

Wdrożenie MTA-STS w domenie powoduje, że serwer wysyłający musi szyfrować wiadomości przed ich wysłaniem. Jeśli atakujący spróbuje ataku SMTP downgrade, wiadomość e-mail po prostu nie zostanie wysłana. Zapewnia to szyfrowanie TLS we wszystkich wiadomościach e-mail.

Raportowanie TLS (TLS-RPT) to protokół, który powiadamia właściciela domeny o problemach z dostarczaniem wiadomości e-mail wysyłanych za pośrednictwem domeny. Jeśli wiadomość e-mail nie zostanie wysłana z powodu obniżenia wersji SMTP lub innego problemu, otrzymasz raport w formacie pliku JSON zawierający szczegóły wiadomości e-mail, która nie powiodła się. Raport ten nie zawiera treści wiadomości e-mail.

Dlaczego potrzebujesz raportowania SMTP TLS?

Istotne jest, aby właściciele domen byli informowani o problemach z dostarczaniem wiadomości e-mail z powodu awarii 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. 

Otrzymywanie raportów zwrotnych

Jeśli wiadomość nie zostanie wysłana, raportowanie TLS pomaga w otrzymaniu powiadomienia o tym fakcie

Aby uzyskać całkowitą widoczność kanałów e-mail

Uzyskaj szczegółowy wgląd w przepływ wiadomości e-mail dzięki raportowaniu TLS.

Aby wyeliminować problemy z dostawą

Raportowanie TLS pomaga zidentyfikować źródło problemu i naprawić go bez opóźnień.raport tls

Kroki aktywacji raportowania TLS 

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

Przykład rekordu TLS-RPT

v=TLSRPTv1; rua=mailto:[email protected];

Rozbijmy 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 TLS-RPT.

rua=mailto:[email protected]:

Ten znacznik wskazuje URI raportowania dla raportów zagregowanych (RUA). Określa, gdzie serwer pocztowy odbiorcy powinien wysyłać zagregowane raporty o awariach TLS. rua oznacza "Reporting URI for Aggregated Reports".

Wartość "mailto:[email protected]" to identyfikator URI określający adres e-mail ([email protected]) na który zagregowane raporty powinny być wysyłane pocztą elektroniczną.

W praktyce można zastąpić "yourdomain.com" rzeczywistą nazwą domeny, w której chcesz otrzymywać te raporty.

Znaczenie każdego komponentu:

v=TLSRPTv1:

Wskazuje wersję używanego protokołu TLS-RPT. Pomaga to zapewnić kompatybilność między nadawcą i odbiorcą raportów.

rua=mailto:[email protected]:

Określa miejsce docelowe zagregowanych raportów dotyczących problemów z dostarczaniem TLS. Podając adres e-mail do raportowania, właściciele domen mogą otrzymywać informacje o nieudanych lub problematycznych połączeniach TLS. Raporty są cenne dla diagnozowania potencjalnych problemów z bezpieczeństwem lub konfiguracją związanych z komunikacją e-mail.

Format raportowania TLS i przykład raportu

Raport JSON TLS jest zgodny z określonym formatem zdefiniowanym w specyfikacji TLS-RPT (Transport Layer Security Reporting Policy). Format ten jest używany do przekazywania informacji o problemach z dostarczaniem wiadomości e-mail związanych z szyfrowaniem TLS. Poniżej znajduje się przykład tego, jak może wyglądać raport JSON TLS:

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

TLS-Reporting-Format-and-Report-Example

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 (np. "policy" dla polityki TLS).

policy_string: Określa ciąg polityki powiązany z polityką (np. "reject" dla ścisłej polityki TLS).

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:

  1. certificate_expired: Certyfikat przedstawiony przez zdalny serwer przekroczył datę wygaśnięcia, co czyni go niewiarygodnym do szyfrowania.
  2. certificate_not_valid_yet: Certyfikat przedstawiony przez zdalny serwer nie jest jeszcze ważny, prawdopodobnie z powodu nieprawidłowego czasu serwera lub przedwczesnego użycia certyfikatu.
  3. certificate_revoked: Certyfikat przedstawiony przez zdalny serwer został unieważniony przez urząd certyfikacji ze względów bezpieczeństwa.
  4. untrusted_certificate: Ł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.
  5. no_valid_signature: Certyfikat przedstawiony przez zdalny serwer nie jest prawidłowo podpisany przez zaufany urząd certyfikacji, co budzi obawy co do jego autentyczności.
  6. unsupported_certificate: Certyfikat przedstawiony przez zdalny serwer używa algorytmów szyfrowania lub długości kluczy, które nie są obsługiwane przez serwer pocztowy nadawcy, uniemożliwiając bezpieczne połączenie.

Niezgodność nazwy hosta i tożsamości

  1. hostname_mismatch: Nazwa hosta określona w certyfikacie serwera nie jest zgodna z nazwą hosta serwera, z którym próbuje połączyć się serwer poczty nadawcy, co wskazuje na możliwy atak typu man-in-the-middle lub problem z konfiguracją.

Zestaw szyfrów i konfiguracja szyfrowania

  1. insecure_cipher_suite: Zestaw szyfrów wynegocjowany między serwerami pocztowymi nadawcy i odbiorcy jest uważany za słaby lub niezabezpieczony, co potencjalnie zagraża poufności i integralności komunikacji.
  2. protocol_version_mismatch: Występuje niezgodność w obsługiwanych wersjach protokołu TLS między serwerami pocztowymi nadawcy i odbiorcy, uniemożliwiająca im nawiązanie zgodnego szyfrowanego połączenia.
  3. no_shared_cipher_suite: Nie ma wspólnego zestawu szyfrów dostępnego dla serwerów pocztowych nadawcy i odbiorcy do szyfrowania, co skutkuje nieudanym połączeniem.

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

  1. 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.
  2. unexpected_message: Serwer pocztowy nadawcy otrzymał nieoczekiwaną lub nieobsługiwaną wiadomość podczas procesu uzgadniania TLS, wskazując na potencjalną niezgodność protokołu lub implementacji.

Kwestie polityki MTA-STS

  1. mta_sts_policy_not_found: Ten błąd występuje, gdy serwer pocztowy nadawcy nie może znaleźć polityki MTA-STS dla domeny odbiorcy.
  2. 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.
  3. 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.
  4. 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 TLS.
  5. 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.
  6. mta_sts_policy_upgrade: Ten błąd występuje, gdy serwer pocztowy nadawcy próbuje uaktualnić połączenie do bezpiecznego przy użyciu MTA-STS, ale serwer odbiorcy nie obsługuje aktualizacji.

Uproszczone raportowanie SMTP TLS z PowerDMARC

Simplified-SMTP-TLS-Reporting-with-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 JSON do raportowania TLS są konwertowane na uproszczone informacje, które można przejrzeć w kilka sekund lub przeczytać szczegółowo.

Problemy z autowykrywaniem

Platforma PowerDMARC automatycznie wskazuje problem, z którym się borykasz, dzięki czemu możesz go rozwiązać bez straty czasu.

raport tls

  • O
  • Latest Posts
Ahona Rudra
Digital Marketing & Content Writer Manager w PowerDMARC
Ahona pracuje jako menedżer ds. marketingu cyfrowego i pisania treści w PowerDMARC. Z zamiłowania jest pisarką, blogerką i specjalistką ds. marketingu w dziedzinie bezpieczeństwa cybernetycznego i technologii informacyjnych.
Latest posts by Ahona Rudra (zobacz wszystkie)
  • Jak chronić hasła przed sztuczną inteligencją? - 20 września 2023 r.
  • Czym są ataki oparte na tożsamości i jak je powstrzymać? - 20 września 2023 r.
  • Czym jest ciągłe zarządzanie narażeniem na zagrożenia (CTEM)? - 19 września 2023 r.
27 sierpnia 2020 r./przez Ahona Rudra
Podziel się tym wpisem
  • Udostępnij na Facebooku
  • Udostępnij na Twitterze
  • Udostępnij na WhatsApp
  • Udostępnij na LinkedIn
  • Share by Mail

Zabezpiecz swoją pocztę e-mail

Powstrzymaj spoofing i popraw dostarczalność poczty e-mail

15-dniowy bezpłatny okres próbny!


Kategorie

  • Blogi
  • Wiadomości
  • Komunikaty prasowe

Najnowsze blogi

  • Jak chronić swoje hasło przed sztuczną inteligencją?
    Jak chronić hasła przed sztuczną inteligencją?20 września 2023 - 1:12 pm
  • Czym są ataki oparte na tożsamości i jak je powstrzymać_
    Czym są ataki oparte na tożsamości i jak je powstrzymać?20 września 2023 - 1:03 pm
  • raport tls
    Czym jest ciągłe zarządzanie narażeniem na zagrożenia (CTEM)?19 września 2023 r. - 11:15
  • Czym są ataki DKIM-Replay-Attacks i jak się przed nimi chronić?
    Czym są ataki DKIM Replay i jak się przed nimi chronić?Wrzesień 5, 2023 - 11:01 am
logo stopka powerdmarc
SOC2 GDPR PowerDMARC zgodny z GDPR crown commercial service
globalny sojusz cybernetyczny certyfikowany powerdmarc csa

Wiedza

Co to jest uwierzytelnianie poczty elektronicznej?
Co to jest DMARC?
Co to jest polityka DMARC?
Co to jest SPF?
Co to jest DKIM?
Co to jest BIMI?
Co to jest MTA-STS?
Co to jest TLS-RPT?
Co to jest RUA?
Co to jest RUF?
Antyspam a DMARC
Dostosowanie DMARC
Zgodność z DMARC
Egzekwowanie DMARC
Przewodnik wdrożenia BIMI
Permerror
Przewodnik wdrażania MTA-STS i TLS-RPT

Narzędzia

Darmowy Generator Rekordów DMARC
Darmowy DMARC Record Checker
Darmowy generator rekordów SPF
Darmowy SPF Record Lookup
Darmowy generator rekordów DKIM
Bezpłatne wyszukiwanie rekordów DKIM
Darmowy generator rekordów BIMI
Bezpłatne wyszukiwanie rekordów BIMI
Bezpłatne wyszukiwanie rekordów FCrDNS
Bezpłatna weryfikacja rekordów TLS-RPT
Bezpłatna wyszukiwarka rekordów MTA-STS
Bezpłatny generator rekordów TLS-RPT

Produkt

Wycieczka po produktach
Cechy
PowerSPF
PowerBIMI
PowerMTA-STS
PowerTLS-RPT
PowerAlerts
Dokumentacja API
Usługi zarządzane
Ochrona przed spoofingiem e-mail
Ochrona marki
Anty Phishing
DMARC dla Office365
DMARC dla Google Mail GSuite
DMARC dla Zimbry
Bezpłatne szkolenie DMARC

Wypróbuj nas

Kontakt z nami
Bezpłatna próba
Demo książki
Partnerstwo
Cennik
FAQ
Wsparcie
Blog
Wydarzenia
Żądanie funkcji
Dziennik zmian
Status systemu

  • English
  • Français
  • Dansk
  • Nederlands
  • Deutsch
  • Русский
  • Español
  • Italiano
  • 日本語
  • 中文 (简体)
  • Português
  • Norsk
  • Svenska
  • 한국어
© PowerDMARC jest zastrzeżonym znakiem towarowym.
  • Twitter
  • Youtube
  • LinkedIn
  • Facebook
  • Instagram
  • Kontakt z nami
  • Zasady i warunki
  • Polityka prywatności
  • Polityka dotycząca plików cookie
  • Polityka bezpieczeństwa
  • Zgodność
  • Zawiadomienie GDPR
  • Sitemap
Dlaczego kompromitacja e-maili dostawców jest tak przerażająca (i co możesz zrobić, aby ją powstrzymać)blog wekablog o ograniczaniu spfDlaczego SPF nie wystarcza, aby powstrzymać Spoofing
Przewiń do góry