Protocolo TLS

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows 10

Este tópico para o profissional de TI descreve como funciona o protocolo TLS (Transport Layer Security) e fornece links para as RFCs IETF para TLS 1.0, TLS 1.1 e TLS 1.2.

Os protocolos TLS (e SSL) estão localizados entre a camada de protocolo do aplicativo e a camada TCP/IP, onde podem proteger e enviar dados do aplicativo para a camada de transporte. Como os protocolos funcionam entre a camada de aplicativo e a camada de transporte, o TLS e o SSL podem dar suporte a vários protocolos de camada de aplicativo.

O TLS e o SSL pressupõem que um transporte orientado à conexão, normalmente TCP, esteja em uso. O protocolo permite que aplicativos cliente e servidor detectem os seguintes riscos de segurança:

  • Adulteração de mensagem

  • Interceptação de mensagens

  • Falsificação de mensagens

Os protocolos TLS e SSL podem ser divididos em duas camadas. A primeira camada consiste no protocolo do aplicativo e nos três protocolos de handshaking: o protocolo handshake, o protocolo de especificação de criptografia de alteração e o protocolo de alerta. A segunda camada é o protocolo de registro.

Camadas de protocolo TLS e SSL

O Schannel SSP implementa os protocolos TLS e SSL sem modificação. O protocolo SSL é proprietário, mas a Força-Tarefa de Engenharia da Internet produz as especificações de TLS públicas. Para obter informações sobre qual versão TLS ou SSL tem suporte em versões do Windows, consulte Protocolos no TLS/SSL (SSP do Schannel). Cada especificação contém informações sobre:

  • O protocolo de registro TLS

  • Os protocolos TLS Handshaking: – Alterar o protocolo de especificação de criptografia – Protocolo de alerta

  • Cálculos criptográficos

  • Pacotes de criptografia obrigatórios

  • Protocolo de dados do aplicativo

RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (O protocolo TLS versão 1.2)

RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1 (O protocolo TLS versão 1.1)

RFC 2246 - The TLS Protocol Version 1.0 (O protocolo TLS versão 1.0)

Retomada da sessão TLS

Introduzido no Windows Server 2012 R2, o Schannel SSP implementou a parte do lado do servidor da retomada da sessão TLS. A implementação de cliente do RFC 5077 foi adicionada no Windows 8.

Dispositivos que conectam o TLS aos servidores frequentemente precisam se reconectar. A retomada da sessão TLS reduz o custo de estabelecer conexões TLS porque a retomada envolve um handshake TLS abreviado. Isso facilita mais tentativas de retomada, permitindo que um grupo de servidores TLS retome as sessões TLS entre si. Essa modificação fornece as seguintes economias para qualquer cliente TLS que dê suporte ao RFC 5077, incluindo dispositivos Windows Phone e Windows RT:

  • Uso reduzido de recursos do servidor

  • Redução de largura de banda, o que melhora a eficiência das conexões de clientes

  • Tempo reduzido gasto para o handshake do TLS devido a retomadas da conexão

Para obter informações sobre a retomada da sessão TLS sem estado, consulte o documento IETF RFC 5077.

Negociação de protocolos de aplicativos

Windows Server 2012 R2 e Windows 8.1 introduziu suporte que permite a negociação do protocolo de aplicativo TLS do lado do cliente. Os aplicativos podem aproveitar os protocolos como parte do desenvolvimento padrão HTTP 2.0 e os usuários podem acessar serviços online como Google e Twitter usando aplicativos que executam o protocolo SPDY.

Para obter informações sobre como funciona a negociação de protocolo de aplicativo, consulte Extensão de negociação de protocolo de camada de aplicativo de Segurança de Camada de Transporte (TLS).

Suporte do TLS para extensões de Indicação de Nome do Servidor

O recurso SNI (Indicação de Nome do Servidor) estende os protocolos SSL e TLS para permitir a identificação adequada do servidor quando várias imagens virtuais estiverem em execução em um único servidor. Em um cenário de hospedagem virtual, vários domínios (cada um com seu próprio certificado potencialmente distinto) são hospedados em um servidor. Nesse caso, o servidor não tem como saber com antecedência qual certificado enviar ao cliente. O SNI permite que o cliente informe o domínio de destino anteriormente no protocolo e isso permite que o servidor selecione corretamente o certificado adequado.

Isso fornece a seguinte funcionalidade adicional:

  • Permite que você hospede vários sites SSL em uma única combinação de porta e protocolo de Internet

  • Reduz o uso de memória quando diversos sites SSL são hospedados em um único servidor Web

  • Permite que mais usuários se conectem a sites SSL simultaneamente