Crittografia. Autenticazione e convalida dell’autorità di certificazione

Nelle ultime versioni, le funzionalità di sicurezza di 4D sono state notevolmente ampliate, in particolare nell’area dei certificati. Tra queste figurano i certificati generati automaticamente per la comunicazione client-server, il supporto per i certificati ECDSA e, con 4D 20 R7, la convalida dell’autorità di certificazione per la comunicazione client-server delle applicazioni inglobate. Alcuni clienti richiedono il massimo livello di sicurezza, il che evidenzia l’importanza di queste funzioni.

Tuttavia, la sicurezza può essere complessa e ci sono state richieste di spiegazioni sul funzionamento di una connessione TLS/SSL e sul ruolo dei certificati. Per questo motivo, prima di addentrarci nelle nuove funzionalità, è utile suddividere i concetti di base della sicurezza e le loro interazioni.

Crittografia, autenticazione e certificati

Alla base della sicurezza ci sono due concetti chiave: crittografia e autenticazione. La crittografia protegge i dati codificandoli e impedendo l’accesso non autorizzato tra un server e un client, mentre l’autenticazione garantisce che sia il client che il server siano chi dicono di essere. I certificati coprono entrambi questi concetti in quanto sono composti da 2 elementi (e, come tali, da 2 file): una chiave che viene mantenuta privata e che verrà utilizzata per crittografare la comunicazione e un certificato pubblico che viene utilizzato per l’autenticazione.

crittografia simmetrica

La forma più semplice di crittografia è la crittografia simmetrica, in cui il client e il server condividono la stessa chiave per crittografare la comunicazione. La crittografia simmetrica è vantaggiosa perché garantisce sia la crittografia che l’autenticazione: il server è valido in quanto utilizza la chiave corretta e il client è valido per lo stesso motivo. Lo svantaggio principale della crittografia simmetrica è la necessità di copiare la chiave sia sul server che sul client, richiedendo un canale di comunicazione separato e sicuro.

Crittografia asimmetrica

La crittografia asimmetrica è ampiamente utilizzata in Internet e si basa su un concetto semplice: sia il client che il server dispongono di chiavi pubbliche e private. La chiave pubblica cripta la comunicazione, mentre la chiave privata la decripta. Il server e il client possono distribuire liberamente le loro chiavi pubbliche senza preoccuparsi di potenziali intercettazioni, poiché la chiave pubblica consente solo la crittografia. Senza la chiave privata, la decodifica della comunicazione non è possibile.

In 4D, la crittografia asimmetrica viene utilizzata per il server HTTP, per il client HTTP e per la comunicazione tra 4D Server e 4D Remote. Per il server HTTP, il certificato e la chiave corrispondente devono essere collocati nella cartella del progetto. Per la comunicazione tra il server 4D e 4D Remote, il certificato e la chiave possono essere memorizzati nella cartella Resource del server 4D, oppure il server 4D può generare automaticamente il proprio certificato. Il client HTTP e il 4D Remote generano automaticamente i loro certificati.

A differenza della crittografia simmetrica, la crittografia asimmetrica garantisce la crittografia ma non l’autenticazione. Ciò significa che non può garantire che il server con cui si comunica sia quello previsto. Questa vulnerabilità può portare all’impersonificazione del server e ad attacchi MITM (man-in-the-middle) (in cui un aggressore intercetta la comunicazione tra il client e il server).

Prevenzione di impersonificazioni di server e MITM: convalida dell’autorità di certificazione

Per prevenire gli attacchi man-in-the-middle, il client e il server devono potersi autenticare a vicenda. Per il client, in genere si utilizza una classica finestra di dialogo login/password, poiché più che una macchina si vuole autenticare un utente.

Uno dei metodi più comuni per autenticare i server è l’utilizzo di un certificato emesso da un’autorità di certificazione affidabile. Le autorità di certificazione sono entità riconosciute a livello mondiale le cui firme sono incorporate in applicazioni come i browser web. Quando un server presenta un certificato emesso da un’autorità di certificazione, il client può verificarne l’autenticità confrontando la firma dell’autorità di certificazione memorizzata con quella del certificato.

Introduzione alla convalida dell’autorità di certificazione in 4D 20 R7

Ora analizziamo la nuova funzionalità di 4D 20 R7: la convalida dell’autorità di certificazione per le applicazioni di tipo engined. Questo aggiornamento consente ai client 4D di verificare il certificato che ricevono dal server 4D, garantendo l’identità del server e fornendo protezione contro gli attacchi man-in-the-middle (MITM).

Per implementare questa funzione, è necessario aggiungere due valori al file buildApp.4DSettings durante la creazione dell’applicazione client: il percorso di un file contenente le firme delle autorità di certificazione affidabili che verrà copiato nell’applicazione client e il nome del dominio del certificato del server. Con queste informazioni, l’applicazione client può verificare che il certificato inviato dal server sia emesso da un’autorità di certificazione valida e che il nome di dominio corrisponda a quello previsto. In caso di discrepanza, la connessione verrà rifiutata.

Per i casi che coinvolgono più client, la creazione di un’applicazione separata per ogni client può essere impegnativa. Per risolvere questo problema, è possibile fornire un elenco di nomi di dominio validi. Sebbene questo approccio sia meno sicuro rispetto all’indicazione di un singolo nome di dominio, richiede comunque che ogni potenziale man-in-the-middle possieda un certificato di uno dei client, cosa non facilmente realizzabile. In alternativa, il campo del nome di dominio può essere lasciato vuoto, nel qual caso 4D verificherà solo che il certificato provenga da un’autorità di certificazione valida.

Per le applicazioni che comunicano su Internet o su altre reti non affidabili, questa funzione offre un livello di protezione essenziale per le comunicazioni client-server.

L’assistenza è sempre disponibile: non esitate a porre domande nel forum di 4D.