Documentazione di PostgreSQL 9.0 > Amministrazione del server > Setup e operatività del server > Connessioni TCP/IP sicure con SSL
PrecedenteOpzioni di criptazioneConnessioni TCP/IP sicure con tunnel SSHSuccessivo

17.8. Connessioni TCP/IP sicure con SSL

PostgreSQL™ ha il supporto nativo per l'utilizzo di connessioni SSL per criptare le comunicazioni client/server aumentando la sicurezza. Questo richiede che OpenSSL™ sia installato sia sul client che sul server e che il supporto in PostgreSQL™ sia abilitato al momento della compilazione (si veda Capitolo 15, Installation from Source Code).

Con il supporto SSL compilato, il server PostgreSQL™ può essere avviato con SSL abilitato impostando il parametro ssl a on nel postgresql.conf. Il server ascolterà sia connessioni normali che SSL sulla stessa porta TCP, e negozierà con qualsiasi client che si connette se usa SSL. In modo predefinito, questa è un'opzione del client; si veda Sezione 19.1, «The pg_hba.conf file» per informazioni su come impostare il server per richiedere l'uso di SSL per alcune o tutte le connessioni.

PostgreSQL™ legge il file di configurazione a levello di sistema di OpenSSL™. In modo predefinito, questo file si chiama openssl.cnf e si trova nella directory riportata da openssl version -d. Questo comportamento può essere sovrascritto impostando la variabile d'ambiente OPENSSL_CONF col nome del file di configurazione desiderato.

OpenSSL™ supporta un vasto insieme di algoritmi di cifrazione e autenticazione, di robustezza variabile. Mentre un elenco di cifrazioni può essere specificato nel file di configurazione di OpenSSL™, si possono specificare cifrazioni specifiche da usare dal server database modificando ssl_ciphers in postgresql.conf.

[Nota]

Nota

È possibile avere un'autenticazione senza criptazione usando le cifrazioni NULL-SHA o NULL-MD5. Comunque, un man-in-the-middle potrebbe leggere le comunicazioni tra il client e il server. Inoltre, l'overhead di criptazione è minimale se confrontato all'overhead dell'autenticazione. Per queste ragioni le cifrazioni non sono raccomandate.

Per avviare in modalità SSL, i file server.crt e server.key devono esistere nella directory dei dati del server. Questi file dovrebbero contenere rispettivamente il certificato del server e la chiave privata. Su sistemi Unix, i permessi su server.key non devono permettere qualsiasi accesso al mondo o al gruppo; si faccia questo con il comando chmod 0600 server.key. Se la chiave privata è protetta con una passphrase, il server la chiederà di inserirla e non si avvierà finchè non la si fornisce.

In some cases, the server certificate might be signed by an «intermediate» certificate authority, rather than one that is directly trusted by clients. To use such a certificate, append the certificate of the signing authority to the server.crt file, then its parent authority's certificate, and so on up to a «root» authority that is trusted by the clients. The root certificate should be included in every case where server.crt contains more than one certificate.

17.8.1. Usare certificati del client

Per richiedere al client di fornire un certificato fidato, mettere i certificati delle autorità (CA) fidate nel file root.crt nella directory dei dati, ed impostare il parametro clientcert a 1 nell'appropriata linea/e hostssl in pg_hba.conf. Quindi sarà richiesto un certificato dal client durante l'avvio della connessione SSL. (Si veda Sezione 31.17, «SSL Support» per una descrizione si come impostare i certificati sul client). Il server verificherà che il certificato del client sia firmato da una delle autorità certificato fidate. Le voci di Certificate Revocation List (CRL) sono controllate anche se il file root.crl esiste. (Si veda http://h71000.www7.hp.com/DOC/83final/BA554_90007/ch04s02.html per diagrammi che mostrano l'utilizzo di certificati SSL).

L'opzione clientcert in pg_hba.conf è disponibile per tutti i metodi di autenticazione, ma solo per le righe specificate come hostssl. Quando clientcert non è specificato o è impostato a 0, il server verificherà comunque i certificati client presentati con root.crt se quel file esiste - ma non esigerà che un certificato di client sia presente.

Si noti che root.crt elenca le CA si livello superiore che sono considerate fidate per firmare i certificati del client. In principio non avrà bisogno dell'elenco delle CA che sono state firmate dal certificato del server, benchè in molti casi quella CA sarebbe fidata anche per i certificati client.

Se si stanno impostando i certificati del client, si può desidare usare il metodo di autenticazione cert, in modo che i certificati controllino l'autenticazione dell'utente così come prevedano la sicurezza della connessione. Si veda Sezione 19.3.9, «Certificate authentication» per dettagli.

17.8.2. Utilizzo del file server SSL

I file server.key, server.crt, root.crt e root.crl sono esaminati solo durante l'avvio del server; così si deve riavviare il server perchè i cambiamenti in questi file abbiano effetto.

Tabella 17.3. Utilizzo del file server SSL

FileContenutiEffetto
server.crtcertificato del servermandato al client per indicare l'identità del server
server.keychiave privata del serverprova che il certificato del server sia stato mandato dal proprietario; non indica che il proprietario del certificato è attendibile
root.crtAutorità di certificato fidatecontrolla che il certificato del client sia firmato da un'autorità di certificato fidata
root.crlcertificati revocati da autorità di certificatoil certificato del client non deve essere in questo elenco

17.8.3. Creare un certificato auto-firmato

Per creare un certificato auto-firmato per il server, usare il seguente comando OpenSSL™:

openssl req -new -text -out server.req

Fornire le informazioni chieste da openssl. Assicurarsi di inserire il nome del host locale come «Common Name»; la password challenge può essere lasciata vuota. Il programma genererà una chiave protetta da passphrase; essa non accetterà una passphrase lunga meno di 4 caratteri. Per rimuovere la passphrase (si deve fare se si vuole l'avvio automatico del server), eseguire i comandi:

openssl rsa -in privkey.pem -out server.key
rm privkey.pem

Inserire la vecchia passphrase per sbloccare la chiave esistente. Adesso fare:

openssl req -x509 -in server.req -text -key server.key -out server.crt

per trasformare il certificato in un certificato auto-firmato e per copiare la chiave e il certificato dove il server li cercherà. Infine fare:

chmod og-rwx server.key

dato che il server rifiuterà il file se i suoi permessi sono più permissivi di così. Per maggiori dettagli si come creare la chiave privata e il certificato per il proprio server, fare riferimento alla documentazione OpenSSL™.

Un certificato auto-firmato può essere usato per test, ma un certificato firmato da un'autorità certificata (CA) (o una delle CA globali o una locale) dovrebbe essere usata in produzione così che i client possano verificare l'identità del server. Se tutti i client sono locali all'organizzazione, si raccomanda di usare una CA locale.

Documentazione di PostgreSQL 9.0 > Amministrazione del server > Setup e operatività del server > Connessioni TCP/IP sicure con SSL
PrecedenteOpzioni di criptazioneConnessioni TCP/IP sicure con tunnel SSHSuccessivo