SSL chi era costui?

Questo documento raccoglie alcune note che ho scritto nel tempo utilizzando il protocollo SSL per la trasmissione sicura dei dati.
Questa pagina ha un taglio pratico e presenta diversi esempi tuttavia non e' un documento introduttivo ed e' consigliato ad un pubblico informaticamente adulto...

I siti web sono protetti con l'HTTPS che utilizza l'SSL, per connettersi in modo sicuro ad un sistema si usa l'ssh che utilizza chiavi, algoritmi e certificati come l'SSL, le VPN utilizzano l'SSL ed anche i database usano lo stesso protocollo per le connessioni sicure.

SSL (TL;DR)

Abbiamo utilizzato fino ad ora il termine SSL ma e' sbagliato!
Un'avvertenza: ho inserito questo paragrafo per completezza, ma e' piuttosto criptico (ovviamente... dato l'argomento ;-): potete tranquillamente saltarlo!

Per essere precisi l'SSL (Secure Sockets Layer) e' il predecessore dell'attuale TLS (Transport Layer Security) e sono entrambe protocolli crittografici utilizzati per le comunicazioni sopra il livello di trasporto TCP (Transmission Control Protocol). L'utilizzo piu' comune e noto del TLS/SSL e' su web per garantire la sicurezza delle comunicazioni verso i siti (con il protocollo HTTPS), altrettanto importante e significativo e' l'uso del TLS/SSL nelle connessioni VPN, ... Per l'accesso alle basi dati e' meno utilizzato poiche' solitamente queste vengono poste su reti interne non raggiungibili da Internet; ma per un database in Cloud la crittografia sul canale di comunicazione e' invece fondamentale.

TLS/SSL forniscono meccanismi per l'autenticazione, l'integrita' dei dati e la cifratura operando al di sopra del livello di trasporto [NdE il livello di trasporto e' il TCP]. Nella fase di avvio della comunicazione tra due nodi viene prima negoziato l'algoritmo da utilizzare, quindi vengono scambiate le chiavi di cifratura ed eseguita l'autenticazione. La fase di autenticazione avviene con lo scambio di chiavi asimmetriche (ovviamente viene inviata solo la chiave pubblica) e la verifica di certificati emessi da certificate authority (CA). Una volta instaurata la comunicazione i messaggi vengono cifrati con chiavi simmetriche ed verificati singolarmente con un checksum.

Per ogni fase vengono utilizzati protocolli diversi ed in ogni versione vengono aggiornati gli algoritmi (eliminando quelli che sono stati ricosciuti meno sicuri). Attualmente vengono utilizzati per lo scambio di chiavi: RSA, Diffie-Hellman, ECDH, ... per l'autenticazione: RSA, DSA, ECDSA, ... per la cifratura simmetrica: RC4, DES, Triple DES, AES, ... per la verifica d'integrita': in TLS sono utilizzati HMAC-MD5 o HMAC-SHA. Ad esempio con l'SSL per la verifica di integrita' venivano utilizzati anche: MD2, MD4, MD5 e SHA-1, ora ritenuti non sufficientemente sicuri.

Tutto chiaro? Probabilmente no... ma non importa! E' piu' semplice di quanto sembri: con il corretto utilizzo di TLS/SSL si esegue almeno un'autenticazione (quindi si e' certi dell'identita' del chiamato/chiamante), ogni messaggio viene verificato (quindi non puo' essere modificato), ogni messaggio viene cifrato (quindi non puo' essere letto da altri).

Protocolli SSL e TLS

Sappiamo che l'SSL (Secure Sockets Layer) e' il predecessore dell'attuale TLS (Transport Layer Security)... vediamo tutta la storia!

L'SSL e' stato sviluppato da Netscape nel 1995 ma quando poi il protocollo e' stato aggiornato dall'IETF (Internet Engineering Task Force), per indicare il cambio di titolarita' ne e' stato cambiato il nome. Si tratta comunque di un'evoluzione dello stesso protocollo.

Il prototollo consente la connessione cifrata a livello di sessione su un trasporto TCP. La fase iniziale del protocollo prevede l'autenticazione tra i due dispositivi in comunicazione. Almeno uno dei due dispositivi deve possedere un certificato SSL emesso da una CA (Certification Authority). Terminata la fase di autenticazione ogni messaggio scambiato viene crittografato e firmato: in questo modo un terzo che vedesse i messaggi sulla rete non potrebbe ne leggerli ne modificarli.

Da citare come sigla anche l'STARTTLS che e' un'ulteriore variazione del TLS che consente l'utilizzo delle stesse porte...

