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, bei 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 zur Signierung und Verschlüsselung von E-Mails, die dann über SparkPost gesendet werden. Teil 3 zeigte, wie man sichere Mailströme in lokale Plattformen wie Port25 PowerMTA und Momentum einspeist.
In dieser Serie haben wir gesehen, dass das Einfügen einer S/MIME-Signatur relativ unkompliziert ist. Das Senden von S/MIME-verschlüsselten Mails ist komplizierter, weil man die öffentlichen Schlüssel der Empfänger erhalten muss. Das 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?
Aber warten Sie – es gibt einen anderen Weg nach Mordor, um diese Schlüssel zu bekommen. Ihr Dienst kann Ihre Kunden (natürlich per E-Mail) einladen, Ihnen eine signierte Mail an eine bekannte Kundenservice-Adresse zu senden. Mit den magischen Kräften 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 gebe ich Ihrem Dienst meine persönliche E-Mail-Signatur per E-Mail, damit mir in Zukunft E-Mails in S/MIME-verschlüsselter Form gesendet werden können.
Daraus lassen sich einige detailliertere Anforderungen ableiten:
Wir benötigen einen immer aktiven, zuverlässigen Eingangs-E-Mail-Dienst, um die signierten E-Mails zu empfangen.
Es sollte keine besonderen Anforderungen an das Mail-Format geben, außer dass es eine S/MIME-Signatur tragen sollte.
Da jeder versuchen kann, eine Mail an diesen Dienst zu senden, sollte er defensiv gestaltet sein, beispielsweise um „Spoof“-Nachrichten von schlechten Akteuren abzulehnen. Es werden mehrere Schichten von Prüfungen erforderlich sein.
Wenn alles in Ordnung ist, speichert der Dienst das Zertifikat in einer Datei im bekannten Klartextformat Privacy-Enhanced Mail (PEM).
Es gibt einige nicht-funktionale Anforderungen:
Maschine-zu-Maschine-Webhook-Dienste können schwer zu durchschauen sein, einfach nur aus den Antworten darauf, was intern vor sich geht. Der Dienst sollte umfangreiche, für Menschen lesbare Protokolle auf Anwendungsebene bereitstellen. Insbesondere die Zertifikatsanalyse und -überprüfung sollte protokolliert werden.
Wir fügen Testfälle für die App-Interna hinzu, verwenden das nette Pytest-Framework und führen diese Tests automatisch beim Einchecken mit Travis CI-Integration mit GitHub aus.
OK – lassen Sie uns anfangen!
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.
