Em versões recentes, as capacidades de segurança de 4D foram significativamente expandidas, particularmente na área de certificados. Isso inclui certificados gerados automaticamente para comunicação cliente-servidor, suporte para certificados ECDSA, e, com 4D 20 R7, a validação de autoridade de certificado para comunicação cliente-servidor de aplicações engined. Alguns clientes requerem o mais alto nível de segurança, destacando a importância dessas caraterísticas.
No entanto, a segurança pode ser complexa, e tem havido pedidos para uma explicação de como uma conexão TLS/SSL funciona e o papel dos certificados. Por conseguinte, antes de nos aprofundarmos nas novas funcionalidades, é útil analisar primeiro os conceitos básicos de segurança e as suas interações.
Encriptação, autenticação e certificados
No centro da segurança estão dois conceitos-chave: encriptação e autenticação. A encriptação protege os dados codificando-os, impedindo o acesso não autorizado entre um servidor e um cliente, enquanto a autenticação garante que tanto o cliente como o servidor são quem afirmam ser. Os certificados abrangem estes dois conceitos, uma vez que são compostos por 2 elementos (e, como tal, 2 ficheiros): uma chave que é mantida privada e que será utilizada para encriptar a comunicação e um certificado público que é utilizado para autenticação.
encriptação simétrica
A forma mais simples de encriptação é a encriptação simétrica, em que o cliente e o servidor partilham a mesma chave para encriptar a sua comunicação. A encriptação simétrica é vantajosa porque garante tanto a encriptação como a autenticação: o servidor é válido porque utiliza a chave correta e o cliente é válido pela mesma razão. O principal inconveniente da encriptação simétrica é a necessidade de copiar a chave tanto para o servidor como para o cliente, o que exige um canal de comunicação separado e seguro.
Encriptação assimétrica
A encriptação assimétrica é amplamente utilizada na Internet e funciona com base num conceito simples: tanto o cliente como o servidor têm chaves públicas e privadas. A chave pública encripta a comunicação, enquanto a chave privada a desencripta. O servidor e o cliente podem distribuir livremente as suas chaves públicas sem se preocuparem com potenciais intercepções, uma vez que a chave pública apenas permite a encriptação. Sem a chave privada, a decriptação da comunicação não é possível.
Em 4D, a encriptação assimétrica é utilizada para o servidor HTTP, o cliente HTTP, e a comunicação entre 4D Server e 4D Remote. Para o servidor HTTP, o certificado e sua chave correspondente devem ser colocados na pasta do projeto. Para a comunicação entre o Servidor 4D e o 4D Remote, o certificado e a chave podem ser armazenados na pasta Resource do Servidor 4D, ou o Servidor 4D pode gerar seu certificado automaticamente. O cliente HTTP e o 4D Remote geram seus certificados automaticamente.
Diferente da criptografia simétrica, a criptografia assimétrica garante a criptografia mas não a autenticação. Isso significa que não pode garantir que o servidor que está sendo comunicado é o servidor pretendido. Esta vulnerabilidade pode levar a ataques de personificação do servidor e ataques man-in-the-middle (MITM) (em que um atacante intercepta a comunicação entre o cliente e o servidor).
Prevenir a falsificação de identidade do servidor e MITM: Validação da autoridade de certificação
Para evitar ataques man-in-the-middle, o cliente e o servidor precisam de uma forma de se autenticarem mutuamente. Para o cliente, uma caixa de diálogo clássica de início de sessão/palavra-passe é geralmente utilizada como mais do que apenas um método para autenticar um usuário.
Um dos métodos mais comuns para autenticar servidores é utilizar um certificado emitido por uma autoridade de certificação fiável. As autoridades de certificação são entidades reconhecidas globalmente cujas assinaturas são incorporadas em aplicações como os navegadores Web. Quando um servidor apresenta um certificado emitido por uma autoridade de certificado, o cliente pode verificar sua autenticidade comparando a assinatura da autoridade de certificado armazenada com a que está no certificado.
Introduzindo a Validação de Autoridade de Certificado em 4D 20 R7
Agora, vamos explorar a nova caraterística em 4D 20 R7: validação de autoridade de certificado para aplicações autônomas. Essa atualização permite que clientes 4D verifiquem o certificado que recebem do Servidor 4D, assegurando a identidade do servidor e fornecendo proteção contra ataques man-in-the-middle (MITM).
Para implementar isso, dois valores precisam ser adicionados ao arquivo buildApp.4DSettings ao construir a aplicação cliente: a localização de um arquivo contendo assinaturas de autoridades de certificado confiáveis que serão copiadas na aplicação cliente e o nome de domínio do certificado do servidor. Com estas informações, a aplicação cliente pode verificar se o certificado enviado pelo servidor é emitido por uma autoridade de certificação válida e se o nome de domínio corresponde ao esperado. Se houver uma discrepância, a ligação será recusada.
Nos casos que envolvem vários clientes, a criação de uma aplicação separada para cada cliente pode ser um desafio. Para resolver este problema, pode ser fornecida uma lista de nomes de domínio válidos. Embora esta abordagem seja menos segura do que a especificação de um único nome de domínio, continua a exigir que qualquer potencial “man-in-the-middle” possua um certificado de um dos clientes, o que não é fácil de conseguir. Alternativamente, o campo de nome de domínio pode ser deixado em branco, e nesse caso 4D só vai verificar se o certificado é originado de uma autoridade de certificação válida.
Para aplicações que se comunicam pela Internet ou outras redes não confiáveis, essa caraterística oferece uma camada essencial de proteção para comunicações cliente-servidor.
Assistência está sempre disponível – sinta-se livre para postar qualquer pergunta no fórum 4D.