DOSTOSUJ Kiedy mówimy o „Email Authentication”, mamy na myśli technikę, która daje odbiorcy wiadomości pewność, że wiadomość faktycznie pochodzi od deklarowanego źródła wiadomości.
Kiedy mówimy o „Email Authentication”, mamy na myśli technikę, która zapewnia odbiorcy wiadomości pewien poziom pewności, że wiadomość rzeczywiście pochodzi od podanego źródła wiadomości. Idea takich technik polega na uzyskaniu pewnego poziomu obrony przed fałszywymi e-mailami, takimi jak phishing i spoofing, wiadomości, które mogą osłabić zaufanie odbiorcy do otrzymywania e-maili. To powiedziawszy, samo wysyłanie uwierzytelnionych wiadomości e-mail nie oznacza, że wiadomość jest dobra lub pożądana; oznacza tylko, że wiadomość jest taka, że można wiarygodnie ustalić reputację strony uwierzytelnionej i użyć jej przy decyzjach o akceptacji i umieszczeniu wiadomości e-mail.
Obecnie stosuje się dwie formy uwierzytelniania e-maili:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
W dzisiejszym poście omówię, czym jest DKIM i jak działa.
Przegląd DKIM
W przeciwieństwie do swojego odpowiednika autoryzacyjnego SPF, który zapewnia sposób, aby domena autoryzowała hosta do wysłania poczty w jego imieniu, DKIM zapewnia sposób, aby podmiot (domena, organizacja, osoba, itp.) wziął odpowiedzialność za wiadomość, niezależnie od podmiotu, który faktycznie wysłał wiadomość. Chociaż w wielu przypadkach odpowiedzialny podmiot i wysyłający podmiot będą tym samym lub przynajmniej ściśle powiązanym, z DKIM nie ma obowiązku, aby tak było.
Moje cele dla ciebie z tym postem są takie, żebyś nauczył się i zrozumiał następujące pojęcia dotyczące DKIM:
DKIM to uwierzytelnianie oparte na „zawartości”, w przeciwieństwie do SPF opartego na „ścieżce”.
Odpowiedzialny podmiot potwierdza swoją odpowiedzialność poprzez „podpisanie” wiadomości parą kryptograficznych skrótów umieszczonych w nagłówku wiadomości.
Walidacja DKIM odbywa się przez domenę odbierającą, która próbuje wygenerować te same dwa skróty.
Walidacja DKIM nie może być ukończona w wielu przypadkach, dopóki pełna wiadomość nie zostanie przesłana przez serwer wysyłający.
Niepowodzenia walidacji mogą być trudne do rozwiązywania.
„Content-Based” Authentication
Podpisywanie i walidacja DKIM
Organizacje, które chcą podpisywać pocztę za pomocą DKIM, najpierw wygenerują dwa klucze kryptograficzne. Jeden z kluczy jest przechowywany w tajemnicy i dostępny dla serwera wysyłającego do podpisywania poczty, a drugi należy upublicznić w DNS do użytku przez domeny odbierające w celu weryfikacji podpisu. Metody generowania tych kluczy i ich instalacji są zależne od platformy i wykraczają poza zakres tego wpisu, chociaż później opiszę publikację publicznego klucza DKIM w DNS.
Nagłówek DKIM-Signature
Aby rozpocząć zrozumienie DKIM, najpierw spójrzmy na nagłówek DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Nagłówek DKIM-Signature to seria par klucz-wartość, niektóre z nich są bardziej interesujące dla czytelnika niż inne, ale wszystkie z nich tutaj opiszę.
Najpierw przyjrzymy się tym, które są głównie przejściowo interesujące dla czytelnika:
v=1; – Określa wersję DKIM (1 to jedyna poprawna wartość)
a=rsa-sha256; – Algorytm używany do konstrukcji kryptograficznych hashy
c=relaxed/relaxed; – Istnieją dwa zestawy zasad dotyczące usuwania białych znaków w nagłówkach i ciele, które mogą być stosowane podczas tworzenia hashy w podpisie DKIM; te zasady nazywane są „canonicalization rules” (stąd klucz c) i zestawy zasad są albo „relaxed” albo „strict”.
t=1454417737; – Znacznik czasu utworzenia podpisu.
Te trzy części nagłówka zawierają faktyczne informacje o podpisie:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – To jest hash ciała wiadomości.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – To jest lista nagłówków, które zostały użyte do stworzenia danych podpisu pokazanych poniżej.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – To są dane faktycznego podpisu DKIM
Te trzy części są najważniejsze dla serwera odbierającego, który będzie walidować podpis:
d=welcome.foo.com; – To identyfikuje domenę, która podpisała wiadomość
s=notices; – Selektor; domeny mogą mieć wiele selektorów, które używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość w imieniu której wiadomość została podpisana. Syntaktycznie, to będzie wyglądać jak adres e-mail i może nawet być nim; część lokalna adresu e-mail może być pusta, jak w tym przykładzie, a część domenowa musi być taka sama jak, lub subdomeną, domeną w części d= podpisu.
Powodem, dla którego te części są interesujące dla serwera odbierającego, jest to, że dostarczają one niezbędnych informacji do pomocy odbiorcy w walidacji podpisów.
DKIM Validation
Oprócz wymogu wspomnianego, że domena i= musi być taka sama jak domena d= lub być domeną podrzędną, bity d= i s= są używane przez walidator do wyszukiwania publicznego klucza DKIM podpisującego w DNS. Klucz jest rekordem TXT w DNS i jest zawsze odnajdywany w lokalizacji selector._domainkey.domain. Tak więc w naszym przykładzie, z s=notices i d=welcome.foo.com, publiczny klucz DKIM byłby odnajdywany w DNS pod adresem notices._domainkey.welcome.foo.com, i mógłby wyglądać następująco:
notices._domainkey.welcome.foo.com. opisowy tekst "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Walidator używa tego klucza (bitów p=) do stworzenia własnego zestawu skrótów wiadomości; jeżeli te skróty się zgadzają, wtedy wiadomość nie została zmieniona w trakcie przesyłu i w związku z tym może przyczynić się do, a może również skorzystać z reputacji, która jest związana z podpisującym wiadomość.
Błąd walidacji i rozwiązywanie problemów
Wspomniałem wcześniej, że niepowodzenia DKIM mogą być trudne do rozwiązania, i wyjaśnię tutaj, dlaczego tak jest.
Niektóre niepowodzenia w walidacji DKIM mają oczywiste przyczyny, takie jak brak podpisania wiadomości, brak odnalezienia klucza publicznego domeny podpisującej w DNS lub brak poprawności składniowej, lub być może wiadomość została wyraźnie zmieniona podczas przesyłania. Gdy mają miejsce takie rodzaje niepowodzeń, łatwo jest zidentyfikować problem i zarekomendować rozwiązanie. Jednakże te trudne przypadki i te, które prowadzą do najbardziej frustrujących doświadczeń wsparcia, to sytuacje, w których wiadomość została podpisana, klucz publiczny istnieje w DNS, a wiadomość nie była wyraźnie zmieniona, lecz walidator zgłasza, że podpis nie przeszedł walidacji.
Powodem, dla którego są one trudne do rozstrzygnięcia, jest to, że nie ma rzeczywistego sposobu dla żadnej ze stron, aby odtworzyć warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość zawiera w nagłówku DKIM-Signature hashe, które zostały wygenerowane przez podpisującego w momencie podpisywania, ale walidator prawdopodobnie nie ma dostępu do infrastruktury podpisującego, a zatem nie może spróbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora, a więc nie ma sposobu, aby spróbować zweryfikować wiadomość w sposób, w jaki zrobił to walidator.
Niepowodzenia, które tutaj opisuję, zdarzają się rzadko, a same niepowodzenia w walidacji DKIM zazwyczaj nie mają wpływu na umiejscowienie dostarczenia. Chociaż DKIM zajmuje się uwierzytelnianiem wiadomości, wdrożenie kompleksowych technik weryfikacji emaili zapewnia wysyłanie na prawdziwe adresy, które rzeczywiście mogą odbierać i uwierzytelniać wiadomości. Z mojego doświadczenia wynika, że takie niepowodzenia generują więcej zgłoszeń wsparcia niż jakiejkolwiek inne problemy związane z DKIM.