Dal punto di vista pratico il protocollo SSL/TLS e' usato dai siti web per garantirne la sicurezza. In questo caso si utilizza il protocollo HTTPS che e' in pratica il protocollo HTTP (per la trasmissione dei contenuti) + SSL (per la crittografia). Il certificato e' posseduto dal web server, in questo modo chi accede al sito e' certo della sua destinazione. Per instaurare un canale sicuro e' sufficiente un solo certificato.

Quando il gioco si fa duro... E' possibile autorizzare i client con un livello di sicurezza maggiore rispetto a quello fornito dalla semplice coppia username/password. In questo caso ogni client deve avere un certificato, vanno inserte nel file root.crt le certificate authorities (CAs) ritenute valide, possono essere configurate le Certificate Revocation List (CRL)... Tecnicamente questa e' la strong authentication che in pratica si basa sull'autenticazione di entrambe le parti con i certificati.

Certificati

Ottenere un certificato e' un po' come ottenere un documento di identita': per un documento di identita' va fatta una richiesta all'ente corretto, spesso si deve pagare qualche costo, si attende la risposta ed alla fine si ottiene il documento richiesto. Il documento ha una data di emissione ed una scadenza e, in qualche raro caso, puo' anche essere revocato.
Naturalmente e' evidente a tutti che c'e' differenza tra una patente ed un passaporto o tra un comune ed una questura... ebbene praticamente lo stesso vale anche per i certificati!

Gli enti che emettono i certificati sono le Certificate Authorities (CA). I certificati possono essere sul dominio singolo, con caratteri Jolly e multidominio. Dal punto di vista di convalida sono previsti livelli diversi: dominio, organizzazione e validazione estesa. Tutti i certificati hanno una scadenza, quindi vanno rinnovati per tempo. I certificati possono essere invalidati dalla CA con l'inserimento nella CRL (Certificate Revocation List).

Tipicamente un certificato ha un costo ma c'e' anche il modo per emettersi un certificato da soli senza pagare nulla. Si tratta di un certificato self-signed e naturalmente sara' accettato solo da chi si fida di noi.
Ecco i passi per creare un certificato self-signed:

# Creamo una richiesta di un certificato # bisogna rispondere alle varie domande: e' importante che il Common Name sia l'FQDN del server openssl req -new -text -out server.req # Ora e' necessario rimuovere la passphrase openssl rsa -in privkey.pem -out server.key rm privkey.pem # Generiamo il certificato self-signed openssl req -x509 -in server.req -text -key server.key -out server.crt # Le permission del file debbono essere molto ristrette altrimenti non vengono accettate chmod og-rwx server.key

Con i passi eseguiti abbiamo generato un certificato server (file server.crt) ed una chiave privata (file server.key) che potranno essere utilizzati dal nostro web server o da qualunque programma che necessita di un certificato (ad esempio un DB server come PostgreSQL).
Alcuni programmi hanno una gestione diversa dei certificati che debbono essere inseriti in un wallet anziche' come file... cambiano solo i comandi ma i certificati sono sempre gli stessi.
Anche le CA debbono essere riconosciute come autorevoli, oltre ai certificati generalmente sono necessarie anche le catene di autorizzazioni delle CA stesse, ma questo argomento e' troppo lungo per descriverlo in questa paginetta di introduzione.

I certificati utilizzati dall'SSL hanno un formato definito dallo standard X.509 introdotto nel 1988. L'RFC 5280 (Request For Comment: e' la modalita' con cui vengono definiti gli standard di comunicazione) definisce il certificato X.509 v3 e l'elenco di revoche di certificati X.509 v2 (CRL).

Formato dei certificati

Come vedete non c'e' la foto... ma il contenuto non e' comprensibile per noi umani ma e' facilmente gestibile perche' si tratta di un formato a caratteri. In realta' esistono diversi formati di file ed e' importante conoscerli. Il formato che abbiamo appena visto e' il PEM ed e' facilmente riconoscibile dalle stringhe BEGIN ed END.

Quando si e' fortunati basta un click e tutto funziona... quando si e' sfortunati bisogna convertire i formati dei certificati, certificare le CA, risalire alle catene di certificazione, ...

HTTPS

Il protocollo HTTP ed il linguaggio ipertestuale HTML sono stati sviluppati al CERN da Tim Berners-Lee e quindi divenuti standard ed hanno trovato un'enorme diffuzione con il WWW (Word Wide Web).
Con l'HTTP un utente che utilizza un browser si collega con un URL ad un sito web, tipicamente alla porta 80, ottiene la pagina cercata e puo' navigare seguendo i link su altre pagine e siti web.

