The DKIM l tag ogranicza ilość kanonizowanego ciała wnoszonego do skrót ciała. Może pozwolić, aby podpis przetrwał dołączoną treść, ale przetrwanie to polega na pozostawieniu treści poza zasięgiem podpisu. Potraktuj to jako decyzję dotyczącą bezpieczeństwa, a nie rutynową naprawę błędów stopki.
Dowiedz się, co mierzy długość
RFC 6376 sekcja 3.5 definiuje l jako liczbę oktetów w kanonizowanym ciele. Nie jest to liczba znaków, liczba linii ani rozmiar załącznika. Kanonizacja ma miejsce przed zastosowaniem limitu długości. Bez l obejmuje całe kanonizowane ciało. Wartość zero nie pozwala, aby żadna zawartość ciała nie wnosiła wkładu do skrótu; nie oznacza to nieograniczonego zasięgu.
Jeśli l przekracza dostępną kanoniczną długość ciała, podpis jest nieważny zgodnie z zasadami weryfikacji specyfikacji. Górna granica jest wyraźnym wymaganiem w RFC 6376 sekcja 3.5. Zwykłe porównanie rozmiaru pliku nie może wiarygodnie ustalić zasięgu, ponieważ kodowanie transferu i kanonizacja wpływają na odpowiednią reprezentację.
Dowiedz się, dlaczego przepustka może wprowadzać w błąd
Ta funkcja została zaprojektowana tak, aby tolerować dodatki, takie jak zwiastuny list mailingowych. Jednakże, RFC 6376 sekcja 8.2 ostrzega, że dołączona treść może wykorzystywać strukturę MIME lub renderowanie klienta, tak że odbiorca zobaczy wprowadzający w błąd materiał, podczas gdy objęty prefiksem pozostanie nienaruszony. Dlatego też przechodzący podpis nie ustanawia integralności całej wyświetlanej treści, gdy l pozostawia nieosłonięty przyrostek.
Przykładowy scenariusz: osoba podpisująca zakrywa początkowy przedrostek treści. Późniejszy procesor dołącza tekst poza tym przedrostkiem. Podpis może pozostać ważny, jeśli objęty prefiksem i podpisanymi nagłówkami pozostaną niezmienione, a inne kontrole weryfikacyjne przejdą pomyślnie. To jest przykład pokrycia koncepcyjnego, a nie demonstracja, że każde dołączenie MIME daje ten sam wynik lub że określony klient wyrenderuje go bezpiecznie.
Sprawdź przed zmianą polityki
Dla każdego podpisu, którego to dotyczy, zachowaj surową wiadomość, l, c, h, d i selektor. Użyj weryfikatora zgodności lub analizy uwzględniającej bajty, aby określić kanonizowaną długość treści i objęty przedrostek. Zwróć uwagę, czy wybrano nagłówki Content-Type i inne nagłówki istotne z punktu widzenia interpretacji. Przegląd pokrycia nagłówka może ujawnić dodatkowe ryzyko, ale nie powoduje podpisania niepodpisanej treści.
Sprawdź, czy system odbiorcy stosuje specjalne zasady do podpisów o ograniczonej treści. RFC 6376 sekcja 8.2 ostrzega sygnatariuszy, aby zachowywali szczególną ostrożność w stosunku do l i zauważa, że asesorzy mogą zignorować takie podpisy. Nie obiecuj, że matematycznie poprawny podpis przedrostkowy będzie akceptowany wszędzie.
Preferuj pełną treść na granicy podpisania
Jeśli celem jest przetrwanie wychodzącego zastrzeżenia, najpierw rozważ przeniesienie zastrzeżenia przed podpisaniem lub podpisaniem ostatecznej wiadomości w autoryzowanej domenie. W przypadku list mailingowych sprawdź projekt modyfikacji listy i podpisywania. Podejścia te dotyczą kolejności przetwarzania, a nie ukrywania zmienionego sufiksu przed zasięgiem.
Jeśli dotychczasowy przepływ pracy nadal wykorzystuje l, udokumentuj dlaczego, które trasy od niego zależą i jakie pozostaje ryzyko interpretacji przez odbiorcę. Przetestuj usunięcie lub wymianę w kontrolowanej ścieżce z planem wycofywania. Nie zmieniaj po cichu profilu podpisywania całej poczty bez sprawdzenia legalnych opóźnionych i pośrednich tras.
Spraw, aby wynik przeglądu był konkretny
Wynik powinien określać, czy zamierzone jest pokrycie całego ciała czy części, jakie komunikaty to wykorzystują i kto zaakceptował ryzyko szczątkowe. Zachowaj dowód dokładnego podpisu i zakrytego przedstawienia. Ogólna liczba przejść DKIM jest niewystarczająca, aby zamknąć tę recenzję, ponieważ nie mówi nic o tym, ile treści chroni podpis.
Pracuj nad przykładem o kanonicznej długości
Załóżmy, że zgodne narzędzie mierzy kanoniczną treść składającą się ze 140 oktetów, a podpis ma l=100. Hash treści obejmuje pierwsze 100 oktetów; pozostałe 40 znajduje się poza zasięgiem skrótu ciała. Jeśli objęty prefiksem i podpisanymi nagłówkami pozostaną niezmienione, dodana treść może zakończyć się pomyślnie weryfikacją. Jeśli zamiast tego kanonizowana treść ma tylko 80 oktetów przy l=100, wartość narusza sekcję 3.5 RFC 6376 , a podpis jest nieprawidłowy. Są to liczby skonstruowane po kanonizacji, a nie surowe rozmiary plików lub wykonany test kryptograficzny.
Prowadź zwarty zapis dochodzenia
Skorzystaj z sugerowanego arkusza ćwiczeń dla sprawdzanej trasy. Jest to pomoc w planowaniu, a nie dowód przeprowadzonego testu.
- Podpis: d, selektor, c, h i l, lub zaznacz brak l.
- Pokrycie: kanonizowana długość ciała, zakryty przedrostek i przyrostek bez znaku, mierzone za pomocą odpowiedniego narzędzia.
- Interpretacja: pokrycie typów treści i efekty renderowania MIME /klienta.
- Decyzja: usunąć częściowe pokrycie, przeprojektować kolejność podpisania lub udokumentować wyjątek o wąskim zakresie.