In recent releases, 4D’s security capabilities have been significantly expanded, particularly in the area of certificates. This includes auto-generated certificates for client-server communication, support for ECDSA certificates, and, with 4D 20 R7, the validation of certificate authority for client-server communication of engined applications. Some customers require the highest level of security, highlighting the importance of these features.
However, security can be complex, and there have been requests for an explanation of how a TLS/SSL connection works and the role of certificates. Therefore, before delving into the new features, it’s helpful to first break down the basic security concepts and their interactions.
Encryption, authentication, and certificates
At the heart of security are two key concepts: encryption and authentication. Encryption protects data by encoding it, preventing unauthorized access between a server and client, while authentication ensures that both the client and server are who they claim to be. Certificates cover both of these concepts as they are composed of 2 elements (and, as such, 2 files): a key that is kept private and will be used to encrypt the communication and a public certificate that is used for authentication.
symmetric encryption
The simplest form of encryption is symmetric encryption, where the client and server share the same key to encrypt their communication. Symmetric encryption is advantageous because it ensures both encryption and authentication: the server is valid as it uses the correct key, and the client is valid for the same reason. The main drawback of symmetric encryption is the need to copy the key to both the server and the client, requiring a separate, secure communication channel.
Asymmetric encryption
Asymmetric encryption is widely used across the internet and operates on a simple concept: both the client and the server have public and private keys. The public key encrypts the communication, while the private key decrypts it. The server and the client can freely distribute their public keys without concern for potential interception, as the public key only permits encryption. Without the private key, decryption of the communication is not possible.
In 4D, asymmetric encryption is utilized for the HTTP server, the HTTP client, and the communication between 4D Server and 4D Remote. For the HTTP server, the certificate and its corresponding key must be placed in the project folder. For communication between the 4D Server and 4D Remote, the certificate and key can either be stored in the Resource folder of 4D Server (the resource folder is next to the 4D Server executable), or the 4D Server can generate its certificate automatically. The HTTP client and the 4D Remote generate their certificates automatically.
Unlike symmetric encryption, asymmetric encryption ensures encryption but not authentication. This means it cannot guarantee that the server being communicated with is the intended server. This vulnerability can lead to server impersonation and man-in-the-middle (MITM) attacks (where an attacker intercepts the communication between the client and server).
Preventing server impersonations and MITM: Certificate Authority Validation
To prevent man-in-the-middle attacks, the client and the server need a way to authenticate each other. For the client, a classic login/password dialog is generally used as more than a machine you want to authenticate a user.
One of the most common methods to authenticate servers is to use a certificate issued by a trusted certificate authority. Certificate authorities are globally recognized entities whose signatures are embedded in applications such as web browsers. When a server presents a certificate issued by a certificate authority, the client can verify its authenticity by comparing the stored certificate authority signature with the one on the certificate.
Introducing Certificate Authority Validation in 4D 20 R7
Now, let’s explore the new feature in 4D 20 R7: certificate authority validation for engined applications. This update enables 4D clients to verify the certificate they receive from the 4D Server, ensuring the server’s identity and providing protection against man-in-the-middle (MITM) attacks.
To implement this, two values need to be added to the buildApp.4DSettings file when building the client application: the location of a file containing signatures of trusted certificate authorities that will be copied in the client application and the domain name of the server certificate. With this information, the client application can verify that the certificate sent by the server is issued by a valid certificate authority and that the domain name matches the expected one. If there is a discrepancy, the connection will be refused.
For cases involving multiple clients, building a separate application for each client can be challenging. To address this, a list of valid domain names can be provided. While this approach is less secure than specifying a single domain name, it still requires any potential man-in-the-middle to possess a certificate from one of the clients, which is not easily achievable. Alternatively, the domain name field can be left blank, in which case 4D will only check that the certificate originates from a valid certificate authority.
For applications that communicate over the Internet or other untrusted networks, this feature offers an essential layer of protection for client-server communications.
Assistance is always available—feel free to post any questions in the 4D forum.