In deze serie hebben we gezien hoe het toevoegen van een S/MIME-handtekening vrij eenvoudig is. Het verzenden van S/MIME-versleutelde e-mails is complexer omdat je openbare sleutels van de ontvanger moet verkrijgen. Het is één ding wanneer je een mailclient gebruikt voor mensen zoals Thunderbird – maar hoe werkt dat met app-gegeneerde e-mailstromen?
In deel 1 hadden we een snelle rondleiding van S/MIME, waarbij we keken naar het ondertekenen en versleutelen van onze berichtenstromen over een reeks mailclients. Deel 2 nam ons mee door een eenvoudige command-line tool om e-mails te ondertekenen en te versleutelen, en ze vervolgens via SparkPost te verzenden. Deel 3 liet zien hoe je veilige mailstromen kunt injecteren in on-premises platforms zoals Port25 PowerMTA en Momentum.
In deze serie hebben we gezien hoe het toevoegen van een S/MIME-handtekening vrij eenvoudig is. S/MIME-versleutelde mail versturen is complexer omdat je ontvangers openbare sleutels moet verkrijgen. Het is één ding als je een mailclient voor mensen zoals Thunderbird gebruikt – maar hoe kan dat werken met appgegenereerde e-mailstromen?
Maar wacht – er is een andere weg naar Mordor om die sleutels te krijgen. Je service kan je klanten uitnodigen (natuurlijk via e-mail) om je een ondertekende mail te sturen naar een bekend klantenserviceadres. Met de magische krachten van SparkPost Inbound Relay webhooks, zullen we die openbare sleutel voor jou extraheren en opslaan.
We kunnen dit samenvatten in een eenvoudig use-case:
Als ontvanger van berichten geef ik je service mijn persoonlijke e-mailhandtekening via e-mail, zodat in de toekomst e-mails in S/MIME-versleutelde vorm naar mij kunnen worden gestuurd.
Hiervan kunnen we enkele meer gedetailleerde vereisten afleiden:
We hebben een altijd-actieve, betrouwbare inkomende e-mailservice nodig om die ondertekende e-mails te ontvangen.
Er mogen geen speciale vereisten zijn aan het mailformaat, behalve dat het een S/MIME-handtekening moet bevatten.
Aangezien iedereen probeert een mail naar deze service te sturen, moet deze defensief ontworpen zijn, bijvoorbeeld om "spoof"-berichten van kwaadwillende actoren af te wijzen. Er zullen meerdere lagen van controle nodig zijn.
Als alles goed wordt gecontroleerd, zal de service het certificaat opslaan in een bestand, gebruikmakend van de bekende plain-text Privacy-Enhanced Mail (PEM) formaat.
Er zijn enkele niet-functionele eisen:
Machine-tot-machine webhook services kunnen moeilijk te zien zijn alleen op basis van reacties op wat er intern gebeurt. De service moet uitgebreide mensleesbare applicatieniveau-logboeken verstrekken. In het bijzonder moeten het parsen en controleren van het certificaat worden gelogd.
We voegen testgevallen toe voor de internals van de app, gebruikmakend van het fraaie Pytest framework, en draaien deze tests automatisch bij inchecken via Travis CI integratie met GitHub.
OK – laten we beginnen!
1. Oplossingsoverzicht
Dit is hoe de algehele oplossing eruit zal zien.
2. Installeren, configureren en starten van de web app
3. SparkPost inbound relay webhooks instellen
Ten eerste kiezen we een domein dat we willen gebruiken als ons inkomend berichtadres – hier zal dat inbound.thetucks.com zijn. Stel je domein in volgens deze gids. Hier zijn de stappen die ik in detail heb gebruikt:
3.1 Voeg MX Records toe
Je hebt toegang nodig tot je specifieke account van de Internet Service Provider. Wanneer klaar, kun je ze controleren met dig – hier is het commando voor mijn domein.
dig +short MX inbound.thetucks.com
Je zou moeten zien:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com.
3.2 Creëer een Inkomend Domein
Gebruik de SparkPost Postman API collectie en selecteer de Inkomende Domeinen / Create .. call. De body van de POST-aanvraag bevat je domein, bijvoorbeeld:
{ "domain": "inbound.thetucks.com" }
3.3 Creëer een Relay Webhook
Creëer een inkomende relay webhook met behulp van de relevante Postman call. De berichtbody in mijn geval bevat:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Zoals eerder vermeld, raad ik aan een auth_token in te stellen met je eigen geheime waarde, zoals ingesteld in het webapp.ini-bestand op je host.
Je “target” waarde moet overeenkomen met je hostadres en TCP-poort waar je de webapp host.
Je “domein” waarde moet overeenkomen met je MX records ingesteld in stap 1.
Dat is het! De basisinfrastructuur is gereed. Je zou nu in staat moeten zijn om certificaten naar je inkomend adres te sturen, ze zullen worden verwerkt en verschijnen op je webapplicatiehost – in dit geval een bestand genaamd bob.lumreeker@gmail.com.crt.
Nu kun je versleutelde e-mails naar Bob sturen, met behulp van de tools die beschreven zijn in deel 2 & 3 van deze serie.
Je kunt de inhoud van een certificaat bekijken met behulp van:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Internals: DKIM-controle, certificaatvalidatie
De app controleert of ontvangen e-mails geldige DKIM hebben en controleert of de certificaten zelf geldig zijn, zoals hier beschreven. Er zijn daar ook implementatieopmerkingen en ideeën voor verder werk.
Samenvattend…
We hebben gezien hoe openbare sleutels van ontvangers eenvoudig kunnen worden verzameld met een e-mail naar een inkomend relay-webhookadres. Zodra dit is gedaan, kunnen die ontvangers hun berichten in S/MIME versleutelde vorm ontvangen.
Dat is het voor nu! Vrolijk verzenden.
