S/MIME Partie 4 : Collecte des clés publiques des destinataires facilement – avec les webhooks de relais entrant SparkPost
·
1 févr. 2019
Points Clés
Prémisse : Envoyer un e-mail chiffré S/MIME n'est pas difficile une fois que vous pouvez automatiquement recueillir la clé publique de chaque destinataire. Ce post comble cette lacune en utilisant SparkPost Inbound Relay Webhooks pour recevoir les e-mails signés, extraire les certificats et les stocker pour un chiffrement ultérieur.
Objectif : Construire un service webhook basé sur Flask qui écoute les messages signés entrants, les valide (vérifications DKIM + certificat), et écrit en toute sécurité chaque clé publique sur le disque pour être utilisé dans le courrier sécurisé sortant.
Points forts :
Problème : L'échange manuel de clés ne s'adapte pas aux e-mails générés par les applications.
Solution : Invitez les utilisateurs à envoyer un e-mail signé ; le webhook entrant analyse automatiquement et stocke leur certificat PEM.
Étapes de configuration :
Configurez un Domaine Entrant et les enregistrements MX (par exemple, inbound.yourdomain.com).
Créez un Inbound Relay Webhook via l'API SparkPost pointant vers le point de terminaison de votre application.
Déployez une petite application Flask (webapp.py) en utilisant la configuration de webapp.ini.
Consigner de manière exhaustive pour la transparence ; intégrer Pytest + Travis CI pour une validation automatisée.
Mesures de sécurité :
Vérifier les signatures DKIM et l'authenticité des messages.
Valider la chaîne de confiance du certificat avant de stocker.
Utiliser un jeton d'authentification secret dans les en-têtes du webhook.
Résultat :
Chaque message entrant valide crée un fichier de certificat tel que bob.lumreeker@gmail.com.crt.
Une fois stockées, ces clés permettent des réponses chiffrées en utilisant des scripts antérieurs des parties 2 et 3.
Points forts des Q&A
Pourquoi la collecte des clés des destinataires est-elle si critique pour S/MIME ?
Parce que le chiffrement nécessite la clé publique de chaque destinataire; automatiser cette étape permet à toute application d'envoyer des courriers sécurisés sans échange manuel.
Comment le SparkPost Inbound Relay Webhook simplifie-t-il la collecte clé ?
Il convertit tout e-mail entrant signé en une charge utile JSON structurée, permettant à votre application d'analyser et de conserver des certificats de manière programmatique.
Quels sont les garde-fous qui empêchent le spoofing ou les soumissions indésirables ?
Le service valide les signatures DKIM, applique les jetons d'authentification, et rejette les messages malformés ou non signés.
Où sont stockés les certificats et sous quel format ?
Ils sont écrits sur le disque au format PEM (fichiers
.crt), prêts à être utilisés par la chaîne d'outils de signature/chiffrement construite dans les parties précédentes.Quel est le workflow du développeur ?
Exécutez l'application Flask, vérifiez avec Postman en utilisant la charge utile d'exemple fournie, puis connectez-la au webhook en direct de SparkPost pour une opération continue.
Conclusion générale ?
La gestion des clés S/MIME peut être entièrement automatisée avec quelques lignes de Python et les API SparkPost—apportant un chiffrement évolutif à tout flux de travail d'e-mails 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. Installation, configuration et démarrage de l'application web
3. Configuration des webhooks de relais entrant SparkPost
4. Internes : vérification DKIM, validation de certificat
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 également des notes de mise en œuvre et des idées pour des travaux ultérieurs.
En résumé…
Nous avons vu comment les clés publiques des destinataires peuvent être facilement rassemblées en utilisant un email vers une adresse de relais webhooks 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.
