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 odbyliśmy szybką wycieczkę po S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeprowadziła nas przez proste narzędzie wiersza poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wprowadzać bezpieczne strumienie poczty do platform lokalnych takich jak Port25 PowerMTA i Momentum.
W tej serii widzieliśmy, że dołączanie podpisu S/MIME jest dość proste. Wysyłanie szyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ trzeba uzyskać klucze publiczne odbiorców. To jedno, gdy używasz klienta pocztowego dla ludzi, takiego jak Thunderbird - ale jak to może działać z generowanymi przez aplikację strumieniami e-mail?
Ale czekaj – jest inny sposób na dotarcie do Mordoru, aby zdobyć te klucze. Twoja usługa może zaprosić klientów (oczywiście przez e-mail) do odesłania podpisanej wiadomości na znany adres obsługi klienta. Korzystając z magicznych mocy SparkPost Inbound Relay webhooks, wyodrębnimy i przechowamy ten klucz publiczny, abyś mógł go użyć.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, dostarczam Twojej usłudze mój osobisty podpis e-mailowy poprzez e-mail, aby w przyszłości wiadomości można było do mnie wysyłać w postaci zaszyfrowanej S/MIME.
Z tego wyprowadźmy bardziej szczegółowe wymagania:
Potrzebujemy zawsze dostępnej, niezawodnej usługi odbierania e-maili, aby odbierać te podpisane wiadomości.
Nie powinny być wymagane żadne specjalne formaty poczty, poza tym, że powinny zawierać podpis S/MIME.
Ponieważ każdy może spróbować wysłać maila do tej usługi, powinna być zaprojektowana defensywnie, na przykład, aby odrzucać „podszyte się” wiadomości od złych aktorów. Konieczne będzie kilka warstw sprawdzania.
Jeśli wszystko zostanie prawidłowo zweryfikowane, usługa zapisze certyfikat w pliku, używając dobrze znanego formatu tekstowego Privacy-Enhanced Mail (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhook maszynowo-maszynowe mogą być trudno widoczne tylko z odpowiedzi na to, co dzieje się wewnątrz. Usługa powinna dostarczać obszerne, zrozumiałe dla ludzi logi aplikacyjne. W szczególności, parsowanie i sprawdzanie certyfikatów powinno być logowane.
Dodajemy przypadki testowe dla wewnętrznych elementów aplikacji, używając przydatnego frameworku Pytest i automatycznie uruchamiamy te testy przy zameldowaniu przy użyciu integracji Travis CI z GitHub.
OK – zacznijmy!
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.
