Protocolo TLS

  • Artigo

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 o protocolo TLS funciona e fornece links para os RFCs IETF para TLS 1.0, TLS 1.1 e TLS 1.2.

Observação

Em uma versão futura do Windows Server, o TLS 1.0 e o 1.1 serão desabilitados por padrão. Para obter mais informações, consulte Recursos de desabilitação do TLS 1.0 e 1.1.

Os protocolos TLS (e SSL) estão localizados entre a camada do protocolo de 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 consideram que um transporte destinado à conexão, normalmente TCP, está em uso. O protocolo permite que aplicativos cliente e servidor detectem os seguintes riscos de segurança:

  • Adulteração de mensagens

  • 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 de 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 SSP do Schannel implementa os protocolos TLS e SSL sem modificação. O protocolo SSL é proprietário, mas a Internet Engineering Task Force produz as especificações públicas do TLS. Para obter informações sobre qual versão do TLS ou SSL tem suporte nas 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 de 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

Apresentado no Windows Server 2012 R2, o SSP do Schannel implementou a parte do lado do servidor da retomada de sessão do 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 de sessão do TLS reduz o custo de estabelecer conexões do TLS, porque a continuidade envolve um handshake do TLS abreviado. Isso facilita mais tentativas de retomada, permitindo que um grupo de servidores de TLS retomem as sessões do TLS uns dos outros. Essa modificação fornece as seguintes economias para todo 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

  • Menos tempo gasto para o handshake do TLS devido às retomadas de conexão

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

Negociação de protocolos de aplicativos

O Windows Server 2012 R2 e Windows 8.1 introduziram 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 do HTTP 2.0 e os usuários podem acessar serviços online, como Google e Twitter, usando os 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 às Extensões de Indicação de Nome de Servidor

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

Isso fornece a seguinte funcionalidade adicional:

  • Permite hospedar vários sites SSL em uma única combinação de Protocolo de Internet e porta

  • 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 aos sites SSL simultaneamente