A volte, per ragioni di test o per uso domestico (configurazione di una vpn con openvpn per es. o di un server stunnel), mi càpita di avere bisogno di un certificato digitale.

Finché il certificato è self-signed, l'operazione richiede veramente pochissimo sforzo. Ma quando devo far riferimento ad una CA interna, la questione si complica. Proverò adesso a descrivere le operazioni che compio quando devo creare:

1. CA + certificati server + certificati client
2. CA + Intermediate CA + certificati server + certificati client

Indice

1. Cos’è un certificato digitale
2. OpenSSL
3. Struttura del “laboratorio”
4. Caso 1: Creazione delle CA e dei certificati client e server
   1. Creazione della CA per i certificati server
      1. Configurazione CA server
      2. Creazione CA server
   2. Creazione del certificato server
      1. Configurazione csr server
      2. Creazione csr server
      3. Configurazione crt server
      4. Creazione crt server
   3. Creazione della CA per i certificati client
      1. Configurazione CA client
      2. Creazione CA client
   4. Creazione del certificato client
      1. Configurazione csr client
      2. Creazione csr client
      3. Configurazione crt client
      4. Creazione crt client
   5. Riassunto
5. Caso 2: Creazione di CA, Intermediate CA e dei certificati client e server

Cos'è un certificato digitale

I certificati digitali sono degli oggetti utilizzati nelle comunicazioni per fornire un canale sicuro su un mezzo intrinsecamente insicuro (internet) e vengono costruiti secondo lo standard X.509, un protocollo che definisce il formato dei certificati e l'insieme degli elementi di contorno come elementi autoritativi, elenchi di revoca e modalità di convalida.

Un certificato digitale è un oggetto crittografico costituito da una parte pubblica (chiave pubblica + informazioni personali del possessore del certificato) e una parte privata (la chiave privata).

La parte pubblica viene firmata digitalmente per garantire autenticazione e integrità e può essere eseguita:

• da se stesso (i cosiddetti certificati self-signed, una sorta di autocertificazione)
• da una CA, un'autorità superiore che garantisce che le informazioni del certificato sono di chi dice di essere.

OpenSSL

Per la costruzione di un certificato digitale, uso OpenSSL che è sia una libreria crittografica che implementa i protocolli TLS e SSL (deprecato), sia un toolkit professionale per l'utilizzo di funzionalità di crittografia.,

OpenSSL ha una cli molto complessa che può essere in parte configurata, soprattutto nella parte di definizione dei certificati, da un file di configurazione, openssl.cnf, un file .ini diviso in sezioni, contenenti una lista di coppie (chiave,valore).

Nel proseguio, invece che usare un unico file omnicomprensivo, ne verrà usato solo un frammento in base al contesto (certificato o csr di ca, intermediate, server o client). Ho trovato questo approccio più flessibile e più chiaro.

Negli esempi, userò questi file che avranno dei nomi “parlanti” in base a ciò che dovrò definire. Non mi dilungherò nella spiegazione delle singole opzioni perché:

1. non le conosco tutte
2. approfondire ogni singola direttiva di openssl.cnf richiederebbe un blog dedicato.

Si potrebbe ancora dissertare sulle versioni di openssl da usare, sui suoi fork ma non è questo il momento, forse in altri post (che sono in fase di preparazione.)

Struttura del “laboratorio”

Data la destinazione dei certificati (test o uso strettamente interno), i certificati vengono generati nella maniera più compatta possibile.

• Per le root CA, gli unici certificati self-signed, viene generato il csr e il crt in un'unica soluzione.
• Le intermediate CA vengono generate, come ogni altro certificato server / client, producendo prima un csr che viene firmato dalla root CA per produrre il crt.
• Anche i certificati server e client, come detto, vengono generati come l'intermediate CA, producendo prima il csr che verrà firmato da una CA.
• Ogni fase (per “fase” intendo produzione di un csr o di un crt) sarà “guidata” dal frammento di file di configurazione avente quel famoso nome “parlante”.
• Prenderò in considerazione due casistiche. In una i certificati server e client verranno validati da una root CA. Nell'altro, la root CA delegherà ad una intermediate CA la validazione di certificati server / client.
• Nella prima casistica, per rendere la soluzione più generica, supporrò di avere una CA distinta per i certificati client e una per i server.

⚠️ ⚠️ ⚠️ SUPER WARNING⚠️ ⚠️ ⚠️ Non è questo il modo formalmente corretto per la creazione di un certificato, almeno non quello da usare per un ambiente di produzione.

Non farò nessuna assunzione sulle modalità di cifratura, né sul tuning di openssl.

