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?
Business in a box.
Odkryj nasze rozwiązania.
Porozmawiaj z naszym zespołem sprzedaży
W części 1, odbyliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 wprowadziła nas do prostego narzędzia wiersza poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wprowadzać bezpieczne strumienie pocztowe do platform lokalnych, takich jak Port25 PowerMTA i Momentum.
W tej serii widzieliśmy, że dodawanie podpisu S/MIME jest dość proste. Wysyłanie zaszyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ musisz uzyskać publiczne klucze odbiorców. To jedno, gdy używasz klienta pocztowego dla ludzi, takiego jak Thunderbird – ale jak to zrobić ze strumieniami e-mail generowanymi przez aplikacje?
Ale zaczekaj – istnieje inny sposób na dotarcie do Mordoru, aby uzyskać te klucze. Twoja usługa może zaprosić Twoich klientów (oczywiście e-mailem), aby wysłali do Ciebie z powrotem podpisaną wiadomość na znany adres obsługi klienta. Korzystając z magicznych możliwości webhooks SparkPost Inbound Relay, wyodrębnimy i przechowamy ten klucz publiczny do Twojego użytku.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, dostarczam Twojej usłudze mój osobisty podpis e-mail, tak aby w przyszłości wiadomości mogły być do mnie wysyłane w zaszyfrowanej formie S/MIME.
Na tej podstawie określmy bardziej szczegółowe wymagania:
Potrzebujemy zawsze dostępnej, niezawodnej usługi odbierania e-maili, aby otrzymywać te podpisane wiadomości.
Nie powinny obowiązywać żadne specjalne wymagania dotyczące formatu wiadomości, poza tym, że powinny one zawierać podpis S/MIME.
Ponieważ każdy może próbować wysłać pocztę do tej usługi, powinna być ona zaprojektowana defensywnie, na przykład, aby odrzucać „podrobione” wiadomości od złych podmiotów. Konieczne będzie kilka warstw sprawdzania.
Jeśli wszystko jest w porządku, usługa zapisze certyfikat w pliku, używając znanego formatu tekstu jawnego wzbogaconej ochrony poczty (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhook typu maszyna-do-maszyny mogą być trudne do zobaczenia tylko z odpowiedzi na to, co się dzieje wewnątrz. Usługa powinna dostarczać obszerne aplikacyjne dzienniki czytelne dla ludzi. W szczególności analiza i sprawdzanie certyfikatów powinny być rejestrowane.
Dodajemy przypadki testowe dla wewnętrznych aplikacji, korzystając z miłego frameworka Pytest, i uruchamiamy te testy automatycznie przy włączaniu używając integracji Travis CI z GitHub.
OK – zacznijmy!
1. Przegląd rozwiązania
Tak będzie wyglądać 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 wiadomości przychodzących – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę zgodnie z tym przewodnikiem. Oto szczegółowe kroki, które zastosowałem:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego specyficznego konta 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 domenę przychodzącą
Użyj kolekcji API Postman SparkPost, wybierając Inbound Domains / Create .. call. Ciało żądania POST zawiera twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz Webhook dla Przekierowań
Utwórz webhook dla przekierowań przychodzących, używając odpowiedniego wywołania Postman. Ciało 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 wcześniej wspomniano, zalecam ustawienie własnej wartości auth_token, jak ustawiono w pliku webapp.ini na twoim hoście.
Twoja wartość „target” musi odpowiadać adresowi hosta i portowi TCP, na którym będziesz hostować aplikację sieciową.
Twoja wartość „domain” musi odpowiadać skonfigurowanym rekordom MX w kroku 1.
To wszystko! Instalacja jest ukończona. Powinieneś teraz móc wysyłać certyfikaty na swój adres przychodzący, będą one przetwarzane i wyświetlane na twoim hostingu aplikacji sieciowej – w tym przypadku, 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.
