Dans cette série, nous avons vu que l'inclusion d'une signature S/MIME est assez simple. L'envoi de courriels cryptés S/MIME est plus complexe car vous devez obtenir les clés publiques des destinataires. C'est une chose lorsque vous utilisez un client de messagerie pour les humains tel que Thunderbird – mais comment cela peut-il fonctionner avec des flux de courriels générés par des applications ?
Dans la partie 1, nous avons eu un aperçu rapide de S/MIME, en examinant la signature et le chiffrement de nos flux de messages à travers une gamme de clients de messagerie. La partie 2 nous a guidés à travers un outil en ligne de commande simple pour signer et crypter les e-mails, puis les envoyer via SparkPost. La partie 3 a montré comment injecter des flux de courrier sécurisés dans des plateformes sur site telles que Port25 PowerMTA et Momentum.
Dans cette série, nous avons vu comment inclure une signature S/MIME est assez simple. Envoyer du courrier chiffré S/MIME est plus complexe car vous devez obtenir les clés publiques des destinataires. C’est une chose lorsque vous utilisez un client de messagerie pour les humains tel que Thunderbird - mais comment cela fonctionne-t-il avec les flux d'e-mails générés par des applications ? Les e-mails générés par des applications, comme ceux utilisés par les plateformes de rencontres, nécessitent une stratégie soignée pour maximiser l'engagement. Voyez comment les applications de rencontre créent des expériences d'e-mail déclenchées captivantes.
Mais attendez - il y a un autre chemin vers la Comté pour obtenir ces clés. Votre service peut inviter vos clients (par e-mail, bien sûr) à vous renvoyer un courrier signé à une adresse de service client connue. En utilisant les pouvoirs magiques des webhooks de SparkPost Inbound Relay, nous allons extraire et stocker cette clé publique pour que vous puissiez l'utiliser.
Nous pouvons résumer cela dans un cas d'utilisation simple :
En tant que destinataire de messages, je fournis à votre service ma signature électronique personnelle par e-mail, afin que, à l'avenir, les e-mails puissent m'être envoyés sous forme chiffrée S/MIME.
A partir de cela, tirons quelques exigences plus détaillées :
Nous avons besoin d'un service de réception d'e-mails toujours actif et fiable pour recevoir ces e-mails signés.
Il ne devrait y avoir aucune exigence particulière sur le format de l'e-mail, si ce n'est qu'il doit contenir une signature S/MIME.
Parce que n'importe qui peut essayer d'envoyer un courrier à ce service, il doit être conçu de manière défensive, par exemple, pour rejeter les messages de «spoof» provenant de mauvais acteurs. Il devra y avoir plusieurs couches de vérification.
Si tout est en ordre, le service stockera le certificat dans un fichier, en utilisant le format texte brut bien connu Privacy-Enhanced Mail (PEM).
Il y a quelques exigences non fonctionnelles :
Les services de webhook machine à machine peuvent être difficiles à visualiser juste à partir des réponses à ce qui se passe à l'intérieur. Le service doit fournir des journaux applicatifs au niveau humain étendus. En particulier, l'analyse et la vérification des certificats doivent être enregistrées.
Nous ajoutons des cas de test pour les processus internes de l'application, en utilisant le charmant cadre Pytest, et exécutons ces tests automatiquement lors de l'enregistrement utilisant l'intégration Travis CI avec GitHub.
D'accord – commençons !
1. Aperçu de la solution
Voici à quoi ressemblera la solution globale.
2. Installer, configurer et démarrer l'application web
3. Configuration des webhooks de relais entrant SparkPost
Premièrement, nous sélectionnons un domaine à utiliser comme notre adresse de message entrant – ici, ce sera inbound.thetucks.com. Configurez votre domaine en suivant ce guide. Voici les étapes que j'ai utilisées en détail :
3.1 Ajouter des enregistrements MX
Vous aurez besoin d'accéder à votre compte de fournisseur de services Internet spécifique. Une fois terminé, vous pouvez les vérifier avec dig – voici la commande pour mon domaine.
Vous devriez voir :
3.2 Créer un domaine entrant
Utilisez la collection Postman API de SparkPost, en sélectionnant le domaine entrant / Créer .. appel. Le corps de la requête POST contient votre domaine, par exemple :
3.3 Créer un Relay Webhook
Créez un webhook de relais entrant en utilisant l'appel pertinent de Postman. Le corps du message dans mon cas contient :
Comme mentionné précédemment, je recommande de définir un auth_token avec votre propre valeur secrète, comme défini dans le fichier webapp.ini sur votre hôte.
Votre valeur "target" doit correspondre à l'adresse de votre hôte et au port TCP où vous hébergerez l'application web.
Votre valeur "domain" doit correspondre à vos enregistrements MX configurés à l'étape 1.
Et voilà ! La plomberie est faite. Vous devriez maintenant pouvoir envoyer des certificats à votre adresse entrante, ils seront traités et apparaîtront sur l'hôte de votre application web – dans ce cas, un fichier nommé bob.lumreeker@gmail.com.crt.
Maintenant, vous pouvez envoyer des courriels chiffrés à Bob, en utilisant les outils décrits dans les parties 2 & 3 de cette série.
Vous pouvez examiner le contenu d'un certificat en utilisant :
4. Internals : vérification DKIM, validation des certificats
L'application vérifie que les e-mails reçus ont un DKIM valide et vérifie que les certificats eux-mêmes sont valides, comme décrit ici. Il y a aussi des notes d'implémentation là-dedans, et des idées pour des travaux futurs.
En résumé…
Nous avons vu comment les clés publiques des destinataires peuvent être facilement collectées en utilisant un email vers une adresse de webhooks de relais entrant. Une fois cela fait, ces destinataires peuvent recevoir leurs messages sous forme chiffrée S/MIME.
C'est tout pour le moment ! Bon envoi.
