Partilhar via


Protocolo de segurança da camada de transporte

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

Note

Em uma versão futura do Windows Server, o TLS 1.0 e 1.1 será desabilitado por padrão. Para obter mais informações, consulte recursos de desativação do TLS versões 1.0 e 1.1.

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

TLS e SSL assumem que um transporte orientado a conexão, normalmente TCP, está em uso. O protocolo permite que os aplicativos cliente e servidor detetem os seguintes riscos de segurança:

  • Adulteração de mensagens

  • Interceçã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 aplicação e nos três protocolos de handshake: o protocolo de handshake, o protocolo de alteração de cifra 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ções. O protocolo SSL é proprietário, mas a Internet Engineering Task Force produz as especificações TLS públicas. Para obter informações sobre qual versão TLS ou SSL é suportada em versões do Windows, consulte Protocolos em TLS/SSL (SSP Schannel). Cada especificação contém informações sobre:

  • O protocolo de registro TLS

  • Os protocolos TLS Handshaking: - Alterar protocolo de especificação de cifra - Protocolo de alerta

  • Cálculos Criptográficos

  • Suítes Cipher obrigatórias

  • Protocolo de Dados de Aplicação

RFC 5246 - O protocolo TLS (Transport Layer Security) Versão 1.2

RFC 4346 - O protocolo TLS (Transport Layer Security) Versão 1.1

RFC 2246 - O Protocolo TLS Versão 1.0

Reinício da sessão TLS

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

Os dispositivos que conectam TLS a 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. Esta modificação proporciona as seguintes economias para qualquer cliente TLS que suporte RFC 5077, incluindo dispositivos Windows Phone e Windows RT:

  • Redução do uso de recursos no servidor

  • Largura de banda reduzida, o que melhora a eficiência das conexões do cliente

  • Redução do tempo necessário para o aperto de mão TLS devido às retomadas da conexão.

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

Negociação de protocolo de aplicação

O Windows Server 2012 R2 e o 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 HTTP 2.0, e os usuários podem acessar serviços on-line, 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 Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension.

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

O recurso de 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 sendo executadas 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. Neste caso, o servidor não tem como saber de antemão 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 hospedar vários sites SSL em uma única combinação de protocolo de Internet e porta

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

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