Certificato SSL - è necessaria la passphrase e come lo sa l'apache?

13

Voglio generare una richiesta di firma del certificato per il mio server e, per farlo, prima ho bisogno di una chiave privata sicura. Quando creo una chiave privata utilizzando openssl genrsa -des3 -out server.key 2048 , mi viene chiesto di fornire una passphrase. Dopo aver fatto alcune ricerche, ho scoperto che non avere passphrase è un rischio elevato per la sicurezza perché una volta che la mia chiave privata viene compromessa, l'hacker sarà in grado di decodificare tutto ciò che è stato crittografato usando la mia chiave.

La mia domanda è: come dovrebbe funzionare il mio server con una chiave privata che ha bisogno di una passphrase. Dato che è senza testa, non posso inserire la chiave quando il server si avvia. Come lo gestirà Apache?

Non sto chiedendo come rimuovere la passphrase (so come), sono piuttosto interessato a come sarà in grado di gestirlo il mio server ed è davvero un grosso rischio per la sicurezza non usare una passphrase? Voglio dire, una volta che il web server viene compromesso, non sarebbe più facile installare un cavallo di troia?

    
posta Matt3o12 12.10.2014 - 19:01
fonte

3 risposte

11

Se proteggi la tua chiave privata con una passphrase, Apache non può usarlo a meno che tu non fornisca Apache con la passphrase ogni volta che si riavvia o tu riavvii. E dal momento che mantenere la passphrase memorizzata nel filesystem sconfiggerebbe il punto della passphrase, questo significa avere un qualche tipo di metodo per passare la passphrase ad Apache da esternamente, ogni volta che si riavvia o si riavvia.

Alcuni lo fanno, ma la sua impraticabilità significa che la maggior parte delle persone usa una chiave privata non crittografata.

Se la tua chiave privata non è crittografata, la sua protezione deriva dal fatto che solo il tuo superutente può leggerlo, e quindi dipende in gran parte dall'integrità del sistema e dalla sua capacità di privilegiare l'escalation o simili.

Se la tua chiave privata è compromessa, puoi andare all'autorità di certificazione della firma e chiedere loro di revocare il certificato. La revoca non è una bacchetta magica, tuttavia con alcuni sistemi che non verificano la revoca e un ritardo tipico tra la revoca di un certificato e le informazioni sulla revoca controllata.

once my private key gets compromised, they hacker will be able to decrypt everything that was encrypted using my key.

Questo scenario è il tipo di cosa che inoltro segreto è progettato per prevenire. In TLS le due parti comunicanti possono, se entrambe hanno il supporto necessario, negoziare impostazioni che abilitino la segretezza, in modo che nel caso in cui la chiave privata venga compromessa è ancora impossibile decrittografare le comunicazioni precedenti.

Il Test server SSL può controllare se il Segreto diretto, tra le altre cose, funzioni sul tuo server.

    
risposta data 13.10.2014 - 04:36
fonte
1

I mean once the web server gets compromised, wouldn't it be easier to install a trojan hourse?

Essenzialmente corretto. Una volta che un utente malintenzionato ha un controllo sufficiente sul proprio server, di solito può semplicemente sostituire il certificato crittografato con un certificato SSL economico o gratuito del tipo che conferma solo l'accesso al server (cosa che fa l'hacker). I browser come regola non discriminano tra i certificati firmati da qualsiasi CA valida.

Oppure possono semplicemente svuotare la configurazione di Apache per fungere da proxy inverso per inoltrare il traffico a qualsiasi indirizzo che scelgono.

Il vantaggio principale di un server con un certificato SSL crittografato caricato in fase di esecuzione è che il certificato non può essere rubato per eseguire un attacco uomo nel mezzo. Questo è principalmente rilevante per i sistemi in cui l'hacker aveva solo un controllo limitato sul server; sufficiente per rubare i dati ma non sovrascrivere le risorse e riavviare i servizi.

    
risposta data 13.10.2014 - 08:13
fonte
0

I'm not asking how to remove the passphrase (I know how), I'm rather interested in how will my server be able to handle it and is it really a big security risk not to use a passphrase? I mean once the web server gets compromised, wouldn't it be easier to install a trojan horse?

Per dare una prospettiva leggermente diversa su questo. Ponendo la domanda se un grosso rischio per la sicurezza sia un po 'complicato. Prima di tutto, facciamo questa domanda, le informazioni memorizzate sul sito sono confidenziali? C'è più di un rischio per la sicurezza se il sito è offline? Se si dispone di informazioni riservate sul sito Web o si viaggia attraverso il sito Web, sarebbe altamente rischioso non crittografare la propria chiave privata. Tuttavia, se non si dispone di informazioni riservate ed è più importante che il sito sia sempre attivo, potrebbe essere più rischioso per la sicurezza firmare la chiave privata, in quanto il poster precedente menzionato significa che è necessario inserire la password su carico Apache.

Ci sono 3 aree di sicurezza, in generale, Riservatezza, Integrità e Accesso, firmerai il certificato se C & I sono un problema e non se A è un problema.

Ovviamente puoi sempre avere la tua torta e mangiarla avendo una farm di Webserver, o anche solo istanze di vm, quindi carica il bilanciamento con un controllo di stato su 443, in questo modo il traffico viene reindirizzato ai server Apache in esecuzione mentre qualcuno partecipa per inserire la password per la chiave privata, questo richiede solo denaro, più ne hai di più che puoi fare.

    
risposta data 13.10.2014 - 16:43
fonte

Leggi altre domande sui tag