Autorizzazioni per i file creati da openssl per il server web https (lighttpd)

Ho creato i seguenti file per il mio server web lighttpd per le connessioni https:

$ ls -al /etc/lighttpd/ssl
drwxr-xr-x 2 root  root  4096 Oct 21 12:51 .
drwxr-xr-x 4 root  root  4096 Oct 20 16:04 ..
-rw-r--r-- 1 http  http  1663 Oct 20 15:49 server.crt
-rw-r--r-- 1 root  root  1062 Oct 20 15:48 server.csr
-rw------- 1 root  root  1704 Oct 20 15:48 server.key
-rw-r----- 1 alarm http  3367 Oct 20 16:02 server.pem
-rw------- 1 root  root  1751 Oct 20 15:48 rootCA.key
-rw-r--r-- 1 root  root  1330 Oct 20 15:48 rootCA.pem
-rw-r--r-- 1 root  root    41 Oct 20 15:49 rootCA.srl

dove server.*sono i miei file server web evidenti e i rootCA.*file sono i miei file di autorità di certificazione (CA) che ho usato per creare il mio certificato di autofirmazione ( https://alexanderzeitler.com/articles/Fixing-Chrome-missing_subjectAltName-selfsigned-cert-openssl/ ). Per poter utilizzare lighttpd con il mio certificato (crt), ho dovuto creare il mio file formattato pem ma facendo:

sudo cat server.crt server.key > server.pemper creare un file in formato pem. Ho installato il mio file rootCA.pem in Chrome (in modo da riconoscere la CA e non lamentarmi del fatto che il sito Web "non è sicuro").

Quindi le mie domande sono

1. le autorizzazioni per i miei file sono OK dal punto di vista della sicurezza o devo cambiare le autorizzazioni del proprietario / gruppo e dei file per qualcos'altro?
2. Che dire delle autorizzazioni della directory / etc / lighttpd / ssl?
3. Dove ho dovuto eseguire il sudo cat server.crt server.key > server.pemcomando sopra aggiungendo my server.keyal file pem, questo non espone la mia chiave privata rendendo quel server.pemfile leggibile da http?

Il mio server.pem deve essere leggibile dal mio server lighttpd poiché l'utente che esegue lighttpd è 'http'.

Questo potrebbe non aver ancora ricevuto alcuna risposta perché è un problema difficile e non esiste un'unica risposta corretta.

L'accesso chiave per i server si traduce in un compromesso tra avvio assistito e non presidiato. È possibile richiedere l'interazione con un amministratore (ad es. Crittografare il file della chiave privata e inserire la passphrase manualmente all'avvio); che protegge la chiave a riposo (su disco) dall'esposizione, ma impedisce l'avvio incustodito. Oppure puoi rendere la chiave a riposo disponibile per il server, consentendo un avvio automatico, ma ciò potenzialmente lo espone agli aggressori.

Quindi l'igiene della chiave a riposo deve riflettere il tuo modello di minaccia. Vale la pena il costo (tempo, inconveniente, ritardo all'avvio) per richiedere l'interazione? Oppure il rischio di divulgazione chiave (la probabilità che ciò accada ti costa) è abbastanza basso da poter consentire l'avvio incustodito?

Supponendo che continui a mantenere disponibile la chiave privata del server per l'avvio automatico (ovvero leggibile dal server senza interazione da parte dell'amministratore), ecco alcune considerazioni:

1. Ottieni la chiave di root lì. Le chiavi CA non devono essere conservate su sistemi esposti al mondo esterno. In questo caso è la tua CA, non una grande pubblica, ma questa è l'igiene delle chiavi PKIX di base.

2. Probabilmente non c'è ulteriore esposizione dall'avere la chiave del server presente in due forme, ma non c'è nemmeno alcun vantaggio. Sbarazzarsi di server.key.

3. La directory potrebbe anche essere di proprietà di root.http e impostata su 750 (root scrivibile, gruppo http leggibile, nessuna autorizzazione mondiale). I vettori di attacco più probabili sono attraverso il server HTTP, ma ce ne sono altri; potrebbe anche scoraggiare alcuni di essi bloccando la lettura / attraversamento del mondo.

Per quanto riguarda la tua ultima domanda: non ho mai usato lighttpd, ma alcuni server supportano un processo di codifica in cui il server legge la chiave all'avvio e quindi rilascia le autorizzazioni in modo da impedirne la lettura in seguito. Ad esempio, il server può avviarsi come root (come deve, su UNIX / Linux, se vuole collegarsi alle porte 80 e 443), quindi legge il file chiave e quindi esegue un setuid su http (o qualsiasi altra cosa). Altri potrebbero avere una disposizione per leggere la chiave da una pipe o simili.

Potrebbe anche essere possibile con lighttpd far leggere la chiave da una copia temporanea che la procedura di avvio elimina dopo l'avvio del server.

La prima linea di difesa, tuttavia, sarebbe quella di assicurarsi che la directory che contiene il file chiave non sia accessibile attraverso nessuno dei webroot e fare del proprio meglio per evitare vulnerabilità di attraversamento del percorso in qualunque server stia servendo. E bloccando il sistema operativo in generale.

Mi piace il libro Bulletproof SSL e TLS di Ivan Ristić , disponibile su feistyduck.com, per consigli sull'utilizzo di SSL / TLS in generale e con HTTPS in particolare. Per i server Web, parla principalmente di Apache, ma gran parte del materiale è ampiamente applicabile.

Spero che questo sia utile.

root: root, chmod 400. E idealmente i file della CA principale non dovrebbero essere ospitati sul tuo server web, altrimenti un compromesso del server compromette anche la tua autorità root.

https://redmine.lighttpd.net/projects/1/wiki/docs_ssl Autorizzazioni Fai attenzione a mantenere privato il tuo file .pem! Lighttpd legge tutti i pemfile all'avvio, prima di abbandonare i privilegi. È quindi meglio rendere il file pem di proprietà di root e leggibile solo da root: $ chown root: root /etc/lighttpd/ssl/example.org.pem $ chmod 400 /etc/lighttpd/ssl/example.org.pem