Come in molti protocolli TCP anche in HTTP i messaggi vengono scambiati in chiaro. E' quindi emersa subito l'esigenza di verificare che il sito cui ci si collegava fosse realmente quello desiderato e che le informazioni confidenziali non venissero inviate in chiaro. Per questo Nescape, che aveva sviluppato uno dei primi browser [NdE Netscape Navigator], sviluppo' il protocollo SSL (Secure Socket Layer) e l'HTTPS (HyperText Transfer Protocol over Secure Socket Layer) nel 1994.

L'HTTPS utilizza una porta di default differente: la porta 443 ma dal punto di vista del protocollo HTTP non cambia nulla, la connessione sicura con SSL/TLS e' implementata al di sopra del protocollo HTTP. Per un utente che utilizza un browser e' molto semplice sapere se il sito a cui e' connesso e' sicuro: apparira' il luchetto con il simbolo dell'HTTPS a fianco dell'indirizzo. Dal punto di vista di navigazione delle pagine, di accessi, ... non cambia nulla ma quando e' presente il simbolo con il luchetto chiuso la connessione e' considerata sicura: il sito web e' quello indicato nell'URL, nessuno puo' leggere i messaggi, nessuno puo' modificare i messaggi.

Differente e' l'HTTP/3, che e' stato introdotto di recente ma e' gia' abilitato su molti siti web e su molti browser. L'HTTP/3 non usa il TCP ma il protocollo QUIC [NdE sviluppato da Jim Roskind di Google nel 2012] che utilizza a sua volta l'UDP sempre sulle porte 80 e 443.

Per i piu' tecnici ecco le principali differenze tra i protocolli [NdA a mio modesto avviso]:

Meno completa ma molto chiara e' questa immagine sulle differenze tra i protocolli HTTP [NdA che ho preso da qui] HTTP Protocols

E' OT ma comunque importante ricordare che anche l'HTML, ovvero il linguaggio ipertestuale con cui sono scritte le pagine web trasportate dall'HTTP/HTTPS ha avuto un forte evoluzione. Su questo ho scritto solo alcune paginette: il tag META, HTML/5, ...
Da citare come sigla anche l'SHTTP modellato sulla posta cifrata S/MIME ma non piu' utilizzato.

SSH

La connessione diretta ad un server su terminale, ovvero il classico telnet, ha un'autenticazione minimale e tutti i messaggi passano in chiaro. SSH sta per Secure Shell e consente un accesso autenticato, crittografato e con messaggi non modificabili tra un terminale ed un server. Il protocollo SSH non utilizza l'SSL ma sono molte le analogie ed i punti di contatto.

La porta di default dell'SSH e' la 22 ed il comando e' ssh [user]@host. Con sftp si accedere in modo sicuro alla gestione di file in modo simile all'FTP.

Con la prima connnessione ad un server viene richiesto se puo' essere considerato sicuro. Nel caso in cui la chiave di un server venga cambiata il client SSH non effettua l'accesso perche' qualcuno potrebbe essersi sostituito all'host originale. Le configurazioni locali sono mantenute nella directory .ssh ed e' in questa directory che eventualmente si effettuano correzioni in caso di problemi (eg. eliminando una riga dal file .ssh/known_hosts).

Per configurare l'accesso senza password ad un server deve essere generata una chiave e copiata la chiave pubblica sul server. I passi di dettaglio sono:

local:~$ ssh-keygen local:~$ cd ~/.ssh/ local:~$ scp id_rsa.pub myuser@host:./id_dsa.pub local:~$ ssh myuser@host host:~$ cd .ssh host:~$ touch authorized_keys2 host:~$ chmod 600 authorized_keys host:~$ cat ../id_rsa.pub >> authorized_keys host:~$ rm ../id_rsa.pub

Qual'e' il formato della chiave RSA generata? Si puo' impostare con l'opzione -m scegliendo anche tra i formati che abbiamo gia' visto:
[ RFC4716 | PKCS8 | PEM ]

Non dovrebbe piu' capitare... ma se si accede a server particolarmente datati l'SSH potrebbe non riuscire a trovare un algoritmo di crittografia abilitato su entrambe i nodi. E' possibile abilitare algoritmi con parametri specifici:
ssh -oHostKeyAlgorithms=+ssh-dss user@host

Con l'SSH e' possibile creare canali di comunicazione per accedere a servizi differenti a quelli della semplice connessione di terminale come descritto in Tunnel SSH.

SSHD

