In dieser Reihe haben wir gesehen, dass das Hinzufügen einer S/MIME-Signatur ziemlich unkompliziert ist. Das Senden von S/MIME-verschlüsselten E-Mails ist komplexer, da Sie die öffentlichen Schlüssel der Empfänger benötigen. Es ist eine Sache, wenn Sie einen E-Mail-Client für Menschen wie Thunderbird verwenden – aber wie kann das mit von Anwendungen generierten E-Mail-Streams funktionieren?
In Teil 1 hatten wir eine kurze Tour durch S/MIME und betrachteten die Signierung und Verschlüsselung unserer Nachrichtenströme über eine Reihe von Mail-Clients. Teil 2 führte uns durch ein einfaches Kommandozeilenwerkzeug, um E-Mails zu signieren und zu verschlüsseln, und sie dann über SparkPost zu senden. Teil 3 zeigte, wie man sichere Mail-Ströme in lokale Plattformen wie Port25 PowerMTA und Momentum einfügt.
In dieser Serie haben wir gesehen, dass das Hinzufügen einer S/MIME-Signatur ziemlich unkompliziert ist. Das Versenden von S/MIME-verschlüsselten Mails ist komplexer, da man öffentliche Schlüssel der Empfänger beschaffen muss. Es ist eine Sache, wenn man einen Mail-Client für Menschen wie Thunderbird benutzt – aber wie funktioniert das mit App-generierten E-Mail-Strömen? App-generierte E-Mails, wie sie von Dating-Plattformen verwendet werden, erfordern eine sorgfältige Strategie, um das Engagement zu maximieren. Sehen Sie, wie Dating-Apps überzeugende, ausgelöste E-Mail-Erlebnisse schaffen.
Aber warten Sie – es gibt einen anderen Weg nach Mordor, um diese Schlüssel zu bekommen. Ihr Service kann Ihre Kunden (natürlich per E-Mail) einladen, Ihnen eine signierte Mail an eine bekannte Kundenservice-Adresse zurückzusenden. Mithilfe der magischen Kräfte der SparkPost Inbound Relay Webhooks werden wir diesen öffentlichen Schlüssel extrahieren und speichern, damit Sie ihn verwenden können.
Wir können dies in einem einfachen Anwendungsfall zusammenfassen:
Als Empfänger von Nachrichten stelle ich Ihrem Service meine persönliche E-Mail-Signatur per E-Mail zur Verfügung, damit mir in Zukunft E-Mails in S/MIME-verschlüsselter Form gesendet werden können.
Daraus wollen wir einige detailliertere Anforderungen ableiten:
Wir benötigen einen stets aktiven, zuverlässigen Eingangs-Mail-Service, um diese signierten E-Mails zu empfangen.
Es sollten keine speziellen Anforderungen an das Mail-Format gestellt werden, außer dass es eine S/MIME-Signatur enthalten sollte.
Da jeder versuchen kann, eine Mail an diesen Service zu senden, sollte er defensiv gestaltet sein, um beispielsweise „Spoof“-Nachrichten von böswilligen Akteuren abzuweisen. Es wird mehrere Überprüfungsebenen geben.
Wenn alles in Ordnung ist, speichert der Service das Zertifikat in einer Datei im bekannten Klartextformat Privacy-Enhanced Mail (PEM).
Es gibt einige nicht-funktionale Anforderungen:
Maschine-zu-Maschine-Webhooks-Dienste können nur schwer durch Rückmeldungen das Innere erkennen lassen. Der Dienst sollte umfangreiche, menschenlesbare Anwendungsprotokolle bereitstellen. Insbesondere das Parsen und Prüfen der Zertifikate sollte protokolliert werden.
Wir fügen Testfälle für die Anwendungsinternen hinzu, indem wir das nette Pytest Framework verwenden und diese Tests automatisch bei Check-in mit der Travis CI-Integration mit GitHub ausführen.
OK – fangen wir an!
1. Lösung Überblick
Hier ist, wie die Gesamtlösung aussehen wird.
2. Installieren, Konfigurieren und Starten der Web-App
3. SparkPost Inbound-Relay-Webhooks-Einrichtung
Zuerst wählen wir eine Domain aus, die wir als Adresse für eingehende Nachrichten verwenden – hier wird es inbound.thetucks.com sein. Richten Sie Ihre Domain entsprechend dieser Anleitung ein. Hier sind die Schritte, die ich im Detail verwendet habe:
3.1 MX-Einträge hinzufügen
Sie benötigen Zugriff auf Ihr spezielles Internet Service Provider-Konto. Wenn dies erledigt ist, können Sie diese mit "dig" überprüfen – hier ist der Befehl für meine Domain.
dig +short MX inbound.thetucks.com
Sie sollten Folgendes sehen:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com.
3.2 Eine eingehende Domain erstellen
Verwenden Sie die SparkPost Postman API-Sammlung und wählen Sie den Inbound Domains / Create .. Aufruf aus. Der Body des POST-Requests enthält Ihre Domain, zum Beispiel:
{ "domain": "inbound.thetucks.com" }
3.3 Erstellen eines Relay Webhooks
Erstellen Sie einen eingehenden Relay-Webhook mit dem entsprechenden Postman-Aufruf. Der Nachrichtenkörper enthält in meinem Fall:
{ "name": "Certificate Collection 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 Ihnen, ein auth_token auf Ihren eigenen geheimen Wert einzustellen, wie im webapp.ini-Dokument auf Ihrem Host festgelegt.
Ihr "target"-Wert muss mit Ihrer Host-Adresse und dem TCP-Port übereinstimmen, auf dem Sie die Web-Anwendung hosten werden.
Ihr "domain"-Wert muss mit Ihren in Schritt 1 eingerichteten MX-Einträgen übereinstimmen.
Das war’s! Die Grundlagen sind erledigt. Sie sollten nun in der Lage sein, Zertifikate an Ihre eingehende Adresse zu senden, sie werden verarbeitet und erscheinen auf Ihrem Webanwendungshost – in diesem Fall eine Datei namens bob.lumreeker@gmail.com.crt.
Sie können jetzt verschlüsselte E-Mails an Bob senden, indem Sie die in den Teilen 2 & 3 dieser Serie beschriebenen Werkzeuge verwenden.
Sie können den Inhalt eines Zertifikats mit folgendem Befehl untersuchen:
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 ein gültiges DKIM haben, und prüft, ob die Zertifikate selbst gültig sind, wie hier beschrieben. Dort gibt es auch Implementierungshinweise und Ideen für weitere Arbeiten.
Zusammenfassend…
Wir haben gesehen, wie öffentliche Schlüssel von Empfängern leicht mit einer E-Mail an eine eingehende Relay-Webhook-Adresse gesammelt werden können. Sobald dies getan ist, können diese Empfänger ihre Nachrichten in S/MIME-verschlüsselter Form erhalten.
Das war’s für jetzt! Viel Spaß beim Senden.
