W tej serii widzieliśmy, że dołączenie podpisu S/MIME jest stosunkowo proste. Wysyłanie zaszyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ musisz uzyskać klucze publiczne odbiorców. To jedna rzecz, gdy korzystasz z klienta pocztowego dla ludzi, takiego jak Thunderbird – ale jak to może działać w przypadku generowanych przez aplikację strumieni e-mailowych?
W części 1, przeprowadziliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeprowadziła nas przez prostą narzędziową linię poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wstrzyknąć bezpieczne strumienie poczty do platform lokalnych, takich jak Port25 PowerMTA i Momentum.
W tej serii widzieliśmy, że dołączenie podpisu S/MIME jest stosunkowo proste. Wysyłanie zaszyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ trzeba uzyskać klucze publiczne odbiorców. To inna sprawa, gdy używasz klienta poczty dla ludzi, takiego jak Thunderbird – ale jak to działa w przypadku strumieni e-mail generowanych przez aplikacje? E-maile generowane przez aplikacje, jak te używane przez platformy randkowe, wymagają starannej strategii do maksymalizacji zaangażowania. Zobacz, jak aplikacje randkowe tworzą przyciągające uwagę uruchamiające doświadczenia e-mail.
Ale poczekaj – jest jeszcze inny sposób na dostanie się do Mordor, aby uzyskać te klucze. Twoja usługa może zaprosić Twoich klientów (oczywiście przez e-mail) do przesłania Ci podpisanej wiadomości na znany adres obsługi klienta. Używając magicznych mocy webhooków SparkPost Inbound Relay, wyciągniemy i przechowamy ten klucz publiczny do Twojego użytku.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, przekazuję twojej usłudze mój osobisty podpis e-mailowy poprzez e-mail, aby w przyszłości wiadomości e-mail mogły być wysyłane do mnie w formie zaszyfrowanej S/MIME.
Na tej podstawie wywiedziemy bardziej szczegółowe wymagania:
Potrzebujemy niezawodnej, zawsze włączonej usługi przyjmowania e-maili, aby odbierać te podpisane wiadomości.
Nie powinny istnieć specjalne wymagania dotyczące formatu poczty, poza tym, że powinien on zawierać podpis S/MIME.
Ponieważ każdy może spróbować wysłać wiadomość do tej usługi, powinna ona być zaprojektowana defensywnie, na przykład aby odrzucać „podrobione” wiadomości od złych aktorów. Będzie potrzeba kilku warstw weryfikacji.
Jeśli wszystko się zgadza, usługa zapisze certyfikat w pliku, używając dobrze znanego formatu tekstowego Privacy-Enhanced Mail (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhook z maszyny do maszyny mogą być trudne do zauważenia tylko z odpowiedzi na to, co dzieje się wewnątrz. Usługa powinna zapewniać obszerne, czytelne dla człowieka logi aplikacji na poziomie aplikacji, w szczególności powinno być prowadzone logowanie weryfikacji i parsowanie certyfikatów.
Dodajemy przypadki testowe dla wewnętrznych części aplikacji, używając fajnego frameworka Pytest, a następnie automatycznie uruchamiamy te testy przy zameldowaniu używając integracji Travis CI z GitHub.
OK – zaczynamy!
1. Przegląd rozwiązania
Oto jak będzie wyglądało ogólne rozwiązanie.
2. Instalacja, konfiguracja i uruchamianie aplikacji webowej
3. SparkPost inbound relay webhooks konfiguracja
Po pierwsze, wybieramy domenę do użycia jako nasz adres przychodzącej wiadomości – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę według tego przewodnika. Oto kroki, które użyłem szczegółowo:
3.1 Dodaj Rekordy MX
Będziesz potrzebować dostępu do swojego konta konkretnego dostawcy usług internetowych. Po zakończeniu, możesz je sprawdzić za pomocą dig – oto polecenie dla mojej domeny.
dig +short MX inbound.thetucks.com
Powinieneś zobaczyć:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com.
3.2 Utwórz Domena Przychodząca
Użyj kolekcji Postman API SparkPost, wybierając Inbound Domains / Create .. wywołanie. Treść żądania POST zawiera twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz Przekaźnikowy Webhook
Utwórz przychodzący webhook przekaźnikowy, używając odpowiedniego wywołania w Postman. Treść wiadomości w moim przypadku zawiera:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Jak wspomniano wcześniej, zalecam ustawienie auth_token na własną tajną wartość, jak określono w pliku webapp.ini na twoim hoście.
Wartość „target” musi odpowiadać adresowi hosta i portowi TCP, gdzie będziesz hostować aplikację.
Wartość „domain” musi odpowiadać rekordu MX skonfigurowanego w kroku 1.
To wszystko! Instalacja jest zakończona. Powinieneś teraz móc wysyłać certyfikaty na swój adres przychodzący, będą one przetwarzane i pojawią się na twoim hoście aplikacji webowej – w tym przypadku, w pliku o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane e-maile do Boba, używając narzędzi opisanych w częściach 2 i 3 tej serii.
Możesz zbadać zawartość certyfikatu używając:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Wewnętrzności: sprawdzanie DKIM, walidacja certyfikatu
Aplikacja sprawdza, czy otrzymane e-maile mają ważny DKIM i czy same certyfikaty są ważne, jak opisano tutaj. Znajdują się tam również notatki dotyczące wdrożenia oraz pomysły na dalsze działania.
Podsumowując…
Widzieliśmy, jak klucze publiczne odbiorców mogą być łatwo gromadzone za pomocą wiadomości e-mail na adres webhooks dla przychodzącej wiadomości. Po wykonaniu tego, ci odbiorcy mogą otrzymywać swoje wiadomości w szyfrowanej formie S/MIME.
To wszystko na teraz! Udanych wysyłek.
