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) stanowi kamień węgielny w zapewnianiu poufności i integralności 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 to skrót od Transport Layer Security Reporting. Jest to standard zgłaszania problemów z dostarczaniem wiadomości e-mail, które występują, gdy wiadomość e-mail nie jest szyfrowana 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:tlsrpt@yourdomain.com;
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:tlsrpt@yourdomain.com: 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:tlsrpt@example.com,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": "smtp-tls-reporting@organization.com",
"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. |
| 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.
Dodatkowe zasoby
- SPF Softfail vs Hardfail: Jaka jest różnica? - 26 kwietnia 2024 r.
- FTC donosi, że poczta e-mail jest popularnym medium do oszustw związanych z podszywaniem się pod inne osoby - 16 kwietnia 2024 r.
- SubdoMailing i wzrost popularności phishingu subdomenowego - 18 marca 2024 r.