unieważniony DKIM klucz i brakujący rekord klucza mogą powiedzieć operatorowi różne rzeczy, ale żadne z nich nie zapewnia użytecznego klucza weryfikacyjnego. RFC 6376 §3.1 wyraźnie nie definiuje żadnej semantycznej różnicy pomiędzy unieważnieniem klucza a usunięciem jego rekordu w celu weryfikacji podpisu. Zachowaj to rozróżnienie podczas diagnozowania awarii lub reagowania na kompromis.
Rozpoznaj różne obserwacje
W rekordzie klucza DKIM pusty p= wartość oznacza unieważnienie. Syntaktycznie odpowiednią ilustracyjną wartością odwołania RSA jest v=DKIM1; k=rsa; p=. Nie zawiera klucza prywatnego i nie jest kluczem zastępczym. Użyj dokładnego selektor nazwę właściciela z podpisu, którego dotyczy problem, i postępuj zgodnie z procesem obsługiwanym przez platformę.
Jeżeli rekord klucza nie istnieje, RFC 6376 §6.1.2 wzywa do trwałej porażki bez kluczowego powodu. Pusta wartość klucza publicznego powoduje trwałą awarię z powodu unieważnienia klucza. Zapytanie DNS , które nie odpowiada, jest inną sytuacją i może spowodować tymczasową awarię. Nie należy wywoływać unieważnienia każdego problemu związanego z wyszukiwaniem.
Zamiar operacyjny nadal wymaga dowodów. Pusty klucz może oznaczać zatwierdzoną zmianę awaryjną lub błąd w publikacji. Brakujący rekord może świadczyć o celowym wycofaniu się, złym selektorze lub przypadkowym usunięciu. Porównaj autorytatywny stan DNS , odpowiedź rekurencyjną, znacznik czasu i historię autoryzowanych zmian przed przypisaniem przyczyny.
Wybierz reakcję w zależności od zdarzenia
W przypadku rutynowego wycofywania należy skoordynować koniec podpisywania z okresem, w którym uzasadnione opóźnione wiadomości mogą nadal wymagać starego klucza publicznego. W przypadku podejrzenia naruszenia klucza prywatnego ciągłość i powstrzymywanie mogą powodować konflikt. Przywołaj proces incydentu, ustal, kto może zatwierdzić zmianę i udokumentuj, dlaczego wybrana reakcja jest proporcjonalna.
Odwołanie nie jest natychmiastowe w przypadku wszystkich pamięci podręcznych. RFC 1034 §3.6 opisuje TTL rekordów w pamięci podręcznej. Mechanizm rozpoznawania nazw może zachować wcześniejsze pozytywne dane do momentu zakończenia okresu istnienia pamięci podręcznej. Zmniejszenie TTL po incydencie nie powoduje retrospektywnego skrócenia każdej kopii w pamięci podręcznej. Niektóre programy rozpoznawania nazw mogą udostępniać nieaktualne dane w ramach RFC 8767 §4 gdy odświeżenie jest niedostępne, zatem stary TTL nie jest bezwzględnym ogólnoświatowym terminem unieważnienia. Nie twórz, że edycja DNS natychmiast uniemożliwia każdą kolejną weryfikację przy użyciu starszej odpowiedzi.
Zatrzymanie zainfekowanego podpisującego i ograniczenie nieautoryzowanego dostępu to osobne zadania. Sama zmiana DNS nie przywróci ujawnionego klucza prywatnego ani nie zabezpieczy konta, które go ujawniło. RFC 6376 §8.3 wyjaśnia ryzyko związane z naruszeniem klucza podpisującego. W przypadku rekordów CNAME zarządzanych przez dostawcę określ, kto kontroluje ostateczne dane klucza i która obsługiwana akcja powoduje wycofanie selektora, którego to dotyczy. Nie dodawaj sprzecznych Rekord TXT obok aliasu jako improwizowana poprawka; Widzieć RFC 1034 §3.6.2.
Pracuj nad przykładem opartym na dowodach
W zdarzeniu syntetycznym komunikaty są używane d=example.com; s=oldbilling. Autorytatywna odpowiedź zawiera teraz pustą wartość p=, podczas gdy jeden rekurencyjny program rozpoznawania nazw nadal zwraca wcześniejszy klucz publiczny. W protokole zdarzenia widnieje zatwierdzone wycofanie. Potwierdza to wyjaśnienie przejścia do pamięci podręcznej; nie stwierdza, że wszyscy odbiorcy zaprzestali już sprawdzania poprawności starego podpisu.
Drugi test wykorzystuje s=old-billing, bez łącznika w zamierzonym selektorze. Nie ma żadnych zapisów pod tą nazwą. Błąd wyszukiwania jest rzeczywisty, ale nie dowodzi, że zamierzony selektor został unieważniony. Dokładne nazwy uniemożliwiają połączenie tych dwóch przypadków w jedno.
Zweryfikuj wymianę bez przywracania ekspozycji
Tam, gdzie dozwolone jest dalsze wysyłanie, użyj nowego, bezpiecznie wygenerowanego klucza i obsługiwanego przejścia selektora. Potwierdź wiarygodną publikację i sprawdź otrzymany test z każdej aplikacji, której dotyczy problem. Trzymaj zhakowany klucz poza skryptami odzyskiwania, kopiami zapasowymi przywracanymi aktywnym sygnatariuszom i kopiowanymi szablonami konfiguracji.
Zachowaj starą konfigurację jako dowód incydentu w ramach ograniczonego dostępu, a nie jako cel automatycznego przywracania. Wycofanie zmian, które przywraca złamany sekret podpisu, może odtworzyć problem. Zamknij incydent, informując o autorytecie zmiany, selektorach, których to dotyczy, działaniach zabezpieczających, obserwacjach w pamięci podręcznej i dowodach z nowym podpisem. Nagraj wszystkie starsze, prawidłowe wiadomości, których weryfikacja została celowo poświęcona.
Sklasyfikuj wyszukiwanie przed wybraniem akcji
Użyj ich jako syntetycznych gałęzi diagnostycznych, a nie wyników z prawdziwej domeny:
- Dokładny selektor zwraca pustą wartość p: klucz jest jawnie unieważniany; RFC 6376 wymaga PERMFAIL (klucz unieważniony).
- Dokładny selektor nie ma rekordu klucza: RFC 6376 wymaga PERMFAIL (brak klucza do podpisu). Sprawdź pisownię, delegację i zatwierdzoną historię przejścia na emeryturę.
- Zapytanie nie otrzymuje odpowiedzi: RFC 6376 zezwala na TEMPFAIL (klucz niedostępny). Sama ta uwaga nie stanowi dowodu na unieważnienie.
Wyniki te dotyczą tego podpisu. Zachowaj osobno inne podpisy i ich wyniki; wiadomość może mieć inną ścieżkę uwierzytelniania.
Powiązane lektury
Delegacja DNS DKIM : oceń zakres kontroli przyznanej dostawcy · Przechowuj i chroń klucze prywatne DKIM w systemach podpisujących.