So che l'e-mail è intrinsecamente insicura in ogni caso, ma considerando che praticamente tutti quelli a cui spedisco le e-mail utilizzano un provider cloud grande e un po 'affidabile, (suggerimento, inizia con G), mi aspetto che la maggior parte della mia e-mail sia inviato tramite MTA relativamente sicuri che richiedono o preferiscono utilizzare TLS.
Da questo presupposto vorrei trarre la conclusione che se volessi ospitare il mio server di posta elettronica e se mi preoccupassi della sicurezza, DEVI supportare TLS e avere un certificato firmato da un'autorità fidata.
Ok, va tutto bene, posso sistemarlo da solo. Ma cosa succede se voglio ospitare autonomamente questo server? So che posso facilmente pagare un fornitore di servizi cloud per ospitarmi, ma ho un desiderio irrazionale di sfuggire completamente al cloud e di costruire la mia infrastruttura.
Tuttavia, questo apre un host (nessun gioco di parole) di altri problemi. La consegna di e-mail da IP residenziali è discutibile al meglio. L'accesso a Internet e l'elettricità non hanno il 100% di uptime nelle aree residenziali. Forse rovino il mio server e devo ridistribuirlo. O forse devo portarlo giù per aggiornarlo.
Quindi, forse desidero noleggiare una VM da un provider cloud ed eseguire un server SMTP, ma allo stesso tempo non voglio che la mia chiave privata lasci la mia macchina.
Sono un programmatore molto capace, quindi sto prendendo in considerazione l'idea di provare questo. Non sono sicuro che sia fisicamente possibile dato il protocollo TLS.
Stavo analizzando questo file, link , un'implementazione javascript di TLS, cercando di capire come potrebbe essere fatto. Ho trovato questo diagramma di stato della rete:
* =======================FULL HANDSHAKE======================
* Client Server
*
* ClientHello -------->
* ServerHello
* Certificate*
* ServerKeyExchange*
* CertificateRequest*
* <-------- ServerHelloDone
* Certificate*
* ClientKeyExchange
* CertificateVerify*
* [ChangeCipherSpec]
* Finished -------->
* [ChangeCipherSpec]
* <-------- Finished
* Application Data <-------> Application Data
Ho anche sfogliato questo articolo: link
Sembra che i passaggi contrassegnati con un asterisco siano facoltativi in base al protocollo. Generalmente, a quanto ho capito, il client e il server devono condividere le chiavi pubbliche, calcolare individualmente e separatamente un segreto condiviso, negoziare una cifra e quindi iniziare la comunicazione attraverso quella chiave reciprocamente compresa utilizzando il segreto condiviso come seme da entrambe le parti.
Se dovessi farlo, suppongo che dovrei creare un'implementazione leggermente rialzata di TLS, chiamiamola "YesTLS".
YesTLS è stupido, ma molto estroverso. Cercherà di accontentare tutti quelli che parlano, anche se non ha idea di cosa stiano dicendo. Lo configurerei con le mie chiavi pubbliche e ogni altro dato richiesto, e poi risponderebbe alle connessioni TCP su determinate porte che sto ascoltando nella mia applicazione. L'idea è che se il client remoto non richiede effettivamente una firma digitale univoca per verificare che stiano parlando con il "portatore di chiavi" che pensano di essere, allora il mio server non ha bisogno di tenere la chiave. Può semplicemente archiviare i pacchetti crittografati mentre li riceve. Quindi, il mio server, che in realtà ha le chiavi, può richiedere quelle connessioni registrate una per una quando è pronto e riattivarle utilizzando le chiavi private reali, ricevendo in tal modo i messaggi crittografati.
In questo modo posso limitare la memorizzazione di e-mail in testo semplice.
Questo sarebbe effettivamente possibile con TLS? Voglio ottenere un rapido controllo della sanità mentale prima di iniziare a provare a farlo accadere.
mail.google.com yes-TLS-smtp-server trusted-smtp-server
X <--- config with pubkey <---
~
---> request TLS connection ---> X
X <--- send public key <-----
---> send public key ---> X
X <--- ok, i'm ready <---
---> encrypted stream ---> X
~
X <--- get new emails <---
---> send google public key --> X
---> and other session info --> X
X <--- ok, i'm ready <---
---> encrypted stream ---> X
should be decryptable?