Os clientes utilizam o protocolo Tabular Data Stream (TDS), um protocolo de camada de aplicativo, para estabelecer uma conexão com o SQL Server. Para proteger a transmissão de dados entre um aplicativo cliente e uma instância do SQL Server, o SQL Server emprega criptografia TLS (Transport Layer Security).

Embora o TDS sempre tenha sido um protocolo seguro, as iterações anteriores do SQL Server não forneciam a opção de desabilitar ou não habilitar a criptografia. Para cumprir o requisito de criptografia obrigatória ao utilizar o SQL Server, foi introduzida uma versão atualizada do protocolo TDS, conhecida como TDS 8.0.

Para melhorar a segurança e a capacidade de gerenciamento do tráfego TDS, o TDS 8.0 implementou um handshake TLS que precede todas as mensagens TDS. Isso envolve efetivamente a sessão TDS em criptografia TLS, alinhando-a com HTTPS e outros protocolos da web. Como resultado, os dispositivos de rede padrão agora podem filtrar e transmitir consultas SQL com segurança, melhorando significativamente o gerenciamento do tráfego TDS.

O TDS 8.0 oferece uma vantagem adicional em relação às versões anteriores por ser compatível não apenas com o TLS 1.3, mas também com futuros padrões TLS. Além disso, o TDS 8.0 mantém total compatibilidade com o TLS 1.2 e iterações anteriores do TLS.

O processo de operação do TDS envolve a utilização do protocolo Tabular Data Stream (TDS), um protocolo de nível de aplicativo projetado especificamente para troca de solicitações e respostas entre sistemas de servidores de banco de dados e clientes. Neste tipo de sistema, um cliente normalmente inicia uma conexão persistente com o servidor. Uma vez estabelecida a conexão através de um protocolo de nível de transporte, a comunicação entre o cliente e o servidor ocorre através de mensagens TDS.

Ao longo da duração da sessão TDS, esta pode ser dividida em três fases distintas:

1. Inicialização
2. Autenticação
3. Troca de dados

Durante a fase inicial, ocorre a negociação da criptografia de troca de dados. Contudo, a negociação do TDS ocorre através de uma conexão que não é criptografada. Para versões anteriores ao TDS 8.0, a conexão do SQL Server aparece da seguinte forma:

O processo começa com um handshake TCP, seguido por um pré-login TDS e uma resposta em texto não criptografado. Depois disso, ocorre um handshake TLS, levando a uma fase de autenticação de forma criptografada. Por fim, pode ocorrer a troca de dados, que podem ou não ser criptografados.

As conexões do SQL Server são estruturadas da seguinte forma com a introdução do TDS 8.0:

O processo começa com um handshake TCP, seguido por um handshake TLS, depois o pré-login e a resposta do TDS ocorrem de maneira criptografada, seguido pela autenticação e, finalmente, ocorre a troca de dados criptografados.

O SQL Server 2022 (16.x) introduziu um novo tipo de criptografia de conexão chamado “estrito” para TDS 8.0. Este tipo de criptografia pode ser habilitado definindo o parâmetro “Encrypt” como “strict” nos drivers do SQL Server. Para utilizar a criptografia de conexão estrita, é necessário atualizar os drivers .NET, ODBC, OLE DB, JDBC, PHP e Python para suas versões mais recentes.

Para garantir proteção contra ataques man-in-the-middle por meio de criptografia de conexão segura, não é possível aos usuários ativar a opção TrustServerCertificate e confiar em qualquer certificado fornecido pelo servidor. Em vez disso, os usuários podem utilizar a opção HostNameInCertificate para especificar o ServerName confiável mencionado no certificado. É imperativo que o certificado do servidor passe com êxito no processo de validação.