Server di store-and-forward SMTP abilitato a TLS: deve memorizzare le chiavi private?

2

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?
    
posta daftuser 02.10.2015 - 03:38
fonte

2 risposte

1

Lo scopo del certificato è dimostrare l'identità dell'endpoint nella connessione e scoraggiare l'uomo negli attacchi centrali. Per dimostrare di possedere il certificato è necessario avere la chiave privata, perché il certificato stesso è pubblico e quindi noto anche a un utente malintenzionato. Di solito la chiave privata viene memorizzata su disco o le operazioni crittografiche necessarie vengono eseguite in un modulo hardware (HSM, smartcard). Ma c'è anche un'implementazione per fare queste operazioni su un sistema remoto dove si potrebbe avere un maggiore controllo, vedi cloudless keyless ssl .

Oltre a ciò TLS in teoria fornirà un trasporto sicuro ma non si aspetta troppo dal modo in cui è attualmente utilizzato tra i server di posta. Molti server di posta ignorano errori di certificato come il nome host autofirmato o non corrispondente. Inoltre, per garantire che la posta venga consegnata al server corretto, sarà necessario proteggere anche i record MX, ovvero i record devono essere protetti dal DNSSec ancora usato di rado e il MTA di consegna deve utilizzare DNSSec per ottenere il MX informazione. Quindi tutto ciò che ottieni dall'uso corrente di TLS è una protezione contro lo sniffing passivo, ma non contro un man-in-the-middle attivo. Questo non significa che non dovresti provare a implementare correttamente TLS sul tuo sito, ma solo tu dovresti sapere quanta sicurezza ottieni realmente.

    
risposta data 02.10.2015 - 06:53
fonte
0

No. Il client richiederà al server di dimostrare che detiene la chiave privata prima di completare l'handshake TLS. Senza la chiave privata, non avrai mai una connessione. Per la Wikipedia

The TLS_DH_anon and TLS_ECDH_anon key agreement methods do not authenticate the server or the user and hence are rarely used because those are vulnerable to Man-in-the-middle attack.

Nessun cliente ragionevole consentirà tali codici.

    
risposta data 02.10.2015 - 05:31
fonte

Leggi altre domande sui tag