S/MIME Część 4: Łatwe zbieranie kluczy publicznych odbiorców – z webhookami SparkPost Inbound Relay
Ptak
1 lut 2019
1 min read
Kluczowe Wnioski
Przesłanie: Wysyłanie e-maili szyfrowanych za pomocą S/MIME nie jest trudne, gdy można automatycznie zbierać klucz publiczny każdego odbiorcy. Ten wpis wypełnia tę lukę poprzez wykorzystanie SparkPost Inbound Relay Webhooks do odbierania podpisanych e-maili, ekstrakcji certyfikatów i ich przechowywania do późniejszego szyfrowania.
Cel: Zbuduj usługę webhook opartą na Flask, która nasłuchuje przychodzących podpisanych wiadomości, weryfikuje je (sprawdzanie DKIM + certyfikatu), i bezpiecznie zapisuje każdy klucz publiczny na dysku do wykorzystania w wychodzącej bezpiecznej poczcie.
Najważniejsze cechy:
Problem: Ręczna wymiana kluczy nie skaluje się dla e-maili generowanych przez aplikacje.
Rozwiązanie: Zaproś użytkowników do wysłania podpisanego e-maila; przychodzący webhook automatycznie parsuje i przechowuje ich certyfikat PEM.
Kroki konfiguracji:
Skonfiguruj Inbound Domain i rekordy MX (np. inbound.yourdomain.com).
Utwórz Inbound Relay Webhook za pomocą SparkPost API, wskazujący na punkt końcowy twojej aplikacji.
Wdrażaj małą Flask app (webapp.py) korzystając z konfiguracji z webapp.ini.
Loguj szczegółowo dla przejrzystości; zintegrować Pytest + Travis CI dla automatycznej weryfikacji.
Środki bezpieczeństwa:
Zweryfikuj podpisy DKIM i autentyczność wiadomości.
Sprawdź łańcuch zaufania certyfikatu przed przechowywaniem.
Użyj sekretnego tokena uwierzytelniającego w nagłówkach webhook.
Wynik:
Każda ważna przychodząca wiadomość tworzy plik certyfikatu, na przykład bob.lumreeker@gmail.com.crt.
Gdy są przechowywane, te klucze umożliwiają szyfrowane odpowiedzi za pomocą wcześniejszych skryptów z części 2 i 3.
Q&A Highlights
Dlaczego zbieranie kluczy odbiorcy jest tak istotne dla S/MIME?
Ponieważ szyfrowanie wymaga klucza publicznego każdego odbiorcy; automatyzacja tego kroku pozwala każdej aplikacji wysyłać bezpieczną pocztę bez ręcznej wymiany.
Jak SparkPost Inbound Relay Webhook upraszcza zbieranie kluczowych danych?
Konwertuje każdą podpisaną wiadomość e-mail przychodzącą na ustrukturyzowany ładunek JSON, umożliwiając Twojej aplikacji analizę i przechowywanie certyfikatów programistycznie.
Jakie zabezpieczenia zapobiegają fałszowaniu lub niechcianym zgłoszeniom?
Usługa weryfikuje podpisy DKIM, wymusza tokeny uwierzytelniające i odrzuca nieprawidłowo sformułowane lub niepodpisane wiadomości.
Gdzie są przechowywane certyfikaty i w jakim formacie?
Są zapisane na dysku w formacie PEM (
.crtpliki), gotowe do użycia przez narzędzia do podpisywania/szyfrowania zbudowane we wcześniejszych częściach.Jaki jest proces pracy developera?
Uruchom aplikację Flask, zweryfikuj za pomocą Postman przy użyciu dostarczonego przykładowego ładunku, a następnie połącz ją z aktywnym webhookiem SparkPost dla ciągłej pracy.
Ogólne wnioski?
Zarządzanie kluczami S/MIME może być w pełni zautomatyzowane za pomocą kilku linii kodu w Pythonie i SparkPost APIs—wprowadzając skalowalne szyfrowanie do każdego przepływu pracy z e-maili generowanymi przez aplikacje.
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!
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!
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.
Oto jak będzie wyglądało ogólne rozwiązanie.
Oto jak będzie wyglądało ogólne rozwiązanie.
2. Instalacja, konfiguracja i uruchamianie aplikacji webowej
Zaczniemy od tej części, aby była w pełni przetestowana, zanim podłączymy przekierowania webhooków przychodzących.
Aplikacja internetowa jest uwzględniona w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – odczytuje e-mail i rozbiera na części pośrednie i certyfikaty użytkowników.
Program webapp.py – prosta aplikacja internetowa kompatybilna z Flask do użycia z SparkPost Inbound Relay Webhooks.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji webowych.
Musisz upewnić się, że twój host ma odpowiedni numer portu TCP otwarty na przychodzące żądania z zewnątrz, aby SparkPost mógł wysyłać wiadomości do twojej aplikacji. Jeśli hostujesz na przykład na AWS EC2, będziesz musiał skonfigurować Security Group swojej instancji.
Instrukcje dotyczące konfigurowania i uruchamiania aplikacji internetowej są zamieszczone w naszym przewodniku instalacji – to całkiem proste. Aby sprawdzić, czy twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać puste żądania z innego hosta, na przykład za pomocą curl:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobrze – twoja aplikacja działa!
W webapp.log na twoim hoście zobaczysz wynik podobny do tego:
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Aby pomóc ci natychmiast pracować z prawdziwymi danymi w twojej aplikacji, możesz zaimportować to konkretne żądanie Postman z repozytorium projektu. Symuluje ono, co będzie robić twoje konto SparkPost, tzn. wysyła POST https zawierający e-mail ze specyficznym, ważnym certyfikatem (należącym do mojego testowego konta) do twojej aplikacji.
Musisz tylko zmienić adres docelowy w żądaniu (w szarym polu powyżej), aby pasował do twojej instalacji. Jeśli zmieniłeś wartość tokena w webapp.ini, dostosuj wartość nagłówka w Postman, aby pasowała.
Jeśli twoja aplikacja działa, zobaczysz odpowiedź „200 OK” z powrotem w Postman. Twój plik webapp.log na hoście zawierać będzie wynik podobny do tego:
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Na szybkie sprawdzenie, spójrz na ostatnią linię – jeśli mówi „written file”, to dobrze. Reszta pokazuje proces sprawdzania DKIM i walidację certyfikatu.
Zaczniemy od tej części, aby była w pełni przetestowana, zanim podłączymy przekierowania webhooków przychodzących.
Aplikacja internetowa jest uwzględniona w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – odczytuje e-mail i rozbiera na części pośrednie i certyfikaty użytkowników.
Program webapp.py – prosta aplikacja internetowa kompatybilna z Flask do użycia z SparkPost Inbound Relay Webhooks.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji webowych.
Musisz upewnić się, że twój host ma odpowiedni numer portu TCP otwarty na przychodzące żądania z zewnątrz, aby SparkPost mógł wysyłać wiadomości do twojej aplikacji. Jeśli hostujesz na przykład na AWS EC2, będziesz musiał skonfigurować Security Group swojej instancji.
Instrukcje dotyczące konfigurowania i uruchamiania aplikacji internetowej są zamieszczone w naszym przewodniku instalacji – to całkiem proste. Aby sprawdzić, czy twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać puste żądania z innego hosta, na przykład za pomocą curl:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobrze – twoja aplikacja działa!
W webapp.log na twoim hoście zobaczysz wynik podobny do tego:
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Aby pomóc ci natychmiast pracować z prawdziwymi danymi w twojej aplikacji, możesz zaimportować to konkretne żądanie Postman z repozytorium projektu. Symuluje ono, co będzie robić twoje konto SparkPost, tzn. wysyła POST https zawierający e-mail ze specyficznym, ważnym certyfikatem (należącym do mojego testowego konta) do twojej aplikacji.
Musisz tylko zmienić adres docelowy w żądaniu (w szarym polu powyżej), aby pasował do twojej instalacji. Jeśli zmieniłeś wartość tokena w webapp.ini, dostosuj wartość nagłówka w Postman, aby pasowała.
Jeśli twoja aplikacja działa, zobaczysz odpowiedź „200 OK” z powrotem w Postman. Twój plik webapp.log na hoście zawierać będzie wynik podobny do tego:
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Na szybkie sprawdzenie, spójrz na ostatnią linię – jeśli mówi „written file”, to dobrze. Reszta pokazuje proces sprawdzania DKIM i walidację certyfikatu.
Zaczniemy od tej części, aby była w pełni przetestowana, zanim podłączymy przekierowania webhooków przychodzących.
Aplikacja internetowa jest uwzględniona w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – odczytuje e-mail i rozbiera na części pośrednie i certyfikaty użytkowników.
Program webapp.py – prosta aplikacja internetowa kompatybilna z Flask do użycia z SparkPost Inbound Relay Webhooks.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji webowych.
Musisz upewnić się, że twój host ma odpowiedni numer portu TCP otwarty na przychodzące żądania z zewnątrz, aby SparkPost mógł wysyłać wiadomości do twojej aplikacji. Jeśli hostujesz na przykład na AWS EC2, będziesz musiał skonfigurować Security Group swojej instancji.
Instrukcje dotyczące konfigurowania i uruchamiania aplikacji internetowej są zamieszczone w naszym przewodniku instalacji – to całkiem proste. Aby sprawdzić, czy twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać puste żądania z innego hosta, na przykład za pomocą curl:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobrze – twoja aplikacja działa!
W webapp.log na twoim hoście zobaczysz wynik podobny do tego:
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Aby pomóc ci natychmiast pracować z prawdziwymi danymi w twojej aplikacji, możesz zaimportować to konkretne żądanie Postman z repozytorium projektu. Symuluje ono, co będzie robić twoje konto SparkPost, tzn. wysyła POST https zawierający e-mail ze specyficznym, ważnym certyfikatem (należącym do mojego testowego konta) do twojej aplikacji.
Musisz tylko zmienić adres docelowy w żądaniu (w szarym polu powyżej), aby pasował do twojej instalacji. Jeśli zmieniłeś wartość tokena w webapp.ini, dostosuj wartość nagłówka w Postman, aby pasowała.
Jeśli twoja aplikacja działa, zobaczysz odpowiedź „200 OK” z powrotem w Postman. Twój plik webapp.log na hoście zawierać będzie wynik podobny do tego:
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Na szybkie sprawdzenie, spójrz na ostatnią linię – jeśli mówi „written file”, to dobrze. Reszta pokazuje proces sprawdzania DKIM i walidację certyfikatu.
3. SparkPost inbound relay webhooks konfiguracja
Po pierwsze, wybieramy domenę do użycia jako nasz adres wiadomości przychodzącej – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę zgodnie z tym przewodnikiem. Oto kroki, które użyłem szczegółowo:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego konkretnego konta dostawcy usług internetowych. Po zakończeniu możesz sprawdzić je 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 SparkPost Postman API collection, wybierając domeny przychodzące / Create .. call. Treść żądania POST zawiera Twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz Relay Webhook
Utwórz webhook przekaźnika przychodzącego, używając odpowiedniego wywołania 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, polecam ustawienie auth_token na własną tajną wartość, jak ustawiono w pliku webapp.ini na Twoim hoście.
Twój „target” musi pasować do adresu hosta i portu TCP, gdzie będziesz prowadzić aplikację internetową.
Twój „domain” musi pasować do rekordów MX skonfigurowanych w kroku 1.
To wszystko! Instalacja jest zakończona. Teraz powinieneś być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetworzone i pojawią się na Twoim hoście aplikacji internetowej – w tym przypadku, plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane e-maile do Bob, używając narzędzi opisanych w częściach 2 i 3 tej serii.
Możesz przeanalizować zawartość certyfikatu używając:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Po pierwsze, wybieramy domenę do użycia jako nasz adres wiadomości przychodzącej – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę zgodnie z tym przewodnikiem. Oto kroki, które użyłem szczegółowo:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego konkretnego konta dostawcy usług internetowych. Po zakończeniu możesz sprawdzić je 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 SparkPost Postman API collection, wybierając domeny przychodzące / Create .. call. Treść żądania POST zawiera Twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz Relay Webhook
Utwórz webhook przekaźnika przychodzącego, używając odpowiedniego wywołania 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, polecam ustawienie auth_token na własną tajną wartość, jak ustawiono w pliku webapp.ini na Twoim hoście.
Twój „target” musi pasować do adresu hosta i portu TCP, gdzie będziesz prowadzić aplikację internetową.
Twój „domain” musi pasować do rekordów MX skonfigurowanych w kroku 1.
To wszystko! Instalacja jest zakończona. Teraz powinieneś być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetworzone i pojawią się na Twoim hoście aplikacji internetowej – w tym przypadku, plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane e-maile do Bob, używając narzędzi opisanych w częściach 2 i 3 tej serii.
Możesz przeanalizować zawartość certyfikatu używając:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Po pierwsze, wybieramy domenę do użycia jako nasz adres wiadomości przychodzącej – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę zgodnie z tym przewodnikiem. Oto kroki, które użyłem szczegółowo:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego konkretnego konta dostawcy usług internetowych. Po zakończeniu możesz sprawdzić je 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 SparkPost Postman API collection, wybierając domeny przychodzące / Create .. call. Treść żądania POST zawiera Twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz Relay Webhook
Utwórz webhook przekaźnika przychodzącego, używając odpowiedniego wywołania 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, polecam ustawienie auth_token na własną tajną wartość, jak ustawiono w pliku webapp.ini na Twoim hoście.
Twój „target” musi pasować do adresu hosta i portu TCP, gdzie będziesz prowadzić aplikację internetową.
Twój „domain” musi pasować do rekordów MX skonfigurowanych w kroku 1.
To wszystko! Instalacja jest zakończona. Teraz powinieneś być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetworzone i pojawią się na Twoim hoście aplikacji internetowej – w tym przypadku, plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane e-maile do Bob, używając narzędzi opisanych w częściach 2 i 3 tej serii.
Możesz przeanalizować 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.
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.
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.
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.
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.
