En esta serie, hemos visto que incluir una firma S/MIME es bastante sencillo. Enviar correo electrónico cifrado con S/MIME es más complejo porque necesitas obtener las claves públicas de los destinatarios. Es una cosa cuando usas un cliente de correo para humanos como Thunderbird, pero ¿cómo puede funcionar eso con flujos de correo electrónico generados por aplicaciones?
En parte 1, tuvimos un recorrido rápido por S/MIME, observando la firma y el cifrado de nuestros flujos de mensajes a través de una variedad de clientes de correo. Parte 2 nos llevó a través de una herramienta de línea de comandos simple para firmar y cifrar correos electrónicos, luego enviarlos a través de SparkPost. Parte 3 mostró cómo inyectar flujos de correo seguros en plataformas locales como Port25 PowerMTA y Momentum.
En esta serie, hemos visto que incluir una firma S/MIME es bastante sencillo. Enviar correo cifrado con S/MIME es más complejo porque necesitas obtener las claves públicas de los destinatarios. Es una cosa cuando estás usando un cliente de correo para humanos como Thunderbird, pero ¿cómo puede eso funcionar con flujos de correo generados por apps?
Pero espera, hay otra forma de llegar a Mordor para obtener esas claves. Tu servicio puede invitar a tus clientes (vía correo electrónico, por supuesto) a enviarte de vuelta un correo firmado a una dirección de servicio al cliente conocida. Usando los poderes mágicos de los webhooks de SparkPost Inbound Relay, extraeremos y almacenaremos esa clave pública para que la uses.
Podemos resumir esto en un caso de uso simple:
Como receptor de mensajes, proporciono a tu servicio mi firma de correo electrónico personal a través de correo electrónico, de modo que en el futuro, los correos puedan serme enviados en forma cifrada con S/MIME.
A partir de esto, derivemos algunos requisitos más detallados:
Necesitamos un servicio de correo electrónico entrante siempre disponible y confiable para recibir esos correos firmados.
No debería haber requisitos especiales en el formato del correo, aparte de que debe llevar una firma S/MIME.
Dado que cualquiera puede intentar enviar un correo a este servicio, debería diseñarse de manera defensiva, por ejemplo, para rechazar mensajes "falsificados" de actores malintencionados. Habrá necesidad de varias capas de verificación.
Si todo está bien, el servicio almacenará el certificado en un archivo, utilizando el conocido formato de texto plano Privacy-Enhanced Mail (PEM).
Existen algunos requisitos no funcionales:
Los servicios de webhook de máquina a máquina pueden ser difíciles de ver solo por las respuestas a lo que está sucediendo por dentro. El servicio debería proporcionar registros extensos a nivel de aplicación legibles por humanos. En particular, el análisis y verificación de certificados debe ser registrado.
Añadimos casos de prueba para los internos de la app, utilizando el agradable marco de trabajo Pytest, y ejecutamos esas pruebas automáticamente al realizar check-in usando la integración de Travis CI con GitHub.
¡OK, comencemos!
1. Resumen de la solución
Aquí está cómo se verá la solución general.
2. Instalación, configuración y puesta en marcha de la aplicación web
3. Configuración de webhooks de SparkPost inbound relay
Primero, seleccionamos un dominio para usar como nuestra dirección de mensajes entrantes – aquí, será inbound.thetucks.com. Configure su dominio siguiendo esta guía. Aquí están los pasos que utilicé en detalle:
3.1 Añadir registros MX
Necesitarás acceso a tu cuenta específica de Proveedor de Servicios de Internet. Cuando termines, puedes verificarlos con dig – aquí está el comando para mi dominio.
dig +short MX inbound.thetucks.com
Deberías ver:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com.
3.2 Crear un Dominio Entrante
Usa la colección de API de Postman de SparkPost, seleccionando la llamada Inbound Domains / Create .. El cuerpo de la solicitud POST contiene tu dominio, por ejemplo:
{ "domain": "inbound.thetucks.com" }
3.3 Crear un Webhook de Retransmisión
Crea un webhook de retransmisión entrante usando la llamada relevante de Postman. El cuerpo del mensaje en mi caso contiene:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Como mencioné antes, recomiendo establecer un auth_token a tu propio valor secreto, como se establece en el archivo webapp.ini en tu host.
Tu valor "target" necesita coincidir con la dirección de tu host y el puerto TCP donde estarás alojando la aplicación web.
Tu valor "domain" necesita coincidir con tus registros MX configurados en el paso 1.
¡Eso es todo! La instalación está completa. Deberías poder enviar certificados a tu dirección de entrada, serán procesados y aparecerán en el host de tu aplicación web – en este caso, un archivo llamado bob.lumreeker@gmail.com.crt.
Ahora puedes enviar emails cifrados a Bob, usando las herramientas descritas en las partes 2 y 3 de esta serie.
Puedes examinar el contenido de un certificado usando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Internals: DKIM checking, validación de certificados
La aplicación verifica que los correos electrónicos recibidos tengan DKIM válidos y verifica que los propios certificados sean válidos, como se describe aquí. También hay notas de implementación allí, e ideas para trabajo futuro.
Resumiendo…
Hemos visto cómo se pueden recopilar fácilmente las claves públicas de los destinatarios usando un correo electrónico a una dirección de webhook de retransmisión entrante. Una vez hecho, esos destinatarios pueden recibir sus mensajes en forma cifrada S/MIME.
¡Eso es todo por ahora! Felices envíos.
