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 partie 1, nous avons fait un tour rapide de S/MIME, en regardant la signature et le chiffrement de nos flux de messages à travers une gamme de clients de messagerie. Partie 2 nous a guidés à travers un outil de ligne de commande simple pour signer et chiffrer des emails, puis les envoyer via SparkPost. La partie 3 a montré comment injecter des flux de mail sécurisés dans des plateformes locales telles que Port25 PowerMTA et Momentum.
Dans cette série, nous avons vu que l’inclusion d’une signature S/MIME est assez simple. Envoyer des mails chiffré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 mail pour les humains comme Thunderbird - mais comment cela peut-il fonctionner avec des flux de mail générés par des applications ?
Mais attendez – il y a une autre façon d'entrer dans Mordor pour obtenir ces clés. Votre service peut inviter vos clients (par email, bien sûr) à vous renvoyer un email signé à une adresse de service client connue. En utilisant les pouvoirs magiques des webhooks SparkPost Inbound Relay, nous extrairons et stockerons cette clé publique pour que vous puissiez l'utiliser.
Nous pouvons résumer cela dans un simple cas d'utilisation :
En tant que destinataire de messages, je fournis à votre service ma signature d'email personnelle par email, afin qu'à l'avenir, les emails puissent m'être envoyés sous forme chiffrée S/MIME.
À partir de cela, établissons quelques exigences plus détaillées :
Nous avons besoin d'un service d'email entrant toujours disponible et fiable pour recevoir ces emails signés.
Il ne doit y avoir aucune exigence particulière sur le format du mail, à part qu'il doit porter une signature S/MIME.
Parce que n'importe qui peut essayer d'envoyer un email à ce service, il doit être conçu de manière défensive, par exemple, pour rejeter les « messages d'usurpation » des mauvais acteurs. Il devra y avoir plusieurs couches de vérification.
Si tout est OK, le service stockera le certificat dans un fichier, en utilisant le format connu sous forme de texte simple Privacy-Enhanced Mail (PEM).
Il y a quelques exigences non fonctionnelles :
Les services d'API de webhook de machine à machine peuvent être difficiles à voir juste à partir des réponses à ce qui se passe à l'intérieur. Le service doit fournir des journaux d'application lisibles par l'homme. En particulier, l'analyse et la vérification des certificats doivent être enregistrées.
Nous ajoutons des cas de test pour les internes de l'application, en utilisant le joli cadre Pytest, et exécutons ces tests automatiquement lors de l'enregistrement à l'aide de 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
Tout d'abord, nous sélectionnons un domaine à utiliser comme 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 fournisseur de services Internet spécifique. Une fois cela fait, vous pouvez les vérifier avec dig – voici la commande pour mon domaine.
dig +short MX inbound.thetucks.com
Vous devriez voir :
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com.
3.2 Créer un domaine entrant
Utilisez le Postman API collection de SparkPost, en sélectionnant l'appel Inbound Domains / Create. Le corps de la requête POST contient votre domaine, par exemple :
{ "domain": "inbound.thetucks.com" }
3.3 Créer un Webhook Relay
Créez un webhook de relais entrant en utilisant l'appel pertinent de Postman. Le corps du message dans mon cas contient :
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Comme mentionné précédemment, je recommande de définir un auth_token à votre propre valeur secrète, tel qu'il est défini dans le fichier webapp.ini sur votre hôte.
La valeur de votre “target” doit correspondre à l'adresse de votre hôte et au port TCP où vous hébergerez l'application web.
La valeur de votre “domaine” doit correspondre à vos enregistrements MX configurés à l'étape 1.
Et voilà ! La tuyauterie est faite. Vous devriez maintenant pouvoir envoyer des certificats à votre adresse entrante, ils seront traités et apparaîtront sur votre hôte de l'application web – dans ce cas, un fichier nommé bob.lumreeker@gmail.com.crt.
Vous pouvez maintenant envoyer des emails 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 :
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
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.