Nel capitolo precedente abbiamo visto la parte relativa al client, ora vediamo la parte relativa al server SSH. La configurazione di default del demone SSH su un Linux recente e' considerata sicura ma e' possibile agire sul file di configurazione /etc/ssh/sshd_config aggiungendo:

Le direttive indicate disabilitano l'accesso all'utenza root (per collegarsi come root bisogna entrare con un utente autorizzato e quindi eseguire un sudo), disabilitano l'accesso ad utenti senza password, modificano la porta di default, utilizzano la versione 2 del protocollo piu' sicura della versione precedente, impostano un keepalive delle sessioni, disabilitano il protocollo X11. E' anche possibile restringere l'accesso ad alcuni utenti o gruppo ed escludere l'autenticazione con password. Questa ultima impostazione ovviamente richiede che prima siano stati configurati i certificati personali... altrimenti non si accede piu' al sistema!
Se un sistema e' esposto ad Internet e' anche opportuno contrastare gli attacchi brute force con programmi come Fail2Ban.

OpenSSH non supporta i certificati X.509 ma alcune implementazioni SSH lo permettono.

VPN

Le VPN (Virtual Private Network) consentono di operare in remoto su una rete in modo protetto. Le VPN utilizzano in modo significativo la crittografia ed i certificati. Dal punto di vista tecnico non tutte le VPN utilizzano il protocollo SSL/TLS. Le tipologie di protocolli per VPN piu' utilizzati attualmente sono SSL, IPSec e PPTP.

Le VPN SSL (naturalmente SSL/TLS), sia commerciali che Open Source come la diffusissima OpenVPN, utilizzano la normale pila TCP-IP e quindi sono facilmente portabili.
Il protocollo IPsec richiede una modifica del protocollo IP e quindi e' necessario un porting specifico per ogni distribuzione di sistema operativo.
Il protocollo PPTP e' stato sviluppato da Microsoft, quindi e' disponibile su tutti i PC, ma e' considerato meno sicuro.

Oltre al protocollo di base e' importante la modalita' di accesso: le principali SSL VPNs sono VPN portal o VPN tunnel.

Varie ed eventuali

L'utilizzo del protocollo SSL presenta notevoli vantaggi in termini di sicurezza ma ha i suoi costi.
La crittografazione ha un peso computazionale (con gli HW attuali difficimente e' un problema), le fasi di autenticazione introducono latenza spesso significativa, la configurazione e' piu' complessa e richiede tempo, i certificati veri hanno un costo ed una scadenza.
La scadenza dei certificati in particolare richiede una gestione attenta: quante volte e' successo di dover sostituire velocemente il certificato su un web server?

I protocolli, gli algoritmi, e, soprattutto, chi li usa, non sono mai perfetti. L'SSL/TLS ha limiti ben precisi (ad esempio protegge il contenuto del messaggio ma non il fatto che una comunicazione avvenga) e viene periodicamente aggiornato perche' si scoprono difetti o nuovi tipi di attacchi. La presenza di un luchetto chiuso su un browser non e' quindi una sicurezza assoluta.

Titolo: SSL, TLS
Livello: Esperto (4/5)
Data: 14 Febbraio 2022 ❤️
Versione: 1.0.1 - 31 Ottobre 2022 🎃
Autore: mail [AT] meo.bogliolo.name

Protocollo	Anno pubblicazione	Stato
SSL 1.0	Non pubblicato	Non pubblicato
SSL 2.0	1995	Deprecato nel 2011 (RFC 6176)
SSL 3.0	1996	Deprecato nel 2015 (RFC 7568)
TLS 1.0	1999	Deprecato nel 2021 (RFC 8996)
TLS 1.1	2006	Deprecato nel 2021 (RFC 8996)
TLS 1.2	2008	Valido (RFC 5246)
TLS 1.3	2018	Attuale (RFC 8446)

Formato	Suffissi	Note
PEM	.pem .crt .cer .key	Utilizzato sui web server (eg. Apache) per CERTIFICATE, CERTIFICATE REQUEST, RSA PRIVATE KEY
P7B/PKCS#7	.p7b .p7c	Utilizzato in Tomcat solo per certificati con il formato: —–BEGIN PKCS7—– —–END PKCS7—–
DER	.cer .der	Formato binario usato spesso con Java
PFX/P12/PKCS#12	.pfx .p12	Formato binario tipico di Windows che contiene server certificate, intermediate certificate e private key

Protocollo	Anno	Stato
HTTP/0.9	1991	Obsoleto
HTTP/1.0	1996	Obsoleto
HTTP/1.1	1997	Standard
HTTP/2	2015	Standard
HTTP/3	2022	Standard