Come dovrei memorizzare le chiavi SSL sul server?

Question

Come dovrei memorizzare le chiavi SSL sul server?

#1 da (22 voti)
#2 da (2 voti)

21

Ho un server web Node.JS HTTPS istanziato come segue:

var privateKey = fs.readFileSync('./../ssl/localhost.key').toString();
var certificate = fs.readFileSync('./../ssl/localhost.crt').toString();

https.createServer({
    key: privateKey,
    cert: certificate
}, server).listen(80, 'localhost');

La mia chiave privata è sul mio server che Node.JS legge per creare il server web HTTPS. Se un hacker ha accesso in lettura ai file del server, può accedere alla chiave privata e impersonare il server web.

La chiave privata dovrebbe essere memorizzata sul server? Dovrebbe essere distrutto una volta che il server HTTPS è stato istanziato?

webserver tls

posta Randomblue 11.01.2013 - 20:33

fonte

2 risposte

2

Probabilmente stai cercando un proxy inverso come nginx. È considerato best practice ™.

Applications running in production usually need to run on port 80 (HTTP), port 443 (HTTPS), or both. This can be a challenge if several components of your application interact with the user or you are using a web server on port 80 to deliver other assets. This makes it necessary to proxy to the Socket.IO server, and NGINX is the best way to do that. - Using NGINX and NGINX Plus with Node.js and Socket.IO, the WebSocket API - nginx blog

o HARDENING NODE. JS FOR PRODUCTION PARTE 3: ZERO DOWNTIME DEPLOYMENTS WITH NGINX

Fondamentalmente, probabilmente stai cercando una soluzione stabile anche per il bilanciamento del carico, la limitazione delle richieste, ecc. mentre stai tentando di memorizzare la chiave privata in modo sicuro.

risposta data 11.09.2015 - 00:44

fonte

Leggi altre domande sui tag webserver tls

Perché il doppio invio di token CSRF deve essere crittografato con numeri casuali forti? Quali sono i buoni modi per educare alla sicurezza IT in un'azienda?

score 22 · Accepted Answer

Non vuoi distruggere la tua chiave privata: ne avrai bisogno di nuovo se il tuo server si riavvia. I riavvii accadono a volte ...

Questa è un'osservazione generica: tu vuoi il tuo server per poter riavviare in modo incustodito. Pertanto deve contenere la chiave privata e quella deve privata essere disponibile per il software del server.

Se un utente malintenzionato dirotta la tua macchina completa, ottiene una copia della tua chiave. Questo è un dato di fatto. Convivici. Esistono tuttavia delle attenuazioni:

È possibile utilizzare le suite di crittografia "DHE" per SSL. Con queste suite di crittografia, la chiave del server viene utilizzata per le firme, non per la crittografia. Ciò significa che l'attaccante che ruba la tua chiave può in seguito impersonare il tuo server (ad esempio, eseguire un server falso) ma non decrittografare le sessioni SSL che ha precedentemente registrato. Questa è una buona proprietà conosciuta come Perfect Forward Secrecy .
Se memorizzi la chiave in un modulo di sicurezza hardware , la chiave non verrà rubata. L'attaccante può giocare con la chiave fintanto che ha un controllo efficace del server, ma non lo estrae. Questo diminuisce il suo potere di disturbo (ma HSM è costoso).

In pratica, ti assicurerai che il file contenente la chiave privata sia leggibile solo sull'account di sistema che esegue il server ( chown e chmod su sistemi Unix-like, diritti di accesso NTFS su Windows).