Il mio obiettivo qui è: voglio ottenere un certificato nella maniera più rapida possibile (e per rapido intendo senza troppi sbattimenti nelle configurazioni perché, alla fine, tutto può essere scriptabile e quindi veloce).

I file di configurazione saranno composti da massimo due sezioni contenenti le extensions X.509 necessarie per la creazione dei certificati. Il resto dei parametri sarà passato nella cli piuttosto che nel file di configurazione.

Mi rendo conto che per una buona comprensione occorrerebbe avere un po' di confidenza con:

• i concetti di cifratura asimmetrica e di certificato digitale
• configurazione e utilizzo base di openssl
• conoscenza di openssl.cnf e extensions X.509

Caso 1: Creazione delle CA e dei certificati client e server

La creazione della CA consisterà in un certificato self-signed ottenuto con un unico comando. Per i certificati invece verrà prodotto prima il csr che poi sarà firmato dalla CA al fine di ottenere il certificato vero e proprio.

Piccola nota: gli attributi basicConstraints, nsCertType, extendedKeyUsage saranno determinanti per battezzare una CA piuttosto che un certificato client/server

Creazione della CA per i certificati server

La creazione del certificato sarà one-shot.

Configurazione CA server

Il file di configurazione sarà ca_cert.cnf

###############
# ca_cert.cnf #
###############
[ v3_ca ]
basicConstraints        = critical,CA:true
keyUsage                = critical, cRLSign, keyCertSign
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
nsCertType              = sslCA
nsComment               = "OpenSSL Generated CA Root Certificate"

Creazione CA server

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CA SERVER ###
openssl req \
-config $CONF_CERT/ca_cert.cnf \
-extensions v3_ca \ 
-x509 \
-days 1825 -sha512 \
-nodes -newkey rsa:4096 \
-subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" \
-keyout $OUTPUT_CERT/ca_server.key \
-out $OUTPUT_CERT/ca_server.crt

• openssl req : crea un csr
• -config $CONFCERT/cacert.cnf : path del file di configurazione
• -extensions v3_ca : sezione del file da prendere come riferimento (in questo caso per le sole extensions X.509)
• -x509 : fa in modo che l'output sia direttamente un certificato piuttosto che un csr
• -days 1825 -sha512 : fissa la scadenza a 5 anni e setta sha512 come algoritmo di digest.
• -nodes -newkey rsa:4096 : crea una chiave rsa non cifrata a 4096 bit
• -subj “/C=IT/ST=Roma”/CN=GlobalSign Test RootCA” : distinguished_name passato da cli
• -keyout $OUTPUTCERT/caserver.key : path di destinazione della chiave
• -out $OUTPUTCERT/caserver.crt : path di destinazione del certificato CA.

Creazione certificato server

Verrà generato prima il csr (certificate signing request) che sarà firmato dalla CA per generare il certificato effettivo.

Configurazione csr server

Il file di configurazione per il csr sarà server_req.cnf, diviso in 3 sezioni.

