OpenSSL ou Criptografia Nativa em Delphi: Escolha em Tempo de Execução

6 de outubro de 2026 · Componentes

Remover as DLLs do OpenSSL de uma aplicação Delphi costumava ser uma decisão de build. Você ativava uma define do compilador, recompilava, e distribuía um segundo executável para os clientes que não podiam ter o OpenSSL nas máquinas deles. O sgcWebSockets 2026.10 transforma isso em uma decisão em tempo de execução: uma única variável global, definida uma vez na inicialização, escolhe se a criptografia da aplicação roda sobre o OpenSSL ou sobre a criptografia embutida na biblioteca, escrita em Object Pascal.

O lado da conexão, TLS sem OpenSSL, é tratado em Delphi TLS 1.3 sem DLLs do OpenSSL. Este post é sobre tudo o mais: as assinaturas, os hashes, o acordo de chaves e a criptografia que sua aplicação faz fora do handshake TLS.

Uma Linha na Inicialização

A unit sgcBase_Helpers declara a global sgcCryptoBackend, do tipo TsgcCryptoBackend:

uses
  sgcBase_Helpers;

begin
  sgcCryptoBackend := cbNative;
  sgcCheckNativeCrypto;
  Application.Initialize;
  ...

O interruptor é global, não por componente, então defina-o antes que qualquer componente seja criado. sgcCheckNativeCrypto é opcional: se as units de criptografia nativa não estiverem compiladas, ele gera uma exceção na inicialização com uma mensagem clara, em vez de na primeira assinatura que sua aplicação tentar fazer.

Três Valores

cbOpenSSL é o padrão. A criptografia da aplicação roda sobre o OpenSSL, exatamente como nas versões anteriores, então atualizar não muda nada até você definir a variável.
cbNative roda a criptografia da aplicação sobre a implementação em Object Pascal. O OpenSSL nunca é carregado para isso.
cbAuto usa o OpenSSL quando suas bibliotecas podem ser carregadas, e o código nativo quando não podem. A verificação roda uma vez e o resultado fica em cache.

cbAuto é a opção para produtos distribuídos das duas formas. Alguns clientes instalam as bibliotecas OpenSSL ao lado do executável, outros não têm permissão para isso, e o mesmo build funciona para os dois casos, sem um chamado de suporte por causa de uma DLL ausente.

// same executable, with or without the OpenSSL libraries beside it
sgcCryptoBackend := cbAuto;

O Que Depende do Interruptor

O interruptor abrange a criptografia que os componentes fazem em seu nome:

os helpers de hash e HMAC;
assinatura e verificação de JWT, HS, RS e ES;
provas de OAuth2 e DPoP;
AWS Signature V4 e URLs assinadas do CloudFront;
Web Push;
criptografia de ponta a ponta (E2EE), em que pares em backends diferentes interoperam, então um cliente em cbNative conversa com um servidor ainda em OpenSSL;
WebAuthn e passkeys;
SAML e assinaturas XML;
NTLM;
AEAD, ML-KEM e HKDF;
proteção de pacotes QUIC, os certificados DTLS e WebRTC, e SRTP.

Nenhum deles precisa de mudança de código. Um JWT que foi assinado com OpenSSL ontem é assinado nativamente hoje porque a variável diz isso.

As Conexões São uma Configuração Separada

sgcCryptoBackend não muda como um componente se conecta. O TLS de uma conexão é escolhido por componente, com IOHandler = iohNativeTLS, nos componentes TCP, HTTP e WebSocket e em tudo que é construído sobre eles, como MQTT, no QUIC e no HTTP/3, e em DTLSOptions para WebRTC:

sgcCryptoBackend := cbNative;                  // application crypto
oClient.TLSOptions.IOHandler := iohNativeTLS;  // this connection

Um componente que mantém o handler OpenSSL ainda carrega o OpenSSL ao se conectar. Com iohNativeTLS no QUIC, HTTP/3 e DTLS, nenhum OpenSSL é usado, seja qual for o valor do interruptor. Uma aplicação que não quer OpenSSL em lugar nenhum define os dois: o interruptor para sua criptografia, e o handler em cada componente que abre uma conexão segura.

A Define Agora É Opcional

Até agora, rodar sem OpenSSL significava a define de compilador SGC_NATIVE_CRYPTO. Ela não é mais necessária. Sem ela, tanto o OpenSSL quanto o código nativo são compilados, e a variável decide em tempo de execução.

A define ainda tem um uso. Ela força o backend nativo independentemente do que sgcCryptoBackend diz e remove o código do OpenSSL das units de criptografia da aplicação, o que deixa o executável menor. Se você já sabe que um build nunca vai usar OpenSSL, ela continua sendo a escolha certa. Se você ainda não sabe, deixe-a desativada e decida na inicialização.

Por Que Isso Importa

Um único build. Clientes que precisam distribuir sem OpenSSL, seja por licenciamento, por uma auditoria de segurança que pergunta sobre todo binário de terceiros, ou por máquinas bloqueadas onde ninguém pode copiar uma DLL, recebem o mesmo executável que todo mundo.
Uma alternativa automática. cbAuto mantém uma aplicação funcionando quando as bibliotecas OpenSSL estão ausentes, em vez de falhar na primeira assinatura.
Mobile. No iOS e no Android não há OpenSSL para empacotar para a criptografia da aplicação.
O mesmo código em todo lugar. O interruptor funciona da mesma forma no Windows, Linux, macOS, iOS e Android, do Delphi 7 ao Delphi 13, e no C++Builder.

Atualização

Nada muda até você definir a variável, porque cbOpenSSL é o padrão. Para experimentar o backend nativo, adicione as duas linhas acima ao seu arquivo de projeto, rode seus testes, e compare. A lista completa do que depende do interruptor, e qual configuração cada área precisa para zero OpenSSL em tempo de execução, está no tópico de ajuda Rodando sem OpenSSL.