Protocolo TLS

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

Este tópico para profissionais de IT descreve como o protocolo TLS funciona e fornece links para 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, em que eles 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.

TLS e SSL supõem que um transporte orientado a 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 mensagem

  • Interceptação de mensagem

  • Falsificação de mensagem

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 mãos: o protocolo de 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 Schannel 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 de TLS ou SSL tem suporte em versões Windows, consulte Protocolos em TLS/SSL (SSP Schannel). Cada especificação contém informações sobre:

  • O protocolo de registro TLS

  • Os protocolos de hands handsing do TLS: – Alterar o protocolo de especificação de criptografia – protocolo de alerta

  • Cálculos criptográficos

  • Pacote de Criptografia Obrigatório

  • 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 SSP Schannel 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 uns dos outros. Essa modificação fornece as seguintes economias para qualquer cliente TLS que dá suporte ao RFC 5077, incluindo Windows Phone e Windows RT dispositivos:

  • 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 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 suporte introduzido que permite a negociação de protocolo de aplicativo TLS do lado do cliente. Os aplicativos podem aproveitar 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 a TLS para Indicação de Nome de Servidor extensões

O recurso Indicação de Nome de Servidor (SNI) estende os protocolos SSL e TLS para permitir a identificação adequada do servidor quando várias imagens virtuais estão 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 apropriado.

Isso fornece as seguintes funcionalidades adicionais:

  • Permite hospedar vários sites SSL em uma única combinação de porta e protocolo da 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