La prima, req, è quella usata da openssl req (in assenza della quale verrà sollevata un'eccezione) e contiene solo il rimando alle extensions X.509 da usare.

Come prima, le extensions X.509 (v3serverreq) definiscono i giusti attributi per questo tipo di certificato.

N.B. L'ultima sezione è quella degli alternatives_name, la cui assenza non comporta problemi nella creazione del certificato ma potrebbe far fallire i check effettuati da alcuni prodotti, ad es. i webserver che pur riconoscendo nel Common Name il nome del servizio (es. la url) scatenano ugualmente l'eccezione BADCERTDOMAIN

##################
# server_req.cnf #
##################
[ req ]
req_extensions = v3_server_req

[ v3_server_req ]
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = serverAuth
nsCertType              = server
nsComment               = "OpenSSL Generated Server Request Certificate"
subjectAltName          = @alt_names

[ alt_names ]
DNS.1 = server.web.local

Creazione csr server

La sintassi è sostanzialmente uguale a quanto visto per la CA con la sola eccezione del parametro -x509 (che creava un crt invece che un csr). Il csr creerà il certificato e la coppia di chiavi pubblica e privata.

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CSR Server ###
openssl req \
-config $CONF_CERT/server_req.cnf \
-nodes -newkey rsa:2048 \
-subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" \
-keyout $OUTPUT_CERT/server.key \
-out $OUTPUT_CERT/server.csr

• openssl req : crea un csr
• -config $CONFCERT/serverreq.cnf : path del file di configurazione
• -nodes -newkey rsa:2048 : crea una chiave rsa non cifrata a 2048 bit
• -subj “/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local” : distinguished_name passato da cli
• -keyout $OUTPUT_CERT/server.key : path di destinazione della chiave
• -out $OUTPUT_CERT/server.csr : path di destinazione del csr

Configurazione crt server

A differenza di prima, non ho un file di configurazioni vero e proprio. Non usando il file generico openssl.cnf, l'unico file che si può invocare dal comando openssl x509 è un elenco di attributi che il certificato dovrà possedere e questo ci è sufficiente per creare certificati client o server.

Il file di configurazione per il crt sarà server_cert.cnf.

###################
# server_cert.cnf #
###################
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = serverAuth
nsCertType              = server
nsComment               = "OpenSSL Generated Server Certificate"
subjectAltName          = @alt_names

[ alt_names ]
DNS.1 = server.web.local

Creazione crt server

Di fatto, le uniche operazione che compio sono quelle di firmare con la CA il certificato, di fissare una scadenza e l'algoritmo di digest (altrimenti verrà applicato un default). Il resto, lo eredito dal csr (potrei sovrascrivere alcune cose come il subj) o dalle estensioni presenti nel file.

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CRT Server ###
openssl x509 \
-extfile $CONF_CERT/server_cert.cnf \
-req -in $OUTPUT_CERT/server.csr \
-days 365 -sha384 \
-CA $OUTPUT_CERT/ca_server.crt \
-CAkey $OUTPUT_CERT/ca_server.key \
-CAcreateserial \
-out $OUTPUT_CERT/server.crt

• openssl x509 : crea un certificato x509
• -extfile $CONFCERT/servercert.cnf : path del file di estensioni
• -req : acquisizione del file csr da far firmare
• -CA $OUTPUTCERT/caserver.crt : acquisizione del certificato della CA
• -CAkey $OUTPUTCERT/caserver.key : acquisizione della chiave privata della CA che firmerà il certificato
• -CAcreateserial : crea un seriale randomico per il certificato da creare. Normalmente una CA crea dei seriali progressivi memorizzandoli in un database interno.
• -days 365 -sha384 : fissa ad un anno la scadenza del certificato e usa sha384 come algoritmo di digest
• -out $OUTPUT_CERT/server.crt : path di destinazione del certificato server.

Creazione della CA per i certificati client

È praticamente la stessa cosa. La differenza è solo formale visto che, tecnicamente, i comandi che andrò ad eseguire saranno praticamente gli stessi (l'unica differenza di rilievo riguarderà i certificati client a cui corrisponderanno estensioni X.509 leggermente differenti)

Configurazione della CA client

È lo stesso file visto prima.

Creazione della CA client

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CA Client ###
openssl req \
-config $CONF_CERT/ca_cert.cnf \
-extensions v3_ca \ 
-x509 \
-days 1825 -sha512 \
-nodes -newkey rsa:4096 \
-subj "/C=IT/ST=Italia/CN=Digicert Test RootCA" \
-keyout $OUTPUT_CERT/ca_client.key \
-out $OUTPUT_CERT/ca_client.crt

C'è poco da dire. L'unica variazione degna di nota è il subj, per il resto è identico alla creazione della ca server.

Creazione certificato client

Come fatto per il server, verrà generato prima il csr che sarà firmato dalla CA per generare il certificato effettivo.

Configurazione csr client

Come per i certificati server, extendedKeyUsage e nsCertType stabiliscono come viene battezzato il certificato.

##################
# client_req.cnf #
##################
[ req ]
req_extensions = v3_client_req

[ v3_client_req ]
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = clientAuth
nsCertType              = client
nsComment               = "OpenSSL Generated Client Request Certificate"

Creazione csr client

Nel csr, viene creata la chiave, rsa a 2048 bit, e viene settato il subj.

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CSR Client ###
openssl req \
-config $CONF_CERT/client_req.cnf \
-nodes -newkey rsa:2048 \
-subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" \
-keyout $OUTPUT_CERT/johndoe.key \
-out $OUTPUT_CERT/johndoe.csr

Configurazione crt client

Il file di configurazione raccoglie solo le estensioni con cui il certificato viene istanziato

###################
# client_cert.cnf #
###################
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = clientAuth
nsCertType              = client
nsComment               = "OpenSSL Generated Client Certificate"

Creazione crt client

Come per il certificato server, il certificato client verrà creato in seguito alla firma del csr dalla CA e aver settato scadenza a algoritmo di digest (altrimenti verrà applicato un default). Essendo un certificato client, viene mostrato anche come costruire un p12, utile nei casi in cui l'autenticazione del client viene fatta dal browser.

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CRT Client ###
openssl x509 \
-extfile $CONF_CERT/client_cert.cnf \
-req -in $OUTPUT_CERT/johndoe.csr \
-days 365 -sha384 \
-CA $OUTPUT_CERT/ca_client.crt \
-CAkey $OUTPUT_CERT/ca_client.key \
-CAcreateserial \
-out $OUTPUT_CERT/johndoe.crt

### Creazione p12 ###
openssl pkcs12 -export -inkey $OUTPUT_CERT/johndoe.key -in $OUTPUT_CERT/johndoe.crt -out $OUTPUT_CERT/johndoe.p12

Riassunto

Di seguito, la raccolta di quanto visto finora, allo scopo di rendere un colpo d'occhio immediato e di dare una base per rendere scriptabile il processo che già così, tenendo presente i file di configurazione così composti e raccogliendo in uno script i comandi proposti, crea 2 CA, un certificato server e uno client (a meno dei subj di fantasia)

File di configurazione:

###############
# ca_cert.cnf #
###############
[ v3_ca ]
basicConstraints        = critical,CA:true
keyUsage                = critical, cRLSign, keyCertSign
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
nsCertType              = sslCA
nsComment               = "OpenSSL Generated CA Root Certificate"

##################
# server_req.cnf #
##################
[ req ]
req_extensions = v3_server_req
 
[ v3_server_req ]
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = serverAuth
nsCertType              = server
nsComment               = "OpenSSL Generated Server Request Certificate"
subjectAltName          = @alt_names

[ alt_names ]
DNS.1 = server.web.local

###################
# server_cert.cnf #
###################
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = serverAuth
nsCertType              = server
nsComment               = "OpenSSL Generated Server Certificate"
subjectAltName          = @alt_names
 
[ alt_names ]
DNS.1 = server.web.local

##################
# client_req.cnf #
##################
[ req ]
req_extensions = v3_client_req
 
[ v3_client_req ]
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = clientAuth
nsCertType              = client
nsComment               = "OpenSSL Generated Client Request Certificate"

###################
# client_cert.cnf #
###################
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = clientAuth
nsCertType              = client
nsComment               = "OpenSSL Generated Client Certificate"

Script di creazione certificati:

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

#############
# CA SERVER #
#############
openssl req -config $CONF_CERT/ca_cert.cnf -extensions v3_ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" -keyout $OUTPUT_CERT/ca_server.key -out $OUTPUT_CERT/ca_server.crt

##########
# Server #
##########
# csr
openssl req -config $CONF_CERT/server_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" -keyout $OUTPUT_CERT/server.key -out $OUTPUT_CERT/server.csr
# crt
openssl x509 -extfile $CONF_CERT/server_cert.cnf 
-req -in $OUTPUT_CERT/server.csr -days 365 -sha384 -CA $OUTPUT_CERT/ca_server.crt -CAkey $OUTPUT_CERT/ca_server.key -CAcreateserial -out $OUTPUT_CERT/server.crt

#############
# CA Client #
#############
openssl req -config $CONF_CERT/ca_cert.cnf -extensions v3_ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=Digicert Test RootCA" -keyout $OUTPUT_CERT/ca_client.key -out $OUTPUT_CERT/ca_client.crt

##########
# Client #
##########
# csr
openssl req -config $CONF_CERT/client_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" -keyout $OUTPUT_CERT/johndoe.key -out $OUTPUT_CERT/johndoe.csr
# crt 
openssl x509 -extfile $CONF_CERT/client_cert.cnf -req -in $OUTPUT_CERT/johndoe.csr -days 365 -sha384 -CA $OUTPUT_CERT/ca_client.crt -CAkey $OUTPUT_CERT/ca_client.key -CAcreateserial -out $OUTPUT_CERT/johndoe.crt
# p12
openssl pkcs12 -export -inkey $OUTPUT_CERT/johndoe.key -in $OUTPUT_CERT/johndoe.crt -out $OUTPUT_CERT/johndoe.p12

Caso 2. Creazione di CA, Intermediate CA e dei certificati client e server

Gli esempi che seguiranno saranno presentati sullo stile del riassunto perché fondamentalmente molto simili al caso 1. Si aggiunge un punto di intermediazione in più dato dal fatto che la CA delega ad una CA “subalterna” l'incarico di verificare le paternità di coloro i quali richiedono certificati.

Quindi avremo:

• una root CA, certificato self-signed
• un'Intermediate CA, validata dalla root CA (csr + crt firmato dalla root CA) n certificati client/server validati dall'Intermediate CA (csr + crt firmato dall'Intermediate CA)

Creazione certificati

OUTPUT_CERT=$HOME/stunnel/build-cert
CONF_CERT=$HOME/stunnel/conf.d

###########
# Root CA #
###########
openssl req -config $CONF_CERT/ca_cert.cnf -extensions v3_ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" -keyout $OUTPUT_CERT/rootca.key -out $OUTPUT_CERT/rootca.crt

###################
# INTERMEDIATE CA #
###################
# csr
openssl req -config $CONF_CERT/intermediate_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/CN=GlobalSign Test IntermediateCA" -keyout $OUTPUT_CERT/intermediate.key -out $OUTPUT_CERT/intermediate.csr
# crt
openssl x509 -extfile $CONF_CERT/intermediate_cert.cnf -req -in $OUTPUT_CERT/intermediate.csr -days 365 -sha384 -CA $OUTPUT_CERT/rootca.crt -CAkey $OUTPUT_CERT/rootca.key -CAcreateserial -out $OUTPUT_CERT/intermediate.crt

##########
# Server #
##########
# csr
openssl req -config $CONF_CERT/server_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" -keyout $OUTPUT_CERT/server.key -out $OUTPUT_CERT/server.csr
# crt
openssl x509 -extfile $CONF_CERT/server_cert.cnf 
-req -in $OUTPUT_CERT/server.csr -CA $OUTPUT_CERT/intermediate.crt -CAkey $OUTPUT_CERT/intermediate.key -CAcreateserial -days 365 -sha384 -out $OUTPUT_CERT/server.crt

##########
# Client #
##########
# csr
openssl req -config $CONF_CERT/client_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" -keyout $OUTPUT_CERT/johndoe.key -out $OUTPUT_CERT/johndoe.csr
# crt
openssl x509 -extfile $CONF_CERT/client_cert.cnf -req -in $OUTPUT_CERT/johndoe.csr -days 365 -sha384 -CA $OUTPUT_CERT/intermediate.crt -CAkey $OUTPUT_CERT/intermediate.key -CAcreateserial -out $OUTPUT_CERT/johndoe.crt
# p12
openssl pkcs12 -export -inkey $OUTPUT_CERT/johndoe.key -in $OUTPUT_CERT/legs.crt -out $OUTPUT_CERT/johndoe.p12

#DigitalCertificate #x509 #csr #openssl #ca #cryptography #AsymmetricEncryption #SymmetricEncryption #DigitalSignature

Introduzione

Da documentazione, Stunnel agisce come un proxy per aggiungere crittografia TLS a server e/o a client già esistenti.

Risulta quindi molto comodo quando si vuole aggiungere, attraverso un tunnel TLS, quella crittografia che manca alle nostre applicazioni per rendere le comunicazioni più sicure. Come in ssh, è possibile “tunnellizzare” solo connessioni TCP.

Di stunnel esaminerò in particolare la fase di autenticazione attraverso certificato o PSK.

Gli scenari possibili, in base alle combinazioni, sono tre:

• client tls – server in chiaro
• client in chiaro – server tls
• client e server in chiaro

Nel primo caso, occorre configurare stunnel in server mode, definendo un receiver ssl, a cui il client potrà connettersi. Scenario 1: stunnel server

Nel secondo caso, occorre configurare stunnel in client mode, definendo un sender ssl che il client userà per connettersi al server Scenario 2: stunnel client

Nel terzo caso, occorre configurare uno stunnel client e uno server Scenario 3: stunnel client e server

Come ulteriore evoluzione per quel che riguarda le tratte in chiaro (e non solo) di client-stunnel client, stunnel client-stunnel server, stunnel server-server, sarebbe buona norma limitarne l’accesso con un firewall. Stunnel e firewall

Se invece stunnel fosse locale (installato direttamente sul client e/o sul server), la richiesta del client o il listener del servizio, avverrebbero sull’interfaccia di loopback. Altrimenti, in assenza di firewall, sarebbe consigliabile accertare che la rete di collegamento fra i proxy stunnel e i rispettivi client/server, sia almeno di tipo “trusted”.

Stunnel consente un certo tuning sulla parte tls, potendo discriminare fra le cipher suites da abilitare, specificare comandi o configurazioni specifiche per openssl. Quando si deve incapsulare una connessione in chiaro in un tunnel ssl bisogna tenere presente gli scenari menzionati prima.

Convenzioni

• Per non perdere generalità, negli esempi che seguiranno, immaginiamo che stunnel non sia locale (anche se spesso lo è).
  • se stunnel in client mode è locale ⇒ accept avverrà sull’interfaccia di loopback, da dove avviene effettivamente la richiesta
  • se stunnel in server mode è locale ⇒ connect avverrà sull’interfaccia di loopback, dove viene erogato effettivamente il servizio
• Non faremo assunzioni sulla creazione dei certificati. Possono anche essere self-signed.

Configurazione stunnel

Verranno mostrate le configurazioni relative agli scenari mostrati nel modo più semplice possibile.

• accept: host e porta che ricevono la richiesta
• connect: host e porta a cui girare l’accept
• cert: normalmente conterrebbe il certificato pubblico che stunnel espone per autenticarsi (la parte privata viene specificata con key). Può però anche essere costituito da tutta i certificati della chain fino alla root CA, in formato pem o p12, iniziando dalla chiave privata, proseguendo con la chiave pubblica, fino a tutte le CA della chain.
• key: chiave privata del certificato
• client: stabilisce se stunnel funzioni in server mode oppure no

Primo scenario

Nel primo caso, una configurazione minimale lato server, ha bisogno:

1. host e porta dello stunnel server che riceve il traffico cifrato
2. host e porta del server su cui girare il traffico in chiaro
3. certificato pubblico e chiave privata necessari per la cifratura

Stunnel Server:

[myService]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
cert = /server_crt.pem<br>
key = /server_key.pem

Secondo scenario

Nel secondo caso, una configurazione minimale lato client, ha bisogno:

1. host e porta dello stunnel client da cui partirà la richiesta
2. host e porta del server da cui stunnel client avvierà la sessione tls

Stunnel Client:

[myService]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_server:port_server

Terzo Scenario

Il terzo caso, è una fusione dei primi due. Sono gli stunnel a gestire il grosso della comunicazione. E nei casi in cui lo stunnel viene installato sulle macchine di servizio, client e server reali usano solo l’interfaccia di loopback.

Una configurazione minimale per il client ha bisogno di:

1. host e porta dello stunnel client da cui partirà la richiesta
2. host e porta del server da cui stunnel client avvierà la sessione tls

Stunnel Client:

[myService]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server

Una configurazione minimale per il server ha bisogno:

1. host e porta dello stunnel server che riceve il traffico cifrato
2. host e porta del server su cui girare il traffico in chiaro certificato pubblicato e chiave privata necessari per la cifratura

Stunnel Server:

[myService]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
cert = /server_crt.pem
key = /server_key.pem

Piccola nota: se client e/o server dovessero supportare chiavi PSK, si potrebbe usare PSK in luogo dei certificati. Ci ritornerò più avanti.

Autenticazione dei client

Le impostazioni viste finora, mostrano come incapsulare un traffico in chiaro all’interno di un tunnel tls e si basano sulla sola autenticazione lato server.

Per migliorare la configurazione possiamo ricorrere alla mutua autenticazione facendo in modo che anche i client si autentichino.

Una mutua autenticazione, con tutte le verifiche del caso, aumenta il grado di sicurezza comunicazione TLS ed è un efficace deterrente contro eventuali attacchi MITM. L’autenticazione sul client si può ottenere sempre con i certificati oppure, più semplicemente, con chiavi PSK.

Autenticazione dei client con certificato

Ad una configurazione minimale per una mutua autenticazione, lato server, si richiede che i client esibiscano il certificato e i client (che sia stunnel in client mode, un browser o qualunque altra cosa) dovranno essere in grado di esibire i certificati nel momento in cui il server li richiederà.

Su stunnel server, alle configurazioni viste in precedenza, si aggiunge requireCert impostato a yes, che richiede ai client l’esibizione di un certificato. Se, durante l’handshake TLS, il client non esibisce un certificato, l’handshake fallisce e la connessione viene rifiutata.

Stunnel Server:

[myService]
…
requireCert = yes
…

È sufficiente questo se i client possono manipolare i propri certificati. Altrimenti, se c’è uno stunnel client che intermedia le richieste dei client effettivi, si deve aggiungere alla sua configurazione la chiave e il certificato del client

Stunnel Client:

[myService]
…
cert = /server_crt.pem
key = /server_key.pem
…

Autenticazione dei client con PSK

Per l’autenticazione PSK bisogna disporre della lista di utenti abilitati con relative chiavi esadecimali di almeno 16 bytes (ossia almeno 32 caratteri esadecimali visto che con un byte si rappresentano due esadecimali).

La creazione di una chiave esadecimale può essere fatta velocemente con openssl. Supponiamo di creare due utenze per Frodo e Gandalf con chiavi da 20 e 42 bytes.

echo -e "frodo:"$(openssl rand -hex 20) > frodo_psk.txt
echo -e "gandalf:"$(openssl rand -hex 42) > gandalf_psk.txt

Tutte le identità dovranno confluire nel file che, nella configurazione stunnel, sarà indicato da PSKsecrets. Ad es:

cat frodo_psk.txt gandalf_psk.txt > psksecrets.txt
…
frodo:84196825fab3389624dcc83eb61189e5b21099fe<br>gandalf:5daf128419855993a2d95ba0a337c51b3f373df88e594441f2979eba6461f25676f1f825b0c76df392f2
…

E, come detto, nella configurazione dello stunnel server dovrò indicare il file delle identità:

Stunnel Server

[myServer]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
PSKsecrets = <path_identity_file>/psksecrets.txt

Se il client supporta PSK, dovrà fornire identità e password. Ad es. facendo un test con openssl:

openssl s_client -port <porta> -psk_identity frodo -psk 84196825fab3389624dcc83eb61189e5b21099fe -tls1_2 -connect <host>

Altrimenti si configura stunnel client indicando sia l’identità, sia il file individuate da PSKsecrets.

Stunnel Client

[myClient]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server
PSKidentity = frodo
PSKsecrets = <path_identity_file>/psksecrets.txt

In alternativa, per non far viaggiare il file delle identità fra tutti i client, possiamo sfruttare a nostro vantaggio il default delle identità.

In assenza della direttiva PSKidentity, viene assunta come identità di default la prima riga del file indicato da PSKSecrets. Basta quindi creare un file con la sola identità che mi occorre, ad es. frodo_psk.txt

frodo:84196825fab3389624dcc83eb61189e5b21099fe

e indicare quello in PSKSecrets. La configurazione che segue è equivalente alla precedente.

Stunnel Client

[myClient]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server
PSKsecrets = <path_identity_file>/frodo_psk.txt

Ulteriori considerazioni di sicurezza

Autenticazione con certificato

La richiesta di autenticazione dei client mediante certificato è una buona misura preventiva ma può essere resa migliore.

Nelle configurazioni viste finora, stunnel server autorizza l’accesso al servizio solo se il client si presenta con un certificato ma non c’è nulla che vincoli il certificato al servizio. In altre parole, un client in possesso di un qualunque certificato, può accedere alla risorsa.

È possibile rafforzare il trusting fra le parti facendo in modo che stunnel autorizzi solo alcuni certificati invece che qualunque. Questo tipo di controllo può essere fatto sia su stunnel sia in client mode che in server mode.

• verifyChain = yes | no
• checkEmail = email del certificato
• checkHost = CN del certificato
• checkIP = IP del peer che presenta il certificato
• verifyPeer = yes | no
• CApath = < path CA >
• CAfile = < file pem contenente la fullchain del certificato presentato a stunnel >

verifyChain Impone che si possa verificare la fullchain del certificato presentato. Se uno degli issuer non viene trovato, la connessione fallisce. La fullchain viene indicata attraverso CAfile o CApath.

CAfile È il file contenente le CA con cui stunnel valida i certificati che gli vengono presentati. Se stunnel è in server mode, sarà la fullchain relativa ai client. Altrimenti sarà la fullchain relativa al server.

CApath È il path in cui si trovano le CA con cui stunnel valida i certificati che gli vengono presentati. Se lo stunnel è in server mode, sarà la fullchain realtiva ai client. Altrimenti sarà la fullchain relativa al server.

verifyPeer Se con CAfile e CApath si verifica la fullchain dei certificati presentati a stunnel, con verifyPeer = yes si verifica che questi certificati siano presenti anche nel suo keystore (CAfile o CApath). Permette di “legare” a stunnel i certificati che dovrà validare.

checkEmail, checkHost, checkIP Come per verifyPeer, sono direttive che permettono di stringere il legame fra il certificato che viene presentato e stunnel. Verifica che l’email, il CN o l’IP del certificato che viene presentato corrispondano a quelli presenti nella configurazione. In una configurazione lato server posso avere molteplici occorrenze di questi due campi relative ad altrettanti certificati. Il caso in cui ad es. si debbano autenticare n client.

Se i certificati sono self-signed, verifyChain perde di significato (coinciderebbe con verifyPeer). La possibilità di generare i certificati attraverso una CA, anche interna, renderebbe il processo più strutturato anche se più complesso (si dovrà trovare un modo per distribuire la CA, se interna). Si tratta di trovare il giusto compromesso fra ampiezza del servizio (quanti utenti coinvolge?) e complessità richiesta.

Se si tratta di realizzare un canale sicuro fra due apparati per una comunicazione server-2-server, vanno bene anche i certificati self-signed o un’autenticazione PSK. Altrimenti, soprattutto nel caso in cui l’autenticazione dei client è una fase critica, conviene valutare l’uso di una CA e una validazione il più possibile restrittiva sui client e sul server.

Autenticazione PSK

A differenza dell’autenticazione con certificato, l’autenticazione con PSK non prevede enhancement di sicurezza ulteriori a meno di specificare opportuni algoritmi di cifratura (cfr. paragrafo successivo).

Cifratura

Come sempre succede, negli scenari di cifratura asimmetrica orientatia alla connessione, l’autenticazione, per quanto possa essere accurata, costituisce solo uno degli aspetti di cui tenere conto nella fase di messa in sicurezza del servizio.

Avere un’autenticazione con certificato generato con tutti i crismi da una CA, è certamente una gran cosa ma mette in sicurezza solo l’aspetto dell’autenticazione, per l’appunto.

l transito dei dati è affidato alle suite di cifratura supportati da openssl e, volendo lavorare di fino, bisognerebbe stringere anche su quelli.

Altrimenti, paradossalmente, si avrà un’autenticazione robustissima ma con algoritmi colabrodo di cifratura dei dati che, ad attaccanti ben motivati, lascerebbero delle porte spalancate per sferrare attacchi MITM per intercettare direttamente i dati, piuttosto che provare il furto di identità.

Ad ogni modo, il default, per ragioni di compatibilità legacy, dei parametri di cifratura (da settare eventualmente su client e sul server) è il seguente:

ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK
ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

dove ciphers raggruppa le suite di cifratura relativi a TLS1.2 in giù e ciphersuites riguarda invece TLS1.3.

Configurazione servizio

Ulteriori restrizioni possono essere aggiunte a livelllo di sistema:

1. regolando i bit di setuid e setgid se stunnel gira come root
2. delimitando l’esecuzione del processo in una gabbia chroot
3. disabilitando le regonetiation (se supportato dalla versione di openssl in uso) che mitiga in parte attacchi dos di tipo CPU-exhaustion
4. ecc..

Caso reale: tunnelizzare Transmission.

Transmission è un client bittorrent che può essere controllato da remoto via rpc attraverso un’interfaccia web o altri client.

Transmission, nelle sue varie declinazioni, non incapsula il traffico rpc in una connessione tls.

Se si vuole che il dato in transito sia cifrato e che la connessione sia autenticata, si può ricorrere:

1. ad un tunnel ssh;
2. all’intermediazione di un webserver come apache o nginx ;
3. ad uno stunnel server

Sugli ultimi due punti si può configurare una mutua autenticazione con certificato (complessa e articolata e, per tanti client, ha un impatto significativo). Scegliamo il 3° caso.

Esposizione dell’interfaccia web

Scenario: abbiamo una macchina (il nostro serverino di fiducia o un nas) con transmission a bordo, presumibilmente dietro un firewall che natta il suo indirizzo privato (192.168.70.15).

Esposizione transmission attraverso stunnel server

Obiettivo: Vogliamo poter raggiungere transmission e vogliamo che i client autentichino la loro connessione prima di accedere al servizio. In base allo scenario, sappiamo che dovremmo configurare un port forwarding dall’AP fino allo stunnel server. Il server transmission rimarrà confinato nella nostra rete locale.

Utilizzo di un client esterno

Supponiamo di utilizzare diversi client: il browser, transmission-remote-gtk o transmission-remote-gui (transgui), tremotesf (mobile).

La prima cosa da fare è configurare un port forwarding sul nostro AP

Rule₁: 9091 ⇒ 192.168.70.10:9091

Dopodichè, configureremo stunnel in server mode davanti a transmission

[transmission]
accept = 192.168.70.10:9091
connect = 192.168.70.15:9091
cert = <path stunnel conf>/ssl/server/certs/stunnel_crt.pem
key = <path stunnel conf>/ssl/server/private/stunnel_key.pem
requireCert = yes
verifyChain = yes
verifyPeer = yes
CApath = <path stunnel conf>/ssl/client/certs

Alcune note sulla configurazione:

• devo disporre di un certificato per stunnel
• devo disporre dei certificati per i client che si connetteranno, le cui fullchain dovranno essere localizzate nel path indicato da CApath

A questo punto basta che i web-client puntino all’host pubblico (151.25.77.205) sulla porta 9091 e il gioco è fatto.

Per gli altri client come transmission-remote-gtk, transgui o tremotesf, per i quali al massimo posso chiedere di usare TLS (ma non sono riuscito ad usare un’autenticazione lato client), conviene installare stunnel in client mode :

[transmission-client]
accept = localhost:9091
connect = 151.25.77.205:9091
client = yes
cert = <path stunnel conf>/ssl/client/laptop_crt.pem
key = <path stunnel conf>/ssl/client/laptop_key.pem
verifyChain = yes
verifyPeer = yes
CAPath = <path stunnel conf>/ssl/server/certs

Il client (ad es. sul laptop) si connetterà su localhost:9091 e dovrà disporre anche del certificato del server e della sua fullchain affinchè i check su verifyChain e verifyPeer non falliscano.

#ca #DigitalCertificate #AsymmetricEncryption #SymmetricEncryption #cryptography #fullchain #psk #ssh #ssl #stunnel #tls #x509 #openssl