API di OpenSSL: strutture fondamentali e insidie

L'API EVP (Envelope) è l'interfaccia di alto livello di OpenSSL per le operazioni crittografiche ed è l'API corretta da utilizzare nel codice applicativo. Astrae i dettagli specifici degli algoritmi dietro un'interfaccia coerente, supporta automaticamente l'accelerazione hardware tramite engine e provider e gestisce correttamente i dettagli relativi a padding e modalità. Le API di basso livello specifiche degli algoritmi di OpenSSL sono deprecate nelle versioni moderne e dovrebbero essere evitate.

La cifratura simmetrica in OpenSSL utilizza l'oggetto di contesto EVP_CIPHER_CTX. La sequenza delle operazioni è: EVP_CIPHER_CTX_new per allocare il contesto, EVP_EncryptInit_ex per inizializzarlo con il cifrario e la chiave, EVP_EncryptUpdate ripetutamente per elaborare i dati, EVP_EncryptFinal_ex per completare il blocco finale e recuperare l'output rimanente, infine EVP_CIPHER_CTX_free per liberare la memoria. Saltare EncryptFinal_ex è un errore comune che produce un output troncato.

Il calcolo del digest dei messaggi utilizza EVP_MD_CTX in modo analogo: EVP_MD_CTX_new, EVP_DigestInit_ex con l'algoritmo (EVP_sha256(), EVP_sha3_256() e così via), EVP_DigestUpdate con blocchi di dati ed EVP_DigestFinal_ex per recuperare l'hash. Le operazioni HMAC utilizzano un HMAC_CTX separato o la più recente API EVP_MAC. L'astrazione EVP consente di sostituire gli algoritmi di hashing modificando una sola chiamata di funzione.

EVP_PKEY è l'oggetto unificato per le chiavi asimmetriche in OpenSSL e supporta RSA, ECDSA, Ed25519, DH e altri algoritmi tramite un'unica interfaccia. Le chiavi vengono create da file PEM o DER con PEM_read_PrivateKey e PEM_read_PUBKEY oppure generate con EVP_PKEY_keygen. EVP_PKEY_sign ed EVP_PKEY_verify eseguono la firma e la verifica per qualsiasi tipo di chiave utilizzando le stesse chiamate di funzione.

BIO (Basic I/O) è il livello di astrazione I/O di OpenSSL, che consente di leggere e scrivere dati protetti da TLS o dati grezzi attraverso una catena di oggetti BIO. Una catena BIO può essere composta da BIO_new_ssl, il livello TLS, concatenato a BIO_new_connect, la connessione TCP. La scrittura nel BIO SSL cifra e invia automaticamente i dati; la lettura decifra i dati ricevuti. Gli oggetti BIO supportano file, socket, buffer in memoria e filtri, come base64 e buffering.

Le connessioni TLS in OpenSSL utilizzano due oggetti: SSL_CTX, il contesto che memorizza la configurazione condivisa, ovvero certificato, chiave privata, bundle delle CA, limiti delle versioni del protocollo ed elenco dei cifrari; e SSL, che rappresenta una singola connessione derivata dal contesto. Crei un SSL_CTX per applicazione, quindi crei oggetti SSL a partire da esso per ogni connessione. SSL_read e SSL_write trasferiscono testo in chiaro; OpenSSL gestisce internamente tutto il framing e la cifratura TLS.

L'errore più pericoloso nell'utilizzo di OpenSSL consiste nell'ignorare i valori restituiti. EVP_EncryptFinal_ex, SSL_read e SSL_write restituiscono valori negativi o zero per indicare gli errori. Chiamare SSL_read in un ciclo senza controllare SSL_get_error può causare cicli infiniti o far ignorare gli errori. È necessario controllare il valore restituito da ogni funzione di OpenSSL che può fallire; gli errori spesso indicano condizioni rilevanti per la sicurezza, come errori durante l'handshake o nella convalida del certificato.

SSL_read e SSL_write possono restituire SSL_ERROR_WANT_READ o SSL_ERROR_WANT_WRITE, indicando che l'operazione deve essere ritentata dopo aver atteso l'I/O. Non si tratta di veri errori, ma di notifiche relative all'I/O non bloccante. Il codice che non chiama SSL_get_error e non gestisce correttamente i casi want-read e want-write può entrare in un busy loop oppure trattare erroneamente queste condizioni come errori. Utilizzi sempre SSL_get_error per interpretare i valori restituiti negativi dalle operazioni di I/O TLS.

OpenSSL contiene molte funzioni di basso livello deprecate che non dovrebbero comparire nel nuovo codice: chiamate dirette a DES_encrypt1, uso diretto delle funzioni di hashing SHA1 o MD5 senza il livello EVP, RSA_private_encrypt al posto di EVP_PKEY_sign e AES_encrypt, che utilizza AES in modalità ECB senza autenticazione. Queste API aggirano i controlli di sicurezza, utilizzano algoritmi deprecati oppure sono semplicemente meno sicure delle equivalenti EVP. Gli avvisi del compilatore spesso segnalano l'utilizzo di API deprecate.

OpenSSL utilizza una gestione esplicita della memoria; ogni oggetto allocato deve essere liberato esplicitamente. Memory leak comuni includono dimenticare EVP_CIPHER_CTX_free dopo la cifratura, non chiamare SSL_free dopo la chiusura di una connessione o non chiamare X509_free dopo la verifica di un certificato. Nei server a esecuzione prolungata, questi leak causano un progressivo esaurimento della memoria. Utilizzi strumenti come valgrind o AddressSanitizer per rilevare i memory leak di OpenSSL durante lo sviluppo.

OpenSSL 3.0 ha introdotto il modello dei provider, sostituendo la precedente API ENGINE per l'accelerazione hardware. I provider sono moduli caricabili che implementano algoritmi crittografici: il provider predefinito, per il software; il provider legacy, per gli algoritmi meno recenti; il provider FIPS, convalidato secondo FIPS 140-2; e provider di terze parti per gli HSM. Il provider FIPS abilita un funzionamento conforme limitando gli algoritmi disponibili a quelli approvati da FIPS 140-2, senza modificare il codice dell'applicazione.

Perché l'API EVP di OpenSSL è preferita alle API di basso livello specifiche degli algoritmi?

Riepilogo dell'API OpenSSL: utilizzi sempre l'API EVP di alto livello; EVP_CIPHER_CTX per le operazioni simmetriche; EVP_MD_CTX per l'hashing; EVP_PKEY per le chiavi asimmetriche; le catene BIO per l'astrazione dell'I/O; SSL_CTX e SSL per le connessioni TLS; controlli sempre i valori restituiti e chiami SSL_get_error; liberi tutti gli oggetti allocati per prevenire i memory leak; eviti le funzioni di basso livello deprecate; e utilizzi i provider di OpenSSL 3.0 per la conformità FIPS o l'accelerazione hardware.