Awaria SMTP TLS może wystąpić, gdy połączenie sieciowe i początkowe polecenia SMTP już zadziałały. Nadawca może nie wynegocjować wersji protokołu, odrzucić certyfikat lub otrzymać przerwę w trakcie uzgadniania. Traktuj je jako obserwacje warstwy transportowej, a nie bezpośredni dowód nadawcy SPF Lub DKIM zapis jest błędny.
Zidentyfikuj rodzaj transportu
W SMTP z STARTTLS, klient najpierw ustanawia SMTP , odbiera ogłoszenie o możliwościach, żąda STARTTLS , a następnie rozpoczyna negocjacje TLS po odpowiedzi serwera na temat gotowości. Niejawny TLS uruchamia TLS natychmiast po połączeniu i jest powszechnie używany w przypadku obsługiwanej usługi przesyłania. Mieszanie tych oczekiwań może spowodować awarię połączenia, zanim nastąpi użyteczna wymiana poczty. RFC 3207 sekcje 4 i 5.
Zapisz miejsce docelowe, port, tryb, oprogramowanie do wysyłania, zdalne powitanie SMTP i reklamowane możliwości. Zachowaj, czy awaria wystąpiła przed zaoferowaniem STARTTLS , po poleceniu STARTTLS , podczas przetwarzania certyfikatu lub po uzgadnianiu. Unikaj kopiowania kluczy prywatnych, haseł lub sekretów sesji do pakietu diagnostycznego. Metadane certyfikatów i zredagowane błędy protokołu są zwykle bardziej przydatne niż niejasne stwierdzenie „nie udało się zabezpieczyć połączenia”.
Oceniaj certyfikaty w ramach rzeczywistych zasad
Wygasły certyfikat, nieobsługiwany protokół, niekompletny łańcuch lub niezgodność tożsamości mogą mieć inne znaczenie w zależności od różnych zasad wysyłania. Zwykły oportunistyczny SMTP TLS nie jest tym samym modelem zapewnienia bezpieczeństwa, co połączenie regulowane MTA-STS lub uwierzytelnione DANE. Nazwij egzekwowane zasady, zanim zinterpretujesz, dlaczego nadawca opóźnił dostawę. Nie zakładaj, że każda implementacja SMTP sprawdza każdy certyfikat w identyczny sposób.
RFC 8461 określa wykrywanie, sprawdzanie i egzekwowanie zasad MTA-STS . RFC 7672 definiuje bezpieczeństwo transportu DANE SMTP przy użyciu uwierzytelnienia DNSSEC TLSA informacja. Mechanizmy te mają swoje własne wymagania i obsługę awarii. Ich obecność należy zweryfikować na podstawie faktycznej konfiguracji nadawcy i odpowiednich dowodów wykrycia, a nie wywnioskować po prostu na podstawie pojawienia się błędu TLS w dzienniku.
Przepracuj hipotetyczny błąd tożsamości
Załóżmy, że autoryzowany klient przesyłania jest skonfigurowany do ukrytego TLS w pliku submit.example , ale jego błąd certyfikatu wskazuje oczekiwaną tożsamość old-submit.example . Najpierw potwierdź bieżący udokumentowany punkt końcowy usługi i to, czy klient do niego dociera. Nie zmieniaj oczekiwanej nazwy tylko po to, aby jakikolwiek certyfikat okazał się pozytywny.
Jeśli właściciel usługi potwierdzi, że submit.example jest poprawny, a certyfikat i łańcuch spełniają odpowiednie wymagania dla tego punktu końcowego, zatwierdzona korekta konfiguracji klienta może rozwiązać niedopasowanie. Jeśli punkt końcowy jest poprawny, ale certyfikat jest nieprawidłowy, zamiast tego napraw certyfikat usługi. Pozostaw włączoną weryfikację w obu ścieżkach i ponownie sprawdź tę samą usługę po poprawieniu.
Jest to hipotetyczne drzewo decyzyjne, a nie wykonane uzgadnianie, wydanie certyfikatu lub deklarowana wersja TLS . W przypadku dostarczania MX użyj rzeczywistych reguł tożsamości MTA-STS lub DANE , zamiast importować założenia klienta przesyłania. Certyfikat strony głównej HTTPS nie ustanawia certyfikatu ani zasad punktu końcowego SMTP .
Usuń przyczynę bez usuwania zabezpieczenia
Przypisz odnawianie certyfikatów i wdrażanie łańcucha właścicielowi usługi, zgodność protokołów właścicielowi platformy pocztowej, a przechwytywanie lub przerwy w ścieżce zespołowi sieciowemu. Przed wymianą certyfikatu sprawdź oczekiwaną tożsamość MX i obowiązujące zasady. Wprowadź jedną zatwierdzoną korektę na raz i zachowaj plan wycofywania zmian.
Nie omijaj ostrzeżenia o certyfikacie, nie wyłączaj wymuszania ani nie zezwalaj na zwykły tekst jedynie w celu zaliczenia testu. To, czy nadawca może się wycofać, zależy od protokołu i obowiązujących zasad; rygorystyczna polityka może celowo odroczyć, zamiast dostarczać w sposób niepewny. Pomyślna, niebezpieczna ponowna próba nie wykazałaby, że problem TLS został rozwiązany.
Sprawdź ponownie uruchomioną sesję SMTP
RFC 3207 wymaga odrzucenia wiedzy SMTP sprzed TLS po pomyślnym STARTTLS ; klient powinien wysłać EHLO jako pierwszy odkryje możliwości sesji chronionej, które mogą różnić się od wcześniejszej listy. Potwierdź, że rzeczywisty MTA kończy to przejście, a następnie przesyła autoryzowany komunikat. Rejestruj wszelkie ciągłe opóźnienia w kolejce i wynik końcowy oddzielnie od powodzenia uzgadniania. TLS chroni przeskok transportowy; samo w sobie nie ustala widocznej legalności autora, całkowitej poufności treści ani umiejscowienia w skrzynce odbiorczej.
Zachowaj wymagania bezpieczeństwa podczas naprawy protokołu TLS
- Przechwytywanie punktu końcowego, portu, STARTTLS lub trybu ukrytego i dokładnego etapu zakończonego niepowodzeniem.
- Przed zmianą certyfikatu zidentyfikuj aktywną politykę i oczekiwaną tożsamość.
- Oddzielna nazwa, ważność, łańcuch zaufania i błędy protokołu; wyklucz wpisy tajne z dzienników.
- Zastosuj zatwierdzoną naprawę związaną z konkretną przyczyną bez wyłączania walidacji.
- Niezależnie potwierdź zgodny z zasadami protokół TLS , reset stanu po STARTTLS i wynik komunikatu.