In questa serie, abbiamo visto che includere una firma S/MIME è piuttosto semplice. Inviare email crittografate S/MIME è più complesso perché devi ottenere le chiavi pubbliche dei destinatari. È una cosa quando usi un client di posta per umani come Thunderbird, ma come può funzionare con flussi email generati da un'app?
In parte 1, abbiamo fatto un breve tour di S/MIME, esaminando la firma e la crittografia dei nostri flussi di messaggi attraverso una gamma di client di posta. Parte 2 ci ha guidato attraverso un semplice strumento da riga di comando per firmare e crittografare le email, quindi inviarle tramite SparkPost. Parte 3 ha mostrato come iniettare flussi di posta sicuri su piattaforme locali come Port25 PowerMTA e Momentum.
In questa serie, abbiamo visto come includere una firma S/MIME sia abbastanza semplice. Inviare mail crittografate S/MIME è più complesso perché è necessario ottenere le chiavi pubbliche dei destinatari. È una cosa quando si utilizza un client di posta per umani come Thunderbird – ma come può funzionare con flussi di email generati dalle app?
Ma aspetta – c'è un altro modo per entrare in Mordor e ottenere quelle chiavi. Il tuo servizio può invitare i tuoi clienti (via email, naturalmente) a inviarti una mail firmata a un indirizzo di servizio clienti noto. Utilizzando i poteri magici dei webhooks SparkPost Inbound Relay, estrarremo e memorizzeremo quella chiave pubblica per farti utilizzare.
Possiamo riassumere questo in un semplice caso d'uso:
Come destinatario di messaggi, fornisco al tuo servizio la mia firma email personale via email, in modo che in futuro mi possano essere inviate email in forma crittografata S/MIME.
Da questo, traiamo alcuni requisiti più dettagliati:
Abbiamo bisogno di un servizio email in entrata, sempre attivo e affidabile, per ricevere quelle email firmate.
Non ci dovrebbero essere requisiti speciali sul formato della mail, a parte il fatto che deve contenere una firma S/MIME.
Poiché chiunque può provare a inviare una mail a questo servizio, dovrebbe essere progettato in modo difensivo, ad esempio, per respingere i messaggi "spoof" da malintenzionati. Ci dovranno essere diversi livelli di controllo.
Se tutto va bene, il servizio memorizzerà il certificato in un file, utilizzando il formato di testo semplice Privacy-Enhanced Mail (PEM).
Ci sono alcuni requisiti non funzionali:
I servizi webhook macchina-a-macchina possono essere difficili da vedere solo dalle risposte a cosa sta succedendo all'interno. Il servizio dovrebbe fornire ampi log leggibili dall'uomo a livello di applicazione. In particolare, l'analisi e il controllo dei certificati dovrebbero essere registrati nei log.
Aggiungiamo casi di test per gli interni dell'app, utilizzando il bel framework Pytest, ed eseguiamo automaticamente quei test al check-in utilizzando l'integrazione Travis CI con GitHub.
OK – iniziamo!
1. Panoramica della soluzione
Ecco come apparirà la soluzione complessiva.
2. Installazione, configurazione e avvio dell'app web
3. Configurazione di SparkPost inbound relay webhooks
Innanzitutto, selezioniamo un dominio da utilizzare come nostro indirizzo di messaggi in entrata – qui sarà inbound.thetucks.com. Configura il tuo dominio seguendo questa guida. Ecco i passaggi che ho utilizzato in dettaglio:
3.1 Aggiungi i Record MX
Avrai bisogno di accesso al tuo account specifico del provider di servizi Internet. Una volta fatto, puoi controllarli con dig – ecco il comando per il mio dominio.
dig +short MX inbound.thetucks.com
Dovresti vedere:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com.
3.2 Crea un Dominio Inbound
Utilizza la SparkPost Postman API collection, selezionando il call Inbound Domains / Create... Il corpo della richiesta POST contiene il tuo dominio, per esempio:
{ "domain": "inbound.thetucks.com" }
3.3 Crea un Relay Webhook
Crea un relay webhook in entrata utilizzando la relativa chiamata Postman. Il corpo del messaggio nel mio caso contiene:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Come menzionato in precedenza, consiglio di impostare un auth_token con il tuo valore segreto personale, come impostato nel file webapp.ini sul tuo host.
Il valore “target” deve corrispondere all'indirizzo e alla porta TCP dell'host in cui ospiterai l'applicazione web.
Il valore “domain” deve corrispondere ai record MX configurati nel passaggio 1.
Questo è tutto! L'installazione è completata. Ora dovresti essere in grado di inviare i certificati al tuo indirizzo in entrata, saranno elaborati e visualizzati sul tuo host dell'applicazione web – in questo caso, un file chiamato bob.lumreeker@gmail.com.crt.
Ora puoi inviare email crittografate a Bob, utilizzando gli strumenti descritti nelle parti 2 & 3 di questa serie.
Puoi esaminare il contenuto di un certificato usando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Internals: Controllo DKIM, validazione dei certificati
L'app controlla che le email ricevute abbiano DKIM validi e verifica che i certificati stessi siano validi, come descritto qui. Ci sono anche note di implementazione lì, e idee per lavori futuri.
Ricapitolando…
Abbiamo visto come le chiavi pubbliche del destinatario possano essere raccolte facilmente utilizzando un'email a un indirizzo di webhook in entrata. Una volta fatto, quei destinatari possono ricevere i loro messaggi in forma crittografata S/MIME.
Questo è tutto per ora! Buon invio.
