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?
Business in a box.
Entdecken Sie unsere Lösungen.
Sprechen Sie mit unserem Vertriebsteam
In Teil 1 hatten wir eine kurze Tour durch S/MIME, wobei wir uns das Signieren und Verschlüsseln unserer Nachrichtenströme in verschiedenen Mail-Clients angesehen haben. Teil 2 führte uns durch ein einfaches Befehlszeilenwerkzeug, um E-Mails zu signieren und zu verschlüsseln und sie dann über SparkPost zu senden. Teil 3 zeigte, wie man sichere Mail-Streams in On-Premise-Plattformen wie Port25 PowerMTA und Momentum einspeist.
In dieser Serie haben wir gesehen, wie das Einfügen einer S/MIME-Signatur relativ einfach ist. Das Senden von S/MIME-verschlüsselter Post ist komplexer, da Sie die öffentlichen Schlüssel der Empfänger erhalten müssen. Das ist eine Sache, wenn Sie einen E-Mail-Client für Menschen wie Thunderbird verwenden – aber wie kann das mit app-generierten E-Mail-Strömen funktionieren?
Aber warten Sie – es gibt einen anderen Weg nach Mordor, um diese Schlüssel zu erhalten. Ihr Service kann Ihre Kunden (natürlich per E-Mail) einladen, Ihnen eine signierte E-Mail an eine bekannte Kundenservice-Adresse zu senden. Mithilfe der magischen Kräfte von SparkPost Inbound Relay Webhooks extrahieren und speichern wir diesen öffentlichen Schlüssel für Ihre Verwendung.
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 zukünftig E-Mails in S/MIME-verschlüsselter Form gesendet werden können.
Daraus lassen sich detailliertere Anforderungen ableiten:
Wir benötigen einen stets verfügbaren, zuverlässigen eingehenden E-Mail-Service, um diese signierten E-Mails zu empfangen.
Es sollten keine besonderen Anforderungen an das E-Mail-Format gestellt werden, außer dass es eine S/MIME-Signatur tragen sollte.
Da jeder versuchen kann, eine E-Mail an diesen Service zu senden, sollte er defensiv gestaltet sein, um beispielsweise „Spoof“-Nachrichten von böswilligen Akteuren abzulehnen. Es müssen mehrere Überprüfungsebenen vorhanden sein.
Wenn alles in Ordnung ist, speichert der Service das Zertifikat in einer Datei im bekannten reinen Textformat Privacy-Enhanced Mail (PEM).
Es gibt einige nicht-funktionale Anforderungen:
Maschine-zu-Maschine-Webhook-Dienste können schwer einsehbar sein, nur anhand von Antworten auf das, was intern passiert. Der Service sollte umfassende menschenlesbare Anwendungsprotokolle bereitstellen. Insbesondere sollte das Parsen und Überprüfen des Zertifikats protokolliert werden.
Wir fügen Testfälle für die App-Interna hinzu, indem wir das nette Pytest-Framework verwenden, und führen diese Tests bei jedem Check-in automatisch mit Travis CI-Integration mit GitHub aus.
OK – los geht’s!
1. Lösung Überblick
So sieht die Gesamtlösung aus.
2. Installieren, Konfigurieren und Starten der Web-App
3. SparkPost Inbound-Relay-Webhooks-Einrichtung
Zunächst wählen wir eine Domain aus, die wir als unsere eingehende Nachrichtenadresse verwenden möchten – hier wird es inbound.thetucks.com sein. Richten Sie Ihre Domain nach dieser Anleitung ein. Hier sind die Schritte, die ich im Detail verwendet habe:
3.1 Hinzufügen von MX-Einträgen
Sie benötigen Zugriff auf Ihr spezifisches Internetdienstanbieter-Konto. Wenn dies erledigt ist, können Sie sie 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 Erstellen einer eingehenden Domain
Verwenden Sie die SparkPost Postman API-Sammlung, indem Sie den Inbound Domains / Create .. Aufruf auswählen. Der Body der POST-Anfrage 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 Nachrichteninhalt 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, ein auth_token auf einen eigenen geheimen Wert einzustellen, wie er in der Datei webapp.ini auf Ihrem Host festgelegt ist.
Ihr „target“-Wert muss Ihrer Host-Adresse und dem TCP-Port entsprechen, auf dem Sie die Webanwendung hosten werden.
Ihr „domain“-Wert muss mit Ihren MX-Einträgen aus Schritt 1 übereinstimmen.
Das war's! Die Einrichtung ist abgeschlossen. Sie sollten nun in der Lage sein, Zertifikate an Ihre eingehende Adresse zu senden, diese werden verarbeitet und erscheinen auf Ihrem Webanwendungshost – in diesem Fall eine Datei namens bob.lumreeker@gmail.com.crt.
Jetzt können Sie verschlüsselte E-Mails an Bob senden, indem Sie die in Teil 2 & 3 dieser Serie beschriebenen Tools 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.
