Per ottenere una terminologia corretta: il certificato è la parte pubblica. È pubblico così tutti lo sanno e quando un client si connette a un server SSL, quel certificato è una delle prime cose che il server invia al client. Ciò che intendi è: quando la chiave privata non è veramente privata, può ancora essere considerato SSL "sicuro"?
La risposta è fondamentalmente: No .
Tuttavia, ci sono dettagli sottili. Quando client e server parlano tra loro, sono d'accordo su una serie di algoritmi crittografici da utilizzare, chiamata suite di crittografia . Vedi lo standard per (la maggior parte) le suite di crittografia attualmente definite. Uno degli elementi della suite di cifratura è il metodo accordo chiave utilizzato per scambiare il "segreto pre-master" da da cui derivano tutte le altre chiavi. Quando la suite di crittografia è una suite "RSA" di base (ovvero il nome della suite di crittografia inizia con " TLS_RSA "), l'accordo chiave è la crittografia asimmetrica di base con RSA: il client genera un segreto pre-master casuale, lo crittografa con la chiave pubblica del server (dal suo certificato) e il server la decrittografa per recuperare il segreto pre-master.
Quando la chiave privata del server è nota a un utente malintenzionato che semplicemente origlia sul canale, quell'hacker può anche decifrare il messaggio dal client, ottenere il segreto pre-master e decrittografare tutto il dati. Sembra sicuro affermare che, in queste condizioni, è rimasta pochissima sicurezza.
Tuttavia, se la suite di cifrari negoziata è di tipo "effimero Diffie-Hellman" (il nome inizia con " TLS_DHE "), l'accordo di chiave effettivo utilizza Diffie-Hellman con coppie di chiavi DH pubbliche / private che sono state generate casualmente sul posto. La chiave privata del server (quella che è hardcoded e quindi non molto privata) viene utilizzata solo per firmare la chiave pubblica DH. In queste condizioni, un attaccante puramente passivo, che si limita a spiare i pacchetti di dati ma non interferisce, non sarà in grado di ottenere il segreto pre-master e la connessione rimarrà protetta. Questa funzione di DHE si chiama Perfect Forward Secrecy .
Tuttavia, anche con DHE, un utente malintenzionato attivo può impersonare il server e montare un Attacco man-in-the-middle , annullando qualsiasi sicurezza. PFS è un vantaggio effettivo solo se si considera il caso di un furto della chiave privata ulteriormente , in cui l'utente malintenzionato ruba la chiave privata del server dopo . A quel punto, è troppo tardi perché l'attaccante sia "attivo" e PFS lo blocca. Ma questa non è la tua situazione: prevedi un caso in cui l'hacker conosce già la chiave privata del server quando avviene la connessione. L'attaccante può quindi attivare un attacco attivo.
Quindi, a sum up : quando la chiave privata del server è nota agli aggressori, la sicurezza viene mantenuta solo contro gli aggressori passivi-soli e solo se il client e il server è d'accordo su una suite di crittografia DHE.
(In senso stretto, la sicurezza può essere salvata anche contro gli attaccanti attivi se la suite di crittografia è DHE e il server richiede un certificato client e la chiave privata del client non è nota all'attaccante. È un caso limite.)