In partie 1, we had a quick tour of S/MIME, looking at signing and encryption of our message streams across a range of mail clients. Partie 2 took us through a simple command-line tool to sign and encrypt emails, then send them through SparkPost. Part 3 showed how to inject secure mail streams into on-premises platforms such as Port25 PowerMTA and Momentum.

Dans cette série, nous avons vu comment inclure une signature S/MIME est assez simple. L'envoi de 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 peut-il fonctionner avec les flux de courrier électronique générés par les applications ?

Mais attendez - il existe un autre moyen d'entrer dans le Mordor pour obtenir ces clés. Votre service peut inviter vos clients (par e-mail, bien sûr) à vous renvoyer un courrier signé à une adresse connue du service client. En utilisant les pouvoirs magiques des webhooks SparkPost Inbound Relay, nous allons extraire et stocker cette clé publique pour que vous puissiez l'utiliser.

Nous pouvons résumer cela par un simple cas d'utilisation :

• 
  

• En tant que destinataire de messages, je mets à la disposition de votre service ma signature électronique personnelle par courrier électronique, afin qu'à l'avenir, les courriers électroniques puissent m'être envoyés sous forme cryptée S/MIME.

• 
  

A partir de là, nous allons déduire des exigences plus détaillées :

• Nous avons besoin d'un service de courrier électronique entrant toujours actif et fiable pour recevoir ces courriels signés.

• Il ne devrait pas y avoir d'exigences particulières concernant le format du courrier, si ce n'est qu'il doit porter une signature S/MIME.

• Étant donné que n'importe qui peut essayer d'envoyer un courrier à ce service, celui-ci doit être conçu de manière défensive, par exemple pour rejeter les messages "usurpés" provenant de mauvais acteurs. Il devra y avoir plusieurs niveaux de vérification.

• If everything checks out OK, the service will store the certificate in a file, using the well-known plain-text Vie privée-Enhanced Mail (PEM) format.

• 
  

Il existe quelques exigences non fonctionnelles :

• Les services de webhooks de machine à machine peuvent être difficiles à voir à partir des réponses à ce qui se passe à l'intérieur. Le service doit fournir des journaux de niveau application lisibles par l'homme. En particulier, l'analyse et la vérification des certificats doivent être enregistrées.

• We add test cases for the app internals, using the nice Pytest framework, and run those tests automatically on check-in using Travis CI integration with GitHub.

• 
  

OK - commençons !

1. Aperçu de la solution

Voici à quoi ressemblera la solution globale.

2. Installer, configurer et démarrer l'application web

Nous allons commencer par cette partie, afin de la tester complètement avant de mettre en place les webhooks des relais entrants.

Le web app is included in the same Projet GitHub as parts 1 – 3, so if you’ve followed those parts, you already have it. Here are the new bits:

• Programme readSMIMEsig.py - lire un email et analyser les certificats intermédiaires et d'utilisateur.

• Programme webapp.py - application web simple, compatible avec Flask, à utiliser avec les Webhooks SparkPost Inbound Relay.

• webapp.ini - fichier de configuration pour les applications ci-dessus. Un fichier de configuration permet de transmettre facilement les mêmes valeurs aux applications en ligne de commande et aux applications Web.

You need to ensure your host has the correct TCP port number open to inbound requests from the outside world so that SparkPost can POST messages to your app. If you’re hosted on AWS EC2, for example, you’ll need to configure the Groupe de sécurité of your instance.

Instructions for configuring and starting the web app are given here – it’s quite easy. To check your app is running and accessible from the outside world, you can send (blank) requests from another host using curl, for example:

curl -X POST https://app.trymsys.net:8855/

Vous devriez voir une réponse telle que :

{"message":"Unknown Content-Type in request headers"}

C'est une bonne chose : votre application fonctionne !

Dans webapp.log sur votre hôte, vous verrez une sortie similaire à celle-ci :

2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type : None

To help you play with real data in your app straight away, you can import this specific Demande du facteur from the project repo. This simulates what your SparkPost account will be doing, i.e. it sends an https POST containing an email with a specific, valid certificate (belonging to a test account of mine) to your app.

Il vous suffit de modifier l'adresse cible dans la requête (dans la case grise ci-dessus) pour qu'elle corresponde à votre installation. Si vous avez modifié la valeur du jeton dans webapp.ini, ajustez la valeur de l'en-tête dans Postman pour qu'elle corresponde.

Si votre application fonctionne, vous verrez une réponse "200 OK" dans Postman. Le fichier webapp.log de votre hôte contiendra une sortie comme celle-ci :

2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True

Pour un contrôle rapide, regardez la dernière ligne : si elle indique "written file", c'est bon. Le reste montre le processus de vérification DKIM et de validation du certificat.

3. Configuration des webhooks du relais entrant SparkPost

Firstly, we select a domain to use as our inbound message address –  here, it will be inbound.thetucks.com. Set your domain up following this guide. Here are the steps I used in detail:

3.1 Ajouter des enregistrements MX

Vous devez avoir accès au compte de votre fournisseur d'accès Internet. Quand c'est 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

Use the SparkPost Collection d'API Postman, selecting the Inbound Domains / Create .. call. Le body of the POST request contains your domain, for example:

{    "domain": "inbound.thetucks.com" }

3.3 Créer un relais Webhook

Créez un webhook de relais entrant en utilisant l'appel Postman correspondant. Dans mon cas, le corps du message contient :

{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }

As mentioned before, I recommend définir un auth_token to your own secret value, as set in the webapp.ini file on your host.

Votre valeur "cible" doit correspondre à l'adresse de l'hôte et au port TCP où vous hébergez l'application Web.

La valeur de votre "domaine" doit correspondre à vos enregistrements MX définis à l'étape 1.

Voilà, c'est fait ! La plomberie est terminée. Vous devriez maintenant être en mesure d'envoyer des certificats à votre adresse d'entrée, 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.

Now you can send encrypted emails to Bob, using the tools described in parts 2 & 3 of this series.

Vous pouvez examiner le contenu d'un certificat en utilisant :

openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout

4. Internes : Vérification DKIM, validation des certificats

The app checks received emails have valid DKIM and checks that the certificates themselves are valid, as described here. There are implementation notes in there too, and ideas for further work.

En résumé...

Nous avons vu comment les clés publiques des destinataires peuvent être recueillies facilement à l'aide d'un courriel envoyé à une adresse webhooks de relais entrant. Une fois cette opération effectuée, ces destinataires peuvent recevoir leurs messages sous forme cryptée S/MIME.

C'est tout pour le moment ! Bon envoi.