Cryptage, authentification et validation d’autorité de certification

Dans les dernières versions, la sécurité a été fortement étendue dans 4D, en particulier dans le domaine des certificats. De nouvelles fonctionnalités ont été ajoutées comme les certificats générés automatiquement pour la communication client-serveur, la prise en charge des certificats ECDSA et, avec 4D 20 R7, la validation de l’autorité de certification pour la communication client-serveur des applications enginées. Certains clients exigent le niveau de sécurité le plus élevé, ce qui souligne l’importance de ces fonctionnalités.

Cependant, la sécurité peut être complexe et c’est pourquoi il est utile d’expliquer le fonctionnement d’une connexion TLS/SSL et le rôle des certificats. C’est pourquoi, avant d’aborder la nouvelles fonctionnalité, commençons par décomposer les concepts de base de la sécurité et leurs interactions.

Chiffrement, authentification et certificats

Deux concepts clés sont au cœur de la sécurité : le chiffrement et l’authentification. Le chiffrement protège les données en les encodant, empêchant ainsi tout accès non autorisé entre un serveur et un client, tandis que l’authentification garantit que le client et le serveur sont bien ceux qu’ils prétendent être. Les certificats couvrent ces deux concepts puisqu’ils sont composés de deux éléments (et donc de deux fichiers) : une clé privée qui sera utilisée pour crypter la communication et un certificat public qui servira à l’authentification.

chiffrement symétrique

La forme la plus simple de cryptage est le cryptage symétrique, dans lequel le client et le serveur partagent la même clé pour crypter leur communication. Le chiffrement symétrique est avantageux car il garantit à la fois le chiffrement et l’authentification : le serveur est valide car il utilise la bonne clé, et le client est valide pour la même raison. Le principal inconvénient du cryptage symétrique est la nécessité de copier la clé à la fois sur le serveur et sur le client, ce qui nécessite un canal de communication distinct et sécurisé.

Cryptage asymétrique

Le cryptage asymétrique est largement utilisé sur Internet et fonctionne selon un concept simple : le client et le serveur disposent tous deux d’une clé publique et d’une clé privée. La clé publique crypte la communication, tandis que la clé privée la décrypte. Le serveur et le client peuvent distribuer librement leurs clés publiques sans se soucier d’une éventuelle interception, car la clé publique ne permet que le cryptage. Sans la clé privée, le décryptage de la communication n’est pas possible.

Dans 4D, le chiffrement asymétrique est utilisé pour le serveur HTTP, le client HTTP et la communication entre 4D Server et 4D Remote. Pour le serveur HTTP, le certificat et la clé correspondante doivent être placés dans le dossier du projet. Pour la communication entre le serveur 4D et 4D Remote, le certificat et la clé peuvent être stockés dans le dossier Resource du serveur 4D, sans quoi le serveur 4D générera son certificat automatiquement. Le client HTTP et les 4D Remote génèrent leurs certificats automatiquement.

Contrairement au cryptage symétrique, le cryptage asymétrique assure le cryptage mais pas l’authentification. Cela signifie qu’il ne peut pas garantir que le serveur avec lequel on communique est le serveur prévu. Cette vulnérabilité peut conduire à l’usurpation de l’identité du serveur et à des attaques de type « man-in-the-middle » (MITM) (lorsqu’un attaquant intercepte la communication entre le client et le serveur).

Prévention des usurpations d’identité et des attaques MITM : validation de l’autorité de certification

Pour empêcher les attaques de type « man-in-the-middle », le client et le serveur ont besoin d’un moyen de s’authentifier l’un l’autre. Pour le client, une boîte de dialogue classique de type login/mot de passe est généralement utilisée pour authentifier un utilisateur.

L’une des méthodes les plus courantes pour authentifier les serveurs consiste à utiliser un certificat délivré par une autorité de certification de confiance. Les autorités de certification sont des entités mondialement reconnues dont les signatures sont intégrées dans des applications telles que les navigateurs web. Lorsqu’un serveur présente un certificat émis par une autorité de certification, le client peut vérifier son authenticité en comparant la signature de l’autorité de certification stockée avec celle du certificat.

Présentation de la validation de l’autorité de certification dans 4D 20 R7

Explorons maintenant la nouvelle fonctionnalité de 4D 20 R7 : la validation de l’autorité de certification pour les applications enginées. Cette mise à jour permet aux clients 4D de vérifier le certificat qu’ils reçoivent du serveur 4D, ce qui garantit l’identité du serveur et offre une protection contre les attaques de type « man-in-the-middle » (MITM).

Pour ce faire, deux valeurs doivent être ajoutées au fichier buildApp.4DSettings lors de la création de l’application client : l’emplacement d’un fichier contenant les signatures des autorités de certification de confiance qui seront copiées dans l’application client et le nom de domaine du certificat du serveur. Grâce à ces informations, l’application cliente peut vérifier que le certificat envoyé par le serveur est émis par une autorité de certification valide et que le nom de domaine correspond à celui attendu. En cas de divergence, la connexion sera refusée.

Quand une application est distribuée à de nombreux clients différents, la création d’une application distincte pour chacun d’entre eux peut s’avérer difficile. Pour y remédier, une liste de noms de domaine valides peut être fournie. Bien que cette approche soit moins sûre que la spécification d’un seul nom de domaine, elle exige toutefois que tout hacker potentiel possède un certificat de l’un des clients, ce qui n’est pas facilement réalisable. Il est également possible de laisser le champ du nom de domaine vide, auquel cas 4D vérifiera uniquement que le certificat provient d’une autorité de certification valide.

Pour les applications qui communiquent sur l’internet ou d’autres réseaux non fiables, cette fonction offre une couche de protection essentielle pour les communications client-serveur.

Bien entendu, l’assistance est toujours disponible – n’hésitez pas à poser vos questions dans le forum 4D.