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 fait un tour rapide de S/MIME, en examinant la signature et le cryptage de nos flux de messages à travers une gamme de clients de messagerie. La partie 2 nous a montré un outil simple en ligne de commande pour signer et crypter les e-mails, puis les envoyer via SparkPost. La partie 3 a démontré comment injecter des flux de courrier sécurisé sur des plateformes locales telles que Port25 PowerMTA et Momentum.
Dans cette série, nous avons vu qu'inclure une signature S/MIME est assez simple. Envoyer des mails chiffrés S/MIME est plus complexe car il est nécessaire d'obtenir les clés publiques des destinataires. C'est une chose lorsque vous utilisez un client de messagerie pour les humains comme Thunderbird, mais comment cela fonctionne-t-il avec des flux de courrier 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 mail signé à une adresse de service client connue. En utilisant les pouvoirs magiques de SparkPost Inbound Relay webhooks, nous extrairons et stockerons cette clé publique pour votre usage.
Nous pouvons résumer cela dans un cas d'utilisation simple :
En tant que destinataire de messages, je fournis à votre service ma signature email personnelle via email, afin que, à l'avenir, les emails puissent m'être envoyés sous forme chiffrée S/MIME.
À partir de cela, dérivons quelques exigences plus détaillées :
Nous avons besoin d'un service de messagerie entrant toujours disponible et fiable pour recevoir ces e-mails signés.
Il ne devrait y avoir aucune exigence particulière sur le format du courrier, autre que le fait qu'il devrait comporter une signature S/MIME.
Étant donné que n'importe qui peut essayer d'envoyer un email à ce service, il devrait être conçu de manière défensive, par exemple pour rejeter les messages "spoof" de mauvais acteurs. Il faudra plusieurs couches de vérification.
Si tout est en ordre, le service stockera le certificat dans un fichier, en utilisant le format bien connu de texte brut Privacy-Enhanced Mail (PEM).
Il y a quelques exigences non fonctionnelles :
Les services de webhook machine-à-machine peuvent être difficiles à comprendre simplement à partir des réponses sur ce qui se passe à l'intérieur. Le service devrait fournir des logs au niveau de l'application, lisibles par l'homme. En particulier, l'analyse et la vérification des certificats doivent être consignées.
Nous ajoutons des cas de test pour les internes de l'application, en utilisant le joli cadre Pytest, et nous exécutons ces tests automatiquement au moment de l'enregistrement en 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
Tout d'abord, 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 fournisseur de services Internet spécifique. Une fois 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 la collection API Postman 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 de relais
Créez un webhook de relais entrant en utilisant l'appel Postman pertinent. 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, telle que définie 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.
C'est fait ! La plomberie est terminée. Vous devriez maintenant pouvoir envoyer des certificats à votre adresse entrante, ils seront traités et apparaîtront sur votre hôte d'application web – dans ce cas, un fichier nommé bob.lumreeker@gmail.com.crt.
Maintenant, vous pouvez envoyer des e-mails cryptés à Bob, en utilisant les outils décrits dans les parties 2 et 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.
