A DKIM błąd skrótu treści oznacza, że weryfikator nie odtworzył pliku skrót ciała zawarte w podpisie, po zastosowaniu odpowiednich zasad podpisu. Nie identyfikuje, który system zmienił wiadomość i nie jest to ta sama diagnoza, co brak klucza publicznego.
Zacznij od zachowania oryginalnej otrzymanej wiadomości. Kopiowanie widocznego tekstu z klienta poczty powoduje utratę struktury MIME , kodowania i innych bajtów ważnych dla weryfikacji.
Potwierdź dokładną awarię
Sprawdź wynik zaufanego odbiorcy i oceniany podpis. Wiadomość może mieć więcej niż jeden Podpis DKIM, a każdy z nich może mieć inną domenę podpisywania lub wynik.
Zapisz d=, s=, algorytm, the c= ustawienie kanonizacji i dowolny znacznik l=długość ciała. Zachowaj dokładny powód weryfikacji. Przekroczono limit czasu wyszukiwania klucza, nieobsługiwany algorytm, niezgodność podpisu nagłówka i niezgodność treści skrótu wymagają różnych dochodzeń.
W RFC 6376 §3.5, wartość bh= jest zakodowanym hashem kanonizowanej treści, podlegającym obróbce o zdefiniowanej długości. Wartość b= należy do obliczenia podpisu. Traktowanie ich jako wymiennych powoduje zaciemnienie tego, które sprawdzenie się nie powiodło.
Zachowaj dowody, które mogą odtworzyć wynik
Zapisz nieprzetworzoną wiadomość za pomocą zatwierdzonej ścieżki eksportu i ogranicz dostęp zgodnie z jej zawartością. Zachowaj otrzymany oryginał w stanie nienaruszonym, z haszem i czasem odbioru, jeśli potwierdza to proces dochodzenia.
Utwórz osobno kopie analityczne. Redakcja adresu, zmiana załącznika lub zapisanie zrekonstruowanej wiadomości może spowodować zmianę materiału istotnego dla weryfikacji. Bezpieczne udostępnianie kopii może być przydatne, ale nie jest automatycznie równoważne zachowanemu oryginałowi.
Zapisz źródło wszelkich wyników weryfikacji. Narzędzie normalizujące zakończenia linii podczas importu może nie oceniać tych samych bajtów, co serwer odbierający. Jeśli dwa narzędzia nie są ze sobą zgodne, najpierw ustal ich dane wejściowe i wspierane zachowanie.
Porównaj wiadomość przed i po prawdopodobnych modyfikatorach
Mapuj rzeczywistą trasę od nadawcy przez bramy, przekaźniki, listy mailingowe i usługi odbierające. Szukaj kontrolowanych schwytań bezpośrednio przed i po podejrzanej transformacji.
Do typowych kandydatów do sprawdzenia zalicza się wstawianie stopki po podpisaniu, przepisywanie adresów URL, ponowne kodowanie MIME , przetwarzanie załączników i naprawy zniekształconych treści. Są to hipotezy, dopóki dowody nie spowodują istotnej zmiany.
Użyj kontrolowanego testu, który podąża tą samą drogą i sprawdza podejrzaną cechę. Porównaj na przykład równoważną wiadomość z regułą stopki bramy i bez niej. Nie generalizuj na podstawie bezpośredniego testu, który omija bramę produkcyjną.
W przypadku syntetycznym przechowywane dane wyjściowe nadawcy sprawdzają się pomyślnie, podczas gdy wiadomość przechwycona po bramce z zastrzeżeniami ma niezgodność skrótu treści. Bramka dodaje stopkę po podpisaniu przez nadawcę. Zgodnie z tymi hipotetycznymi obserwacjami wskazuje to na zależność konfiguracji, którą należy rozwiązać, a nie powód do zastąpienia klucza publicznego DKIM .
Zrozum, co kanonizacja może tolerować
Zasady kanonizacji DKIM pozwalają na szczególne normalizacje. Nie zapewniają one bezpieczeństwa dowolnej edycji treści. Spokojna kanonizacja treści nie jest pozwoleniem na przepisywanie linków lub dodawanie akapitu po podpisaniu.
Sprawdź algorytm określony w podpisie i użyj weryfikatora, który poprawnie go implementuje. Nie diagnozuj na podstawie identycznego wizualnie renderowania: dwa wyświetlane komunikaty mogą zawierać różne oktety ze znakiem.
Pod RFC 6376 §3.5, wartość l= ogranicza kanoniczne oktety treści objęte zdefiniowanymi obliczeniami. Nie jest to ogólna poprawka dla bramy modyfikującej, a celowe pozostawienie treści poza ochroną zmienia ocenę bezpieczeństwa. Użyj obsługiwanych konfiguracji i przejrzyj implikacje, zamiast dodawać limit długości w celu stłumienia symptomu.
Napraw modyfikowaną trasę, a następnie ponownie oceń wyrównanie
Jeżeli organizacja kontroluje trasę, zorganizuj wymagane modyfikacje przed końcowym odpowiednim etapem podpisywania. Jeśli usługa ponownie podpisuje pocztę, sprawdź nową tożsamość podpisującą i czego ona dowodzi. Przechodzący podpis niepowiązanego pośrednika nie jest automatycznie zgodny z oryginałem widocznym w domenie From; RFC 9989 §4.4.1 wymaga dopasowania uwierzytelnionej tożsamości podpisującej.
W przypadku legalnych tras pośrednich pozostających poza kontrolą nadawcy należy ocenić obowiązujące wytyczne dotyczące interoperacyjności. Nie wyłączaj przetwarzania zabezpieczeń ani nie osłabiaj polityki domeny tylko dlatego, że jeden test się nie powiedzie.
Powtórz proces biznesowy, którego to dotyczy, i zachowaj dowody przed i po. Następnie użyj Diagnostyka wyrównania DMARC aby ustalić, czy pozostaje przechodząca wyrównana ścieżka. Incydent kończy się po zrozumieniu istotnej transformacji i jej skutków oraz zweryfikowaniu zamierzonej trasy.
Wybierz następny krok diagnostyczny
Skorzystaj z proponowanej sekwencji decyzyjnej; nie rejestruje żadnego wykonanego testu:
- Brak użytecznego klucza lub przekroczono limit czasu zapytania: postępuj zgodnie z wynikami wyszukiwania poniżej RFC 6376 §6.1.2 zamiast diagnozować stopkę.
- Ponownie obliczony skrót treści różni się od bh: porównaj reprezentację treści, rzeczywiste ustawienia c/l i zarejestrowaną wartość bh w RFC 6376 §6.1.3. Możliwą przyczyną jest również uszkodzony lub nieprawidłowo wygenerowany bh lub błąd w implementacji osoby podpisującej/weryfikatora; samo niedopasowanie nie dowodzi modyfikacji ciała.
- Hash treści jest zgodny, ale podpis nie działa: sprawdź podpisane nagłówki, obliczenia podpisu i relację klucz-sygnatariusz; samo dopasowanie bh nie jest przepustką DKIM .
- Wiele podpisów nie zgadza się: powiąż każdy wynik z jego własnymi d i s, zanim zdecydujesz, czy pozostaje przechodząca wyrównana ścieżka.