Tutte le guide e le implementazioni di sTunnel sul posto di lavoro fanno la stessa cosa, dicono che una volta che la chiave privata e il certificato pubblico sono stati creati sul server, è necessario raggrupparli e condividerli con l'host client.
Mentre questo ha perfettamente senso per me con il certificato pubblico (dato che il client crittografa i dati che lo utilizzano) sicuramente la condivisione della chiave privata va contro l'intero ethos SSL?
Stunnel è SSL e, in SSL, le chiavi private non devono mai viaggiare. L'ethos SSL è che i certificati X.509 vengono utilizzati per autenticare i peer senza un segreto condiviso pre-distribuito. Ad esempio, quando colleghi il tuo browser Web a https://example.com , il livello SSL riconosce il certificato del server e può assicurarsi che parli al vero "esempio.com" senza bisogno di conoscenze preliminari su quel sito specifico.
Stunnel è fuori da questo modello, poiché viene tipicamente usato tra due macchine che si conoscono già. Ciò consente di utilizzare modelli più leggeri.
Per impostazione predefinita, stunnel non convalida i certificati . Questo è indicato come indicato nella pagina HOWTO (nella sezione "Come verificare i certificati di stunnel?"). Se non hai cambiato questa impostazione, allora non importa affatto quali certificati utilizzi. Ovviamente, i certificati non validi lasciano il tunnel vulnerabile agli attacchi Man-in-the-Middle . Questo può essere ancora accettabile, dal punto di vista della sicurezza, se il tunnel è destinato a trasmettere solo un protocollo sottostante che include già la protezione crittografica; in genere, si utilizza stunnel per superare il firewall di una scuola / azienda, ma all'interno si esegue solo un SSH. Lo stunnel è lì solo per mantenere il firewall inconsapevole della natura SSHish della comunicazione. In questo caso specifico, i certificati di convalida non vanno bene. (Bene, per quanto riguarda la tua sicurezza, stai ancora aggirando il firewall della tua scuola / azienda, che è moralmente e legalmente discutibile.)
La maggior parte delle guide di stunnel spiega come configurare stunnel in tale modalità di non verifica e copiare il certificato su client e server è il modo più conveniente per mantenere le cose in esecuzione.
Se configura stunnel per convalidare i certificati, allora:
Il client deve essere in grado di verificare che il certificato del server (il certificato sia la parte pubblica, NON la chiave privata), che implica o conoscerlo in anticipo, o verificarne la firma con riguarda una CA nota.
Quando il client ha verificato che il certificato del server è autentico, deve comunque verificare che si tratti del certificato del server previsto.
Se il server richiede un certificato dal client, deve similmente essere in grado di verificarlo e verificare che corrisponda a un client consentito.
Non c'è codice in stunnel che confronta i certificati client e server l'uno con l'altro. Vivono davvero in mondi distinti; il certificato del client viene convalidato sul server, il certificato del server viene convalidato sul client. Avere lo stesso certificato su entrambi i sistemi non ha alcuna influenza sul comportamento di entrambi.
In un sistema di controllo dei certificati, se sia il client che il server utilizzano lo stesso certificato, il client può impersonare il server e viceversa. Se ci sono solo due macchine, questo non importa molto. Se ci sono più macchine (ad esempio due client da connettere sullo stesso server), questo può essere molto importante (non è necessario consentire a un client di incorniciare un altro client con un server falso). E, naturalmente, la condivisione della chiave privata implica che la chiave privata viaggiava da una macchina all'altra, che utilizzava un tunnel preesistente (ad esempio SSH) oppure un'operazione rischiosa. Le chiavi private devono rimanere private e più una chiave privata viaggia, meno privata diventa.
No.
Se si desidera utilizzare l'autenticazione del certificato client, è necessario copiare la chiave privata del client e il certificato dal client dall'autorità di certificazione.
Se si desidera consentire ai client di autenticare un server, è necessario copiare la chiave privata del server e il certificato dall'autorità di certificazione sul server.
Esattamente come si desidera autenticare l'impatto dell'estremità remota su quali altre risorse sono necessarie dove. Prendendo il caso più semplice di un client che si connette in modo anonimo (cioè senza un certificato client) a un server, il client può
SSL è tutto basato su un menage-a-trois tra il server, il client e l'autorità di certificazione.
Leggi altre domande sui tag encryption unix openssl public-key-infrastructure