In Teil 1 hatten wir eine schnelle Tour durch S/MIME, in der wir die Signierung und Verschlüsselung unserer Nachrichtenströme über eine Reihe von Mail-Clients betrachteten. Teil 2 führte uns durch ein einfaches Befehlszeilenwerkzeug zum Signieren und Verschlüsseln von E-Mails, das diese dann über SparkPost versenden kann. Teil 3 zeigte, wie man sichere Mailströme in vor Ort verfügbaren Plattformen wie Port25 PowerMTA und Momentum einspeisen kann.
In dieser Reihe haben wir gesehen, dass das Einfügen einer S/MIME-Signatur ziemlich unkompliziert ist. Das Versenden von S/MIME-verschlüsselten E-Mails ist komplexer, weil du die öffentlichen Schlüssel der Empfänger beschaffen musst. Es ist das eine, wenn du einen Mail-Client für Menschen wie Thunderbird verwendest – aber wie funktioniert das mit von Apps generierten E-Mail-Strömen?
Aber Moment – es gibt einen weiteren Weg nach Mordor, um diese Schlüssel zu erhalten. Dein Dienst kann deine Kunden (über E-Mail, natürlich) einladen, dir eine signierte E-Mail an eine bekannte Kundenservice-Adresse zu senden. Mit den magischen Kräften von SparkPost Inbound Relay Webhooks werden wir diesen öffentlichen Schlüssel extrahieren und für dich speichern.
Wir können dies in einem einfachen Anwendungsfall zusammenfassen:
Als Empfänger von Nachrichten stelle ich deinem Dienst meine persönliche E-Mail-Signatur per E-Mail zur Verfügung, damit in Zukunft E-Mails an mich in S/MIME-verschlüsselter Form gesendet werden können.
Darauf basierend lassen sich detailliertere Anforderungen ableiten:
Wir benötigen einen immer aktiven, zuverlässigen Service für eingehende E-Mails, um diese signierten E-Mails zu empfangen.
Es sollten keine speziellen Anforderungen an das E-Mail-Format bestehen, außer dass es eine S/MIME-Signatur tragen sollte.
Da jeder versuchen kann, eine E-Mail an diesen Dienst zu senden, sollte er defensiv gestaltet sein, um beispielsweise „Spoof“-Nachrichten von schlechten Akteuren abzulehnen. Es wird mehrere Ebenen der Überprüfung benötigen.
Wenn alles in Ordnung ist, wird der Dienst das Zertifikat in einer Datei speichern, im bekannten Klartextformat Privacy-Enhanced Mail (PEM).
Es gibt einige nicht-funktionale Anforderungen:
Machine-to-Machine-Webhook-Dienste können anhand von Antworten auf das Geschehen im Inneren schwer zu erkennen sein. Der Dienst sollte umfassende menschenlesbare Protokolle auf Anwendungsebene bereitstellen. Insbesondere das Parsen und Überprüfen des Zertifikats sollte protokolliert werden.
Wir fügen Testfälle für die internen Anwendungen hinzu, unter Verwendung des schönen Pytest-Frameworks, und führen diese Tests automatisch bei jedem Check-in mit Travis CI-Integration in GitHub durch.
OK – lass uns anfangen!
1. Lösungsübersicht
So wird die Gesamtlösung aussehen.
2. Installation, Konfiguration und Start der Web-App
Wir beginnen mit diesem Teil, damit wir ihn vollständig getestet haben, bevor wir die eingehenden Relay-Webhook-Anfragen integrieren.
Die Web-App ist im selben GitHub-Projekt wie die Teile 1 – 3 enthalten, also wenn du diese Teile verfolgt hast, hast du sie bereits. Hier sind die neuen Teile:
Programm readSMIMEsig.py – eine E-Mail lesen und Zwischen- sowie Benutzer-Zertifikate parsen.
Programm webapp.py – einfache Flask-kompatible Webanwendung für die Verwendung mit SparkPost Inbound Relay Webhooks.
webapp.ini – Konfigurationsdatei für die oben Genannten. Eine Konfigurationsdatei ermöglicht es, dieselben Werte einfach sowohl an Befehlszeilen- als auch an Webanwendungen zu übergeben.
Du musst sicherstellen, dass dein Host die korrekte TCP-Portnummer für eingehende Anfragen aus der Außenwelt geöffnet hat, damit SparkPost Nachrichten an deine App POSTen kann. Wenn du beispielsweise auf AWS EC2 gehostet wirst, musst du die Sicherheitsgruppe deines Instances konfigurieren.
Anweisungen zur Konfiguration und zum Starten der Web-App findest du hier – es ist ganz einfach. Um zu überprüfen, ob deine App läuft und von der Außenwelt erreichbar ist, kannst du beispielsweise leere Anfragen von einem anderen Host mit curl senden:
curl -X POST https://app.trymsys.net:8855/
Du solltest eine Antwort wie folgt sehen:
{"message":"Unbekannter Inhaltstyp in den Anfrage-Headers"}
Das ist eine gute Sache – deine App läuft!
In der webapp.log auf deinem Host wirst du Ausgaben sehen, die dieser ähnlich sind:
2019-01-15 00:11:07,575,root,INFO,Anfrage von 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,| Unbekannter Inhaltstyp: None
Um dir zu helfen, sofort mit echten Daten in deiner App zu experimentieren, kannst du diese spezifische Postman-Anfrage aus dem Projekt-Repo importieren. Dies simuliert, was dein SparkPost-Konto tun wird, d.h. es sendet ein https POST, das eine E-Mail mit einem spezifischen, gültigen Zertifikat (das zu einem meiner Testkonten gehört) an deine App sendet.
Du musst nur die Zieladresse in der Anfrage (im grauen Feld oben) ändern, um mit deiner Installation übereinzustimmen. Wenn du den Token-Wert in webapp.ini geändert hast, passe den Header-Wert in Postman entsprechend an.
Wenn deine App funktioniert, wirst du in Postman eine „200 OK“-Antwort zurücksehen. Deine webapp.log-Datei auf dem Host enthält Ausgaben wie die folgenden:
2019-01-15 00:11:48,554,root,INFO,Anfrage von 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 bestanden 2019-01-15 00:11:48,600,root,INFO,| inhaltstyp=multipart/signed; protokoll="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",inhaltbeschreibung=None 2019-01-15 00:11:48,600,root,INFO,| inhaltstyp=text/plain; charset=utf-8; format=flowed,inhaltbeschreibung=None 2019-01-15 00:11:48,600,root,INFO,| inhaltstyp=application/pkcs7-signature; name="smime.p7s",inhaltbeschreibung=S/MIME-Kryptografische Signatur 2019-01-15 00:11:48,600,root,INFO,| dateiname=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Zertifikat: 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,| Zertifikat: 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,| geschriebene datei ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Zur schnellen Überprüfung: Suche nach der letzten Zeile – wenn dort steht „geschriebene datei“, dann bist du gut. Der Rest zeigt den DKIM-Überprüfungs- und Zertifikatsvalidierungsprozess.
3. Einrichtung der SparkPost-Inbound-Relay-Webhooks
Zuerst wählen wir eine Domain aus, die wir als unsere eingehende Nachrichtenadresse verwenden – hier wird es inbound.thetucks.com sein. Richte deine Domain gemäß dieser Anleitung ein. Hier sind die Schritte, die ich im Detail verwendet habe:
3.1 MX-Einträge hinzufügen
Du benötigst Zugriff auf dein spezifisches Internet-Service-Provider-Konto. Wenn das erledigt ist, kannst du sie mit dig überprüfen – hier ist der Befehl für meine Domain.
dig +short MX inbound.thetucks.com
Du solltest sehen:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com.
3.2 Eine eingehende Domain erstellen
Verwende die SparkPost Postman API-Sammlung, wähle den Aufruf Eingehende Domains / Erstellen ... . Der Body der POST-Anfrage enthält deine Domain, beispielsweise:
{ "domain": "inbound.thetucks.com" }
3.3 Einen Relay-Webhook erstellen
Erstelle einen eingehenden Relay-Webhook mithilfe des entsprechenden Postman-Aufrufs. Der Nachrichtenbody enthält in meinem Fall:
{ "name": "Zertifikatssammel-Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Wie bereits erwähnt, empfehle ich, einen auth_token auf deinen eigenen geheimen Wert festzulegen, wie er in der Datei webapp.ini auf deinem Host festgelegt ist.
Dein „target“-Wert muss deiner Hostadresse und TCP-Port entsprechen, an dem du die Web-App hosten wirst.
Dein „domain“-Wert muss deinen in Schritt 1 festgelegten MX-Einträgen entsprechen.
Das war’s! Die technische Einrichtung ist abgeschlossen. Du solltest jetzt in der Lage sein, Zertifikate an deine eingehende Adresse zu senden, die verarbeitet werden und auf deinem Webanwendungs-Host angezeigt werden – in diesem Fall in einer Datei namens bob.lumreeker@gmail.com.crt.
Jetzt kannst du verschlüsselte E-Mails an Bob senden, mit den in den Teilen 2 & 3 dieser Reihe beschriebenen Werkzeugen.
Du kannst den Inhalt eines Zertifikats mit folgendem Befehl überprüfen:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Interna: DKIM-Überprüfung, Zertifikatsvalidierung
Die App überprüft, ob empfangene E-Mails gültige DKIM besitzen und überprüft, dass die Zertifikate selbst gültig sind, wie hier beschrieben. Es gibt auch Implementierungsnotizen und Ideen für weitere Arbeiten.
Zusammenfassend…
Wir haben gesehen, wie Empfänger-öffentliche Schlüssel leicht gesammelt werden können, indem man eine E-Mail an eine Adresse von eingehenden Relay-Webhooks sendet. Sobald dies erledigt ist, können diese Empfänger ihre Nachrichten in S/MIME-verschlüsselter Form empfangen.
Das war's fürs Erste! Viel Spaß beim Senden.