Best practices and applications of TLS/SSL (parte 1)
Questa è la prima parte del mini how-to che ho deciso di tradurre, sia per tenere la mente fresca e allenata, sia per fare un po’ di chiarezza agli utenti/passanti di under_r00t.
Per lavoro mi serviva avere a disposizione e “sotto mano” un buon documento consultabile, ho spulciato tra le mie risorse ed ho trovato quello che mi serviva, per questioni di Copyright preferisco non dire chi è il proprietario né il titolo del “white paper”, sappiate che è affidabile 😉 .
Queste sono le “best practices and applications of TLS/SSL” .
Transport Layer Security o TLS, largamente conosciuto anche come Secure Sockets Layer o SSL, è l’applicazione più popolare al mondo per la crittografia delle chiavi pubbliche. E’ famoso per il suo utilizzo in sessioni sicure di browsing ma può essere impiegato anche in altri campi.
TLS/SSL può essere utilizzato per fornire una solida autenticazione tra 2 parti in una sessione di comunicazione, una forte criptazione dei dati in transito tra i 2 e per la verifica dell’ integrità dei dati. Come sempre, se usato impropriamente, TLS può dare l’illusione di sicurezza dove invece le comunicazioni sono state compromesse. E’ importante mantenere i certificati aggiornati e controllare con rigore la presenza di errori.
In alcuni, ma non tutti, degli utilizzi di TLS l’integrità dei processi è supportata dai certificati rilasciati da una “Certificate Authority” (CA) riconosciuta.
INTRODUZIONE
Lo scenario attuale vede la continua crescita e sviluppo di applicazioni “business” , allo stesso passo cresce la necessità di sviluppare modelli sicuri. Assieme alla complessità e alla funzionalità cresce anche l’opportunità di abusi da parte di malintenzionati.
Le soluzioni a questo problema sono svariate e devono essere esplorate individualmente, ma una tecnologia ricorre spesso: TLS o Transport Layer Security, conosciuta spesso con il nome della tecnologia precedente SSL o Secure Socket Layer.
Basilarmente TLS fornisce 3 benefici:
- Provvede all’autenticazione di soggetti in comunicazione, sia in una direzione sia in entrambe le direzioni.
- Cripta le sessioni di comunicazione.
- Assicura l’integrità dei dati trasferiti.
In questo documento si parlerà anche delle CA e del loro ruolo nelle infrastruture delle chiavi pubbliche o PKI.
COS’È TSL/SSL
TLS/SSL è un protocollo di tunneling che lavora al transport layer (livello di trasporto della pila ISO/OSI ndr) e fornisce criptazione, autenticazione e verifica dell’integrità dei dati.
Certificati digitali
un certificato digitale è un documento elettronico che conferma l’identià di un soggetto (che può essere un utente, un server, una società, un programma su un client, più o meno qualsiasi cosa) e associa questo soggetto ad una chiave pubblica. Il certificato digitale è l’identificazione di un soggetto nell’infrastruttura delle chiavi pubbliche. Ogni soggetto che partecipa ad una comunicazione assicurata da TLS può valutare il contenuto del certificato. Il campo maggiormente esaminato è il “common name”. Ognuno poi confronta il valore con quello aspettato.
Utenti possono generare un proprio certificato digitale, chiamati self-signed certificates, grazie all’utilizzo di free tools ma hanno senso se vengono utilizzati all’interno della propria rete. Di fatto la miglior cosa è acquisire certificati da CA riconosciute (… speculazione ndr).
Autenticazione e verifica
Le chiavi pubbliche crittografate permettono 2 soggetti di autenticarsi a vicenda. Ogni soggetto ha 2 chiavi, le chiavi sono valori numerici molto grandi. Un messaggio scambiato tra le 2 parti viene fatto girare attraverso un algoritmo di hash. La funzione di hash prende un blocco di dati e ne calcola un valore, questo valore è conosciuto come hash o digest. Modificare anche una piccolissima parte questo blocco di dati farebbe variare l’hash in modo significativo. Allo stesso tempo non è possibile ricreare il blocco di dati partendo dall’hash.
Il mittente usa la propria chiave privata per criptare il valore dell’hash. Questo valore criptato viene chiamato “digital signature” (firma digitale). Il messaggio assieme alla signature viene spedito al destinatario. Il destinatario usa la chiave pubblica del mittente per decriptare la firma. A questo punto viene generato un hash del messaggio utilizzando lo stesso algoritmo del mittente e poi vengono comparati i valori.
Se i valori coincidono si possono fare 2 considerazioni certe: i dati non sono stati modificati e il mittente è chi dice di essere.
L’autenticazione e la verifica non sono facoltativi nel TLS.
Sicurezza della chiave
Ci sono delle regole fondamentali che devono essere seguite in modo che l’infrastruttura delle chiavi pubbliche lavori adeguatamente.
Le chiavi private devono essere private: il firmatario di un messaggio deve mantenere la propria chiave privata assolutamente confidenziale. Chiunque la possedesse potrebbe effettivamente impersonare il mittente.
Le chiavi pubbliche devono essere pubbliche: non necessariamente pubbliche, ma devono essere accessibili a chiunque abbia una ragione valida per leggere il messaggio o per criptare un messaggio al soggetto nominato nel certificato.
Gli algoritmi di hash non devono collidere: una collisione si ha quando l’algoritmo di hash genera lo stesso digest da due differenti blocchi di dati. In qualche punto questo è inevitabile, ma l’abilità di generare collisioni intenzionalmente compromette tutte le funzioni delle chiavi pubbliche. Questo è il motivo per cui vengono continuamente sviluppati e rilasciati nuovi e migliori algoritmi di hash.
CRIPTAZIONE
Anche quando non viene utilizzata l’autenticazione, TLS può usare le chiavi di criptazione e un algoritmo di cifratura per criptare/decriptare dati in una comunicazione. La cifratura è anche usata per criptare il digest di un messaggio. Ci sono differenti algoritmi di cifratura per differenti circostante.
Fine della prima parte! Stay tuned stay hack 😉
Tags: crypt, tls/ssl, white paper