Segurança da camada de transporte - Transport Layer Security

Suíte de protocolo de Internet
Camada de aplicação
BGP DHCP (v6) DNS FTP HTTP HTTPS IMAP LDAP MGCP MQTT NNTP NTP POP PTP ONC / RPC RTP RTSP RASGAR trago SMTP SNMP SSH Telnet TLS / SSL XMPP mais...
Camada de transporte
TCP UDP DCCP SCTP de RSVP mais...
Camada de Internet
IP IPv4 IPv6 ICMP (v6) ECN IGMP IPsec mais...
Camada de link
ARP NDP OSPF Túneis L2TP PPP MAC Ethernet Wi-fi DSL ISDN FDDI mais...
v t e

Transport Layer Security ( TLS ), o sucessor do agora obsoleto Secure Sockets Layer ( SSL ), é um protocolo criptográfico projetado para fornecer segurança de comunicação em uma rede de computadores. O protocolo é amplamente usado em aplicativos como e-mail , mensagens instantâneas e voz sobre IP , mas seu uso como camada de segurança em HTTPS continua sendo o mais publicamente visível.

O protocolo TLS visa principalmente fornecer privacidade e integridade de dados entre dois ou mais aplicativos de comunicação de computador. Ele roda na camada de aplicação da Internet e é ele próprio composto de duas camadas: o registro TLS e os protocolos de handshake TLS.

TLS é um padrão proposto pela Internet Engineering Task Force (IETF), definido pela primeira vez em 1999, e a versão atual é o TLS 1.3 definido em agosto de 2018. O TLS se baseia nas especificações SSL anteriores (1994, 1995, 1996) desenvolvidas pela Netscape Communications para adicionar o protocolo HTTPS para seu navegador da web Navigator .

Descrição

Os aplicativos cliente-servidor usam o protocolo TLS para se comunicar através de uma rede de uma forma projetada para evitar interceptação e violação .

Como os aplicativos podem se comunicar com ou sem TLS (ou SSL), é necessário que o cliente solicite que o servidor configure uma conexão TLS. Uma das principais maneiras de conseguir isso é usar um número de porta diferente para conexões TLS. Por exemplo, a porta 80 é normalmente usada para tráfego HTTP não criptografado , enquanto a porta 443 é a porta comum usada para tráfego HTTPS criptografado . Outro mecanismo é o cliente fazer uma solicitação específica de protocolo ao servidor para mudar a conexão para TLS; por exemplo, fazendo uma solicitação STARTTLS ao usar os protocolos de correio e notícias .

Depois que o cliente e o servidor concordam em usar o TLS, eles negociam uma conexão com estado usando um procedimento de handshaking . Os protocolos usam um handshake com uma cifra assimétrica para estabelecer não apenas as configurações de cifra, mas também uma chave compartilhada específica da sessão com a qual a comunicação posterior é criptografada usando uma cifra simétrica . Durante esse handshake, o cliente e o servidor concordam com vários parâmetros usados ​​para estabelecer a segurança da conexão:

• O handshake começa quando um cliente se conecta a um servidor habilitado para TLS solicitando uma conexão segura e o cliente apresenta uma lista de conjuntos de criptografia suportados ( cifras e funções hash ).
• Nessa lista, o servidor escolhe uma função de criptografia e hash que também oferece suporte e notifica o cliente sobre a decisão.
• O servidor geralmente fornece a identificação na forma de um certificado digital . O certificado contém o nome do servidor , a autoridade de certificação confiável (CA) que atesta a autenticidade do certificado e a chave de criptografia pública do servidor.
• O cliente confirma a validade do certificado antes de prosseguir.
• Para gerar as chaves de sessão usadas para a conexão segura, o cliente:
  • criptografa um número aleatório ( PreMasterSecret ) com a chave pública do servidor e envia o resultado para o servidor (que somente o servidor deve ser capaz de descriptografar com sua chave privada); ambas as partes usam o número aleatório para gerar uma chave de sessão exclusiva para criptografia e descriptografia subsequentes de dados durante a sessão
  • usa a troca de chaves Diffie – Hellman para gerar com segurança uma chave de sessão única e aleatória para criptografar e descriptografar que tem a propriedade adicional de sigilo de encaminhamento: se a chave privada do servidor for divulgada no futuro, ela não pode ser usada para descriptografar a sessão atual, mesmo que a sessão é interceptada e gravada por um terceiro.

Isso conclui o handshake e inicia a conexão segura, que é criptografada e descriptografada com a chave de sessão até que a conexão seja encerrada. Se qualquer uma das etapas acima falhar, o handshake TLS falhará e a conexão não será criada.

TLS e SSL não se encaixam perfeitamente em nenhuma camada do modelo OSI ou do modelo TCP / IP . O TLS é executado "em cima de algum protocolo de transporte confiável (por exemplo, TCP)", o que implicaria que ele está acima da camada de transporte . Ele serve de criptografia para camadas superiores, o que normalmente é a função da camada de apresentação . No entanto, os aplicativos geralmente usam o TLS como se fosse uma camada de transporte, embora os aplicativos que usam o TLS devam controlar ativamente o início dos handshakes TLS e o manuseio dos certificados de autenticação trocados.

Quando protegidas por TLS, as conexões entre um cliente (por exemplo, um navegador da web) e um servidor (por exemplo, wikipedia.org) devem ter uma ou mais das seguintes propriedades:

• A conexão é privada (ou segura ) porque um algoritmo de chave simétrica é usado para criptografar os dados transmitidos. As chaves para essa criptografia simétrica são geradas exclusivamente para cada conexão e são baseadas em um segredo compartilhado que foi negociado no início da sessão. O servidor e o cliente negociam os detalhes de qual algoritmo de criptografia e chaves criptográficas usar antes que o primeiro byte de dados seja transmitido (veja abaixo). A negociação de um segredo compartilhado é segura (o segredo negociado não está disponível para bisbilhoteiros e não pode ser obtido, mesmo por um invasor que se coloca no meio da conexão) e confiável (nenhum invasor pode modificar as comunicações durante a negociação sem ser detectou).
• A identidade das partes comunicantes pode ser autenticada usando criptografia de chave pública . Esta autenticação é necessária para o servidor e opcional para o cliente.
• A conexão é confiável porque cada mensagem transmitida inclui uma verificação de integridade da mensagem usando um código de autenticação de mensagem para evitar perda não detectada ou alteração dos dados durante a transmissão.

Além do acima, a configuração cuidadosa de TLS pode fornecer propriedades adicionais relacionadas à privacidade, como sigilo de encaminhamento , garantindo que qualquer divulgação futura de chaves de criptografia não possa ser usada para descriptografar qualquer comunicação TLS registrada no passado.

O TLS oferece suporte a muitos métodos diferentes para troca de chaves, criptografia de dados e autenticação da integridade da mensagem. Como resultado, a configuração segura de TLS envolve muitos parâmetros configuráveis ​​e nem todas as opções fornecem todas as propriedades relacionadas à privacidade descritas na lista acima (consulte as tabelas abaixo § Troca de chave , § Segurança de cifra e § Integridade de dados ).

Foram feitas tentativas de subverter os aspectos da segurança das comunicações que o TLS busca fornecer, e o protocolo foi revisado várias vezes para lidar com essas ameaças à segurança. Os desenvolvedores de navegadores da web revisaram repetidamente seus produtos para se defender contra possíveis falhas de segurança depois que elas foram descobertas (consulte o histórico de suporte TLS / SSL dos navegadores da web).

História e desenvolvimento

Protocolos SSL e TLS

Protocolo	Publicados	Status
SSL 1.0	Não publicado	Não publicado
SSL 2.0	1995	Obsoleto em 2011 ( RFC  6176 )
SSL 3.0	1996	Obsoleto em 2015 (RFC  7568 )
TLS 1.0	1999	Obsoleto em 2020 (RFC  8996 )
TLS 1.1	2006	Obsoleto em 2020 (RFC  8996 )
TLS 1.2	2008
TLS 1.3	2018

Sistema de rede de dados segura

O Protocolo de Segurança da Camada de Transporte (TLS), juntamente com várias outras plataformas básicas de segurança de rede, foi desenvolvido por meio de uma iniciativa conjunta iniciada em agosto de 1986, entre a Agência de Segurança Nacional, o Escritório Nacional de Padrões, a Agência de Comunicações de Defesa e doze comunicações e empresas de informática que iniciaram um projeto especial denominado Secure Data Network System (SDNS). O programa foi descrito em setembro de 1987 na 10ª Conferência Nacional de Segurança de Computadores em um extenso conjunto de artigos publicados. O programa de pesquisa inovador se concentrou em projetar a próxima geração de redes de comunicações de computador seguras e especificações de produtos a serem implementadas para aplicações em internets pública e privada. A intenção era complementar os novos padrões de Internet OSI emergentes, avançando tanto nos perfis GOSIP do governo dos EUA quanto no enorme esforço internacional de Internet ITU-ISO JTC1. Originalmente conhecido como protocolo SP4, foi renomeado como TLS e posteriormente publicado em 1995 como padrão internacional ITU-T X.274 | ISO / IEC 10736: 1995.

Programação de rede segura

Os primeiros esforços de pesquisa para a segurança da camada de transporte incluíram a interface de programação de aplicativo (API) Secure Network Programming (SNP) , que em 1993 explorou a abordagem de ter uma API de camada de transporte segura muito semelhante aos soquetes de Berkeley , para facilitar a adaptação de aplicativos de rede pré-existentes com segurança medidas.

SSL 1.0, 2.0 e 3.0

A Netscape desenvolveu os protocolos SSL originais e Taher Elgamal , cientista-chefe da Netscape Communications de 1995 a 1998, foi descrito como o "pai do SSL". O SSL versão 1.0 nunca foi lançado publicamente devido a sérias falhas de segurança no protocolo. A versão 2.0, após ser lançada em fevereiro de 1995, foi rapidamente descoberta por conter uma série de falhas de segurança e usabilidade. Ele usou as mesmas chaves criptográficas para autenticação e criptografia de mensagens. Ele tinha uma construção MAC fraca que usava a função hash MD5 com um prefixo secreto, tornando-o vulnerável a ataques de extensão de comprimento. E não forneceu proteção para o aperto de mão de abertura ou para o fechamento de uma mensagem explícita, ambos significando que ataques man-in-the-middle poderiam passar despercebidos. Além disso, o SSL 2.0 assumiu um único serviço e um certificado de domínio fixo, conflitando com o recurso amplamente utilizado de hospedagem virtual em servidores Web, de modo que a maioria dos sites foi efetivamente impedida de usar SSL.

Essas falhas exigiram o redesenho completo do protocolo para SSL versão 3.0. Lançado em 1996, foi produzido por Paul Kocher trabalhando com os engenheiros da Netscape Phil Karlton e Alan Freier, com uma implementação de referência por Christopher Allen e Tim Dierks da Consensus Development. As versões mais recentes de SSL / TLS são baseadas em SSL 3.0. O rascunho de 1996 do SSL 3.0 foi publicado pela IETF como um documento histórico no RFC  6101 .

SSL 2.0 foi preterido em 2011 pela RFC  6176 . Em 2014, SSL 3.0 foi considerado vulnerável ao ataque POODLE que afeta todas as cifras de bloco em SSL; RC4 , a única cifra sem bloco suportada pelo SSL 3.0, também pode ser quebrada conforme usada no SSL 3.0. SSL 3.0 foi preterido em junho de 2015 pela RFC  7568 .

TLS 1.0

O TLS 1.0 foi definido pela primeira vez no RFC  2246 em janeiro de 1999 como uma atualização do SSL Versão 3.0 e escrito por Christopher Allen e Tim Dierks da Consensus Development. Conforme declarado na RFC, "as diferenças entre este protocolo e o SSL 3.0 não são dramáticas, mas são significativas o suficiente para impedir a interoperabilidade entre o TLS 1.0 e o SSL 3.0". Tim Dierks escreveu mais tarde que essas mudanças, e a renomeação de "SSL" para "TLS", foram um gesto para salvar a face da Microsoft, "então não pareceria [que] a IETF estava apenas carimbando o protocolo da Netscape".

O PCI Council sugeriu que as organizações migrassem do TLS 1.0 para o TLS 1.1 ou superior antes de 30 de junho de 2018. Em outubro de 2018, Apple , Google , Microsoft e Mozilla anunciaram em conjunto que suspenderiam o uso do TLS 1.0 e 1.1 em março de 2020.

TLS 1.1

O TLS 1.1 foi definido no RFC  4346 em abril de 2006. É uma atualização do TLS versão 1.0. As diferenças significativas nesta versão incluem:

• Adicionada proteção contra ataques de encadeamento de blocos de criptografia (CBC).
  • O vetor de inicialização implícito (IV) foi substituído por um IV explícito.
  • Alteração no tratamento de erros de preenchimento .
• Suporte para registro de parâmetros da IANA .

O suporte para as versões 1.0 e 1.1 do TLS foi amplamente suspenso pelos sites por volta de 2020, desativando o acesso às versões do Firefox anteriores a 24 e ao Google Chrome antes de 29.

TLS 1.2

O TLS 1.2 foi definido no RFC  5246 em agosto de 2008. Ele se baseia na especificação anterior do TLS 1.1. As principais diferenças incluem:

• A combinação MD5 - SHA-1 na função pseudo - aleatória (PRF) foi substituída por SHA-256 , com uma opção para usar PRFs especificados por conjunto de criptografia.
• A combinação MD5 – SHA-1 no hash da mensagem finalizada foi substituída por SHA-256, com uma opção para usar algoritmos de hash específicos do conjunto de criptografia. No entanto, o tamanho do hash na mensagem finalizada ainda deve ser de pelo menos 96 bits .
• A combinação MD5 – SHA-1 no elemento assinado digitalmente foi substituída por um único hash negociado durante o handshake , cujo padrão é SHA-1.
• Aprimoramento na capacidade do cliente e do servidor de especificar quais hashes e algoritmos de assinatura eles aceitam.
• Expansão do suporte para criptografias de criptografia autenticadas , usadas principalmente para Galois / Counter Mode (GCM) e modo CCM de criptografia Advanced Encryption Standard (AES).
• Definição de extensões TLS e conjuntos de cifras AES foram adicionados.

Todas as versões TLS foram refinadas ainda mais no RFC  6176 em março de 2011, removendo sua compatibilidade com versões anteriores com SSL, de forma que as sessões TLS nunca negociem o uso de Secure Sockets Layer (SSL) versão 2.0.

TLS 1.3

O TLS 1.3 foi definido no RFC  8446 em agosto de 2018. Ele se baseia na especificação anterior do TLS 1.2. As principais diferenças do TLS 1.2 incluem:

• Separando o acordo de chave e algoritmos de autenticação dos conjuntos de criptografia
• Removendo o suporte para curvas elípticas nomeadas fracas e menos usadas
• Removendo o suporte para funções hash criptográficas MD5 e SHA-224
• Exigindo assinaturas digitais, mesmo quando uma configuração anterior é usada
• Integrando HKDF e a proposta DH semi-efêmera
• Substituindo a retomada por PSK e tíquetes
• Suporte para apertos de mão 1- RTT e suporte inicial para 0- RTT
• Obrigação de sigilo de encaminhamento perfeito , por meio do uso de chaves efêmeras durante o contrato de chave (EC) DH
• Descartando o suporte para muitos recursos inseguros ou obsoletos, incluindo compressão , renegociação, cifras não AEAD , troca de chave não PFS (entre as quais estão trocas de chaves RSA estáticas e DH estáticas ), grupos DHE personalizados , negociação de formato de ponto EC, protocolo Change Cipher Spec, Olá, mensagem, hora UNIX, e a entrada AD do campo de comprimento para cifras AEAD
• Proibindo a negociação SSL ou RC4 para compatibilidade com versões anteriores
• Integrando o uso de hash de sessão
• Suspensão do uso do número da versão da camada de registro e congelamento do número para compatibilidade aprimorada com versões anteriores
• Movendo alguns detalhes de algoritmos relacionados à segurança de um apêndice para a especificação e relegando ClientKeyShare para um apêndice
• Adicionando a cifra de fluxo ChaCha20 com o código de autenticação de mensagem Poly1305
• Adicionando os Ed25519 e Ed448 algoritmos de assinatura digital de
• Adicionando os x25519 e x448 protocolos de troca de chaves
• Adicionando suporte para o envio de várias respostas OCSP
• Criptografando todas as mensagens de handshake após o ServerHello

Network Security Services (NSS), a biblioteca de criptografia desenvolvida pela Mozilla e usada por seu navegador Firefox , habilitou o TLS 1.3 por padrão em fevereiro de 2017. O suporte TLS 1.3 foi adicionado posteriormente - mas devido a problemas de compatibilidade para um pequeno número de usuários, não habilitado automaticamente - para o Firefox 52.0 , lançado em março de 2017. O TLS 1.3 foi habilitado por padrão em maio de 2018 com o lançamento do Firefox 60.0 .

O Google Chrome definiu o TLS 1.3 como a versão padrão por um curto período de tempo em 2017. Em seguida, ele o removeu como padrão, devido a middleboxes incompatíveis, como proxies da web Blue Coat .

Durante o IETF 100 Hackathon que ocorreu em Cingapura em 2017, o The TLS Group trabalhou na adaptação de aplicativos de código aberto para usar o TLS 1.3. O grupo TLS era formado por indivíduos do Japão , Reino Unido e Maurício por meio da equipe cyberstorm.mu. Este trabalho teve continuidade no IETF 101 Hackathon em Londres e no IETF 102 Hackathon em Montreal.

wolfSSL habilitou o uso de TLS 1.3 a partir da versão 3.11.1, lançada em maio de 2017. Como a primeira implementação comercial de TLS 1.3, wolfSSL 3.11.1 suportava Draft 18 e agora suporta Draft 28, a versão final, bem como muitas versões anteriores . Uma série de blogs foi publicada sobre a diferença de desempenho entre TLS 1.2 e 1.3.

No Setembro de 2018, o popular projeto OpenSSL lançou a versão 1.1.1 de sua biblioteca, na qual o suporte para TLS 1.3 era "o novo recurso principal".

Segurança de transporte empresarial

A Electronic Frontier Foundation elogiou o TLS 1.3 e expressou preocupação com o protocolo variante Enterprise Transport Security (ETS), que intencionalmente desabilita medidas de segurança importantes no TLS 1.3. Originalmente denominado Enterprise TLS (eTLS), o ETS é um padrão publicado conhecido como 'ETSI TS103523-3', "Middlebox Security Protocol, Part3: Enterprise Transport Security". Ele deve ser usado inteiramente em redes proprietárias, como sistemas bancários. O ETS não oferece suporte ao sigilo direto para permitir que organizações terceirizadas conectadas às redes proprietárias possam usar sua chave privada para monitorar o tráfego da rede para a detecção de malware e para facilitar a realização de auditorias. Apesar dos benefícios alegados, a EFF alertou que a perda do sigilo direto poderia facilitar a exposição dos dados, além de dizer que existem maneiras melhores de analisar o tráfego.

Certificados digitais

Um certificado digital certifica a propriedade de uma chave pública pelo assunto nomeado do certificado e indica certos usos esperados dessa chave. Isso permite que outras pessoas (partes confiáveis) dependam de assinaturas ou asserções feitas pela chave privada que corresponde à chave pública certificada. Os keystores e trust stores podem estar em vários formatos, como .pem, .crt, .pfx e .jks.

Autoridades de certificação

O TLS normalmente depende de um conjunto de autoridades de certificação terceirizadas confiáveis ​​para estabelecer a autenticidade dos certificados. A confiança geralmente é ancorada em uma lista de certificados distribuídos com o software do agente do usuário e pode ser modificada pela parte confiável.

De acordo com a Netcraft , que monitora certificados TLS ativos, a autoridade de certificação (CA) líder de mercado é a Symantec desde o início da pesquisa (ou a VeriSign antes da unidade de negócios de serviços de autenticação ser adquirida pela Symantec). Em 2015, a Symantec respondia por pouco menos de um terço de todos os certificados e 44% dos certificados válidos usados ​​pelos 1 milhão de sites mais movimentados, conforme contabilizado pela Netcraft. Em 2017, a Symantec vendeu seu negócio TLS / SSL para a DigiCert. Em um relatório atualizado, foi mostrado que IdenTrust , DigiCert e Sectigo são as 3 principais autoridades de certificação em termos de participação de mercado desde maio de 2019.

Como consequência da escolha dos certificados X.509 , as autoridades de certificação e uma infraestrutura de chave pública são necessárias para verificar a relação entre um certificado e seu proprietário, bem como para gerar, assinar e administrar a validade dos certificados. Embora isso possa ser mais conveniente do que verificar as identidades por meio de uma rede de confiança , as divulgações de vigilância em massa de 2013 tornaram mais conhecido que as autoridades de certificação são um ponto fraco do ponto de vista de segurança, permitindo ataques man-in-the-middle (MITM) se a autoridade de certificação cooperar (ou estiver comprometida).

Algoritmos

Troca de chave ou acordo de chave

Antes que um cliente e servidor possam começar a trocar informações protegidas por TLS, eles devem trocar ou concordar com segurança sobre uma chave de criptografia e uma cifra para usar ao criptografar dados (consulte § Cifra ). Entre os métodos usados ​​para troca / acordo de chave estão: chaves públicas e privadas geradas com RSA (denotado por TLS_RSA no protocolo de handshake TLS), Diffie – Hellman (TLS_DH), efêmero Diffie – Hellman (TLS_DHE), curva elíptica Diffie – Hellman ( TLS_ECDH), curva elíptica efêmera Diffie – Hellman (TLS_ECDHE), Diffie – Hellman anônimo (TLS_DH_anon), chave pré-compartilhada (TLS_PSK) e Senha remota segura (TLS_SRP).

Os métodos de acordo de chave TLS_DH_anon e TLS_ECDH_anon não autenticam o servidor ou o usuário e, portanto, são raramente usados ​​porque são vulneráveis ​​a ataques man-in-the-middle . Apenas TLS_DHE e TLS_ECDHE fornecem sigilo de encaminhamento .

Os certificados de chave pública usados ​​durante a troca / acordo também variam no tamanho das chaves de criptografia públicas / privadas usadas durante a troca e, portanto, na robustez da segurança fornecida. Em julho de 2013, o Google anunciou que não usaria mais chaves públicas de 1024 bits e mudaria para chaves de 2048 bits para aumentar a segurança da criptografia TLS que fornece a seus usuários porque a força da criptografia está diretamente relacionada ao tamanho da chave .

Troca / acordo e autenticação de chaves

Algoritmo	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	Status
RSA	sim	sim	sim	sim	sim	Não	Definido para TLS 1.2 em RFCs
DH - RSA	Não	sim	sim	sim	sim	Não
DHE - RSA ( sigilo de encaminhamento )	Não	sim	sim	sim	sim	sim
ECDH - RSA	Não	Não	sim	sim	sim	Não
ECDHE - RSA (sigilo de encaminhamento)	Não	Não	sim	sim	sim	sim
DH - DSS	Não	sim	sim	sim	sim	Não
DHE - DSS (sigilo de encaminhamento)	Não	sim	sim	sim	sim	Não
ECDH - ECDSA	Não	Não	sim	sim	sim	Não
ECDHE - ECDSA (sigilo de encaminhamento)	Não	Não	sim	sim	sim	sim
ECDH - EdDSA	Não	Não	sim	sim	sim	Não
ECDHE - EdDSA (sigilo de encaminhamento)	Não	Não	sim	sim	sim	sim
PSK	Não	Não	sim	sim	sim
PSK - RSA	Não	Não	sim	sim	sim
DHE - PSK (sigilo de encaminhamento)	Não	Não	sim	sim	sim	sim
ECDHE - PSK (sigilo de encaminhamento)	Não	Não	sim	sim	sim	sim
SRP	Não	Não	sim	sim	sim
SRP - DSS	Não	Não	sim	sim	sim
SRP - RSA	Não	Não	sim	sim	sim
Kerberos	Não	Não	sim	sim	sim
DH -ANON (inseguro)	Não	sim	sim	sim	sim
ECDH -ANON (inseguro)	Não	Não	sim	sim	sim
GOST R 34.10-94 / 34.10-2001	Não	Não	sim	sim	sim		Proposto em rascunhos de RFC

Cifra

Segurança de criptografia contra ataques viáveis ​​publicamente conhecidos

Cifra			Versão do protocolo						Status
Modelo	Algoritmo	Força nominal (bits)	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
Bloquear cifra com modo de operação	AES GCM	256, 128	N / D	N / D	N / D	N / D	Seguro	Seguro	Definido para TLS 1.2 em RFCs
	AES CCM		N / D	N / D	N / D	N / D	Seguro	Seguro
	AES CBC		N / D	Inseguro	Depende de mitigações	Depende de mitigações	Depende de mitigações	N / D
	Camélia GCM	256, 128	N / D	N / D	N / D	N / D	Seguro	N / D
	Camélia CBC		N / D	Inseguro	Depende de mitigações	Depende de mitigações	Depende de mitigações	N / D
	ARIA GCM	256, 128	N / D	N / D	N / D	N / D	Seguro	N / D
	ARIA CBC		N / D	N / D	Depende de mitigações	Depende de mitigações	Depende de mitigações	N / D
	SEED CBC	128	N / D	Inseguro	Depende de mitigações	Depende de mitigações	Depende de mitigações	N / D
	3DES EDE CBC	112	Inseguro	Inseguro	Inseguro	Inseguro	Inseguro	N / D
	GOST 28147-89 CNT	256	N / D	N / D	Inseguro	Inseguro	Inseguro	N / D	Definido em RFC  4357
	IDÉIA CBC	128	Inseguro	Inseguro	Inseguro	Inseguro	N / D	N / D	Removido de TLS 1.2
	DES CBC	056	Inseguro	Inseguro	Inseguro	Inseguro	N / D	N / D
		040	Inseguro	Inseguro	Inseguro	N / D	N / D	N / D	Proibido em TLS 1.1 e posterior
	RC2 CBC	040	Inseguro	Inseguro	Inseguro	N / D	N / D	N / D
Cifra de fluxo	ChaCha20 - Poly1305	256	N / D	N / D	N / D	N / D	Seguro	Seguro	Definido para TLS 1.2 em RFCs
	RC4	128	Inseguro	Inseguro	Inseguro	Inseguro	Inseguro	N / D	Proibido em todas as versões de TLS pela RFC  7465
		040	Inseguro	Inseguro	Inseguro	N / D	N / D	N / D
Nenhum	Nulo	-	Inseguro	Inseguro	Inseguro	Inseguro	Inseguro	N / D	Definido para TLS 1.2 em RFCs

Notas

Integridade de dados

Um código de autenticação de mensagem (MAC) é usado para integridade de dados. HMAC é usado para o modo CBC de cifras de bloco. A criptografia autenticada (AEAD), como o modo GCM e o modo CCM, usa o MAC integrado ao AEAD e não usa HMAC . PRF baseado em HMAC ou HKDF é usado para handshake TLS.

Integridade de dados

Algoritmo	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	Status
HMAC - MD5	sim	sim	sim	sim	sim	Não	Definido para TLS 1.2 em RFCs
HMAC - SHA1	Não	sim	sim	sim	sim	Não
HMAC - SHA256 / 384	Não	Não	Não	Não	sim	Não
AEAD	Não	Não	Não	Não	sim	sim
GOST 28147-89 IMIT	Não	Não	sim	sim	sim		Proposto em rascunhos de RFC
GOST R 34.11-94	Não	Não	sim	sim	sim

Aplicações e adoção

No design de aplicativos, o TLS é geralmente implementado sobre os protocolos da camada de transporte, criptografando todos os dados relacionados ao protocolo de protocolos como HTTP , FTP , SMTP , NNTP e XMPP .

Historicamente, o TLS tem sido usado principalmente com protocolos de transporte confiáveis, como o Transmission Control Protocol (TCP). No entanto, também foi implementado com protocolos de transporte orientados a datagramas, como o User Datagram Protocol (UDP) e o Datagram Congestion Control Protocol (DCCP), cujo uso foi padronizado independentemente usando o termo Datagram Transport Layer Security (DTLS) .

Sites

O principal uso do TLS é proteger o tráfego da World Wide Web entre um site da Web e um navegador da Web codificado com o protocolo HTTP. Esse uso de TLS para proteger o tráfego HTTP constitui o protocolo HTTPS .

Suporte ao protocolo do site (setembro de 2021)

Versão do protocolo	Suporte do site	Segurança
SSL 2.0	0,4%	Inseguro
SSL 3.0	3,1%	Inseguro
TLS 1.0	44,0%	Descontinuada
TLS 1.1	48,1%	Descontinuada
TLS 1.2	99,6%	Depende de criptografia e mitigações de cliente
TLS 1.3	48,9%	Seguro

Notas

Navegadores da web

A partir de abril de 2016, as versões mais recentes de todos os principais navegadores da web são compatíveis com TLS 1.0, 1.1 e 1.2 e os ativam por padrão. No entanto, nem todos os sistemas operacionais da Microsoft com suporte são compatíveis com a versão mais recente do IE. Além disso, muitos sistemas operacionais atualmente oferecem suporte a várias versões do IE, mas isso mudou de acordo com as Perguntas frequentes da Política de Ciclo de Vida de Suporte do Internet Explorer ", a partir de 12 de janeiro de 2016, apenas a versão mais atual do Internet Explorer disponível para um sistema operacional compatível receberá informações técnicas suporte e atualizações de segurança. " A página prossegue, listando a versão mais recente do IE com suporte naquela data para cada sistema operacional. A próxima data crítica seria quando um sistema operacional atinge o estágio de fim de vida, que está na ficha técnica do ciclo de vida do Windows da Microsoft .

As atenuações contra ataques conhecidos ainda não são suficientes:

• Mitigações contra o ataque POODLE : alguns navegadores já evitam o fallback para SSL 3.0; no entanto, essa atenuação precisa ser suportada não apenas por clientes, mas também por servidores. A desativação do próprio SSL 3.0, a implementação de "divisão de registro anti-POODLE" ou a negação de cifras CBC no SSL 3.0 é necessária.
  • Google Chrome: completo (TLS_FALLBACK_SCSV é implementado desde a versão 33, fallback para SSL 3.0 está desativado desde a versão 39, SSL 3.0 em si está desativado por padrão desde a versão 40. O suporte do próprio SSL 3.0 foi abandonado desde a versão 44.)
  • Mozilla Firefox: completo (o suporte do próprio SSL 3.0 foi eliminado desde a versão 39. O próprio SSL 3.0 está desabilitado por padrão e o fallback para SSL 3.0 está desabilitado desde a versão 34 , TLS_FALLBACK_SCSV é implementado desde a versão 35. No ESR, o próprio SSL 3.0 é desabilitado por padrão e TLS_FALLBACK_SCSV é implementado desde ESR 31.3.)
  • Internet Explorer: parcial (apenas na versão 11, SSL 3.0 está desativado por padrão desde abril de 2015. A versão 10 e anteriores ainda são vulneráveis ​​ao POODLE).
  • Opera : complete (TLS_FALLBACK_SCSV é implementado desde a versão 20, "divisão de registro anti-POODLE", que é eficaz apenas com implementação do lado do cliente, é implementado desde a versão 25, SSL 3.0 em si é desativado por padrão desde a versão 27. Suporte de SSL 3.0 em si será descartado desde a versão 31.)
  • Safari: completo (apenas no OS X 10.8 e posterior e no iOS 8, cifras CBC durante o fallback para SSL 3.0 são negadas, mas isso significa que usará RC4, o que também não é recomendado. O suporte do próprio SSL 3.0 foi retirado no OS X 10.11 e posterior e iOS 9.)
• Mitigação contra ataques RC4 :
  • O Google Chrome desativou o RC4, exceto como substituto desde a versão 43. O RC4 está desativado desde o Chrome 48.
  • O Firefox desabilitou o RC4, exceto como um fallback desde a versão 36. O Firefox 44 desabilitou o RC4 por padrão.
  • O Opera desabilitou o RC4, exceto como um fallback desde a versão 30. O RC4 está desabilitado desde o Opera 35.
  • O Internet Explorer para Windows 7 / Server 2008 R2 e para Windows 8 / Server 2012 definiu a prioridade de RC4 para a mais baixa e também pode desabilitar RC4, exceto como um fallback por meio das configurações do registro. O Internet Explorer 11 Mobile 11 para Windows Phone 8.1 desabilita o RC4, exceto como fallback se nenhum outro algoritmo habilitado funcionar. O Edge e o IE 11 desabilitaram o RC4 completamente em agosto de 2016.
• Mitigação contra ataque FREAK :
  • O navegador Android incluído no Android 4.0 e mais antigo ainda é vulnerável ao ataque FREAK.
  • O Internet Explorer 11 Mobile ainda é vulnerável ao ataque FREAK.
  • Google Chrome, Internet Explorer (desktop), Safari (desktop e celular) e Opera (celular) têm atenuações FREAK em vigor.
  • O Mozilla Firefox em todas as plataformas e o Google Chrome no Windows não foram afetados pelo FREAK.

Histórico de suporte TLS / SSL de navegadores da web

Navegador	Versão		Plataformas	Protocolos SSL		Protocolos TLS				Suporte de certificado			Vulnerabilidades corrigidas						Seleção de protocolo pelo usuário
				SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	EV	SHA-2	ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam
Google Chrome ( Chrome para Android )	1-9		Windows  (7+) macOS  (10.11+) Linux Android  (5.0+) iOS  (12.2+) Chrome OS	Desativado por padrão	Ativado por padrão	sim	Não	Não	Não	Sim (apenas desktop)	precisa de sistema operacional compatível com SHA-2	precisa de sistema operacional compatível com ECC	Não afetado	Vulnerável (HTTPS)	Vulnerável	Vulnerável	Vulnerável (exceto Windows)	Vulnerável	sim
	10-20			Não	Ativado por padrão	sim	Não	Não	Não	Sim (apenas desktop)	precisa de sistema operacional compatível com SHA-2	precisa de sistema operacional compatível com ECC	Não afetado	Vulnerável (HTTPS / SPDY)	Vulnerável	Vulnerável	Vulnerável (exceto Windows)	Vulnerável	sim
	21			Não	Ativado por padrão	sim	Não	Não	Não	Sim (apenas desktop)	precisa de sistema operacional compatível com SHA-2	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Vulnerável	Vulnerável	Vulnerável (exceto Windows)	Vulnerável	sim
	22-29			Não	Ativado por padrão	sim	sim	Não	Não	Sim (apenas desktop)	precisa de sistema operacional compatível com SHA-2	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Vulnerável	Vulnerável	Vulnerável (exceto Windows)	Vulnerável	Temporário
	30-32			Não	Ativado por padrão	sim	sim	Sim	Não	Sim (apenas desktop)	precisa de sistema operacional compatível com SHA-2	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Vulnerável	Vulnerável	Vulnerável (exceto Windows)	Vulnerável	Temporário
	33–37			Não	Ativado por padrão	sim	sim	sim	Não	Sim (apenas desktop)	precisa de sistema operacional compatível com SHA-2	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Parcialmente mitigado	Prioridade mais baixa	Vulnerável (exceto Windows)	Vulnerável	Temporário
	38, 39			Não	Ativado por padrão	sim	sim	sim	Não	Sim (apenas desktop)	sim	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Parcialmente mitigado	Prioridade mais baixa	Vulnerável (exceto Windows)	Vulnerável	Temporário
	40			Não	Desativado por padrão	sim	sim	sim	Não	Sim (apenas desktop)	sim	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Mitigado	Prioridade mais baixa	Vulnerável (exceto Windows)	Vulnerável	sim
	41, 42			Não	Desativado por padrão	sim	sim	sim	Não	Sim (apenas desktop)	sim	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Mitigado	Prioridade mais baixa	Mitigado	Vulnerável	sim
	43			Não	Desativado por padrão	sim	sim	sim	Não	Sim (apenas desktop)	sim	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Mitigado	Apenas como reserva	Mitigado	Vulnerável	sim
	44-47			Não	Não	sim	sim	sim	Não	Sim (apenas desktop)	sim	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Não afetado	Apenas como reserva	Mitigado	Mitigado	Temporário
	48, 49			Não	Não	sim	sim	sim	Não	Sim (apenas desktop)	sim	precisa de sistema operacional compatível com ECC	Não afetado	Mitigado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Temporário
	50–53			Não	Não	sim	sim	sim	Não	Sim (apenas desktop)	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Temporário
	54-66			Não	Não	sim	sim	sim	Desativado por padrão (versão de rascunho)	Sim (apenas desktop)	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Temporário
	67-69			Não	Não	sim	sim	sim	Sim (versão de rascunho)	Sim (apenas desktop)	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Temporário
	70-83			Não	Não	sim	sim	sim	sim	Sim (apenas desktop)	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Temporário
	84-90			Não	Não	Avisar por padrão	Avisar por padrão	sim	sim	Sim (apenas desktop)	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Temporário
	91-93	94		Não	Não	Não	Não	sim	sim	Sim (apenas desktop)	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Temporário
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	Certificado EV	Certificado SHA-2	Certificado ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário
Independente do sistema operacional Microsoft Edge (baseado em Chromium)	79–83		Windows  (7+) macOS  (10.12+) Linux  Android  (4.4+) iOS  (11.0+)	Não	Não	sim	sim	sim	sim	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	sim
	84-90			Não	Não	Avisar por padrão	Avisar por padrão	sim	sim	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	sim
	91-93	94		Não	Não	Não	Não	sim	sim	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	sim
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	Certificado EV	Certificado SHA-2	Certificado ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário
Mozilla Firefox ( Firefox para celular )	1.0, 1.5		Windows  (7+) macOS  (10.12+) Linux Android  (5.0+) iOS (11.4+) Firefox OS Maemo ESR apenas para: Windows  (7+) macOS  (10.9+) Linux	Ativado por padrão	Ativado por padrão	sim	Não	Não	Não	Não	sim	Não	Não afetado	Não afetado	Vulnerável	Vulnerável	Não afetado	Vulnerável	sim
	2			Desativado por padrão	Ativado por padrão	sim	Não	Não	Não	Não	sim	sim	Não afetado	Não afetado	Vulnerável	Vulnerável	Não afetado	Vulnerável	sim
	3-7			Desativado por padrão	Ativado por padrão	sim	Não	Não	Não	sim	sim	sim	Não afetado	Não afetado	Vulnerável	Vulnerável	Não afetado	Vulnerável	sim
	8–10 ESR 10			Não	Ativado por padrão	sim	Não	Não	Não	sim	sim	sim	Não afetado	Não afetado	Vulnerável	Vulnerável	Não afetado	Vulnerável	sim
	11-14			Não	Ativado por padrão	sim	Não	Não	Não	sim	sim	sim	Não afetado	Vulnerável (SPDY)	Vulnerável	Vulnerável	Não afetado	Vulnerável	sim
	15–22 ESR 17.0–17.0.10			Não	Ativado por padrão	sim	Não	Não	Não	sim	sim	sim	Não afetado	Mitigado	Vulnerável	Vulnerável	Não afetado	Vulnerável	sim
	ESR 17.0.11			Não	Ativado por padrão	sim	Não	Não	Não	sim	sim	sim	Não afetado	Mitigado	Vulnerável	Prioridade mais baixa	Não afetado	Vulnerável	sim
	23			Não	Ativado por padrão	sim	Desativado por padrão	Não	Não	sim	sim	sim	Não afetado	Mitigado	Vulnerável	Vulnerável	Não afetado	Vulnerável	sim
	24, 25.0.0 ESR 24.0-24.1.0			Não	Ativado por padrão	sim	Desativado por padrão	Desativado por padrão	Não	sim	sim	sim	Não afetado	Mitigado	Vulnerável	Vulnerável	Não afetado	Vulnerável	sim
	25.0.1, 26 ESR 24.1.1			Não	Ativado por padrão	sim	Desativado por padrão	Desativado por padrão	Não	sim	sim	sim	Não afetado	Mitigado	Vulnerável	Prioridade mais baixa	Não afetado	Vulnerável	sim
	27-33 ESR 31,0-31,2			Não	Ativado por padrão	sim	Sim	Sim	Não	sim	sim	sim	Não afetado	Mitigado	Vulnerável	Prioridade mais baixa	Não afetado	Vulnerável	sim
	34, 35 ESR 31,3-31,7			Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Não afetado	Mitigado	Mitigado	Prioridade mais baixa	Não afetado	Vulnerável	sim
	ESR 31.8			Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Não afetado	Mitigado	Mitigado	Prioridade mais baixa	Não afetado	Mitigado	sim
	36–38 ESR 38.0			Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Não afetado	Mitigado	Mitigado	Apenas como reserva	Não afetado	Vulnerável	sim
	ESR 38,1-38,8			Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Não afetado	Mitigado	Mitigado	Apenas como reserva	Não afetado	Mitigado	sim
	39-43			Não	Não	sim	sim	sim	Não	sim	sim	sim	Não afetado	Mitigado	Não afetado	Apenas como reserva	Não afetado	Mitigado	sim
	44-48 ESR 45			Não	Não	sim	sim	sim	Não	sim	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Não afetado	Mitigado	sim
	49-59 ESR 52			Não	Não	sim	sim	sim	Desativada por padrão (versão preliminar)	sim	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Não afetado	Mitigado	sim
	60-62 ESR 60			Não	Não	sim	sim	sim	Sim (versão de rascunho)	sim	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Não afetado	Mitigado	sim
	63-77 ESR 68			Não	Não	sim	sim	sim	sim	sim	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Não afetado	Mitigado	sim
	78-92 ESR 78,0-78,14 ESR 91,0-91,1			Não	Não	Desativado por padrão	Desativado por padrão	sim	sim	sim	sim	sim	Não afetado	Mitigado	Não afetado	Desativado por padrão	Não afetado	Mitigado	sim
	ESR 78,15 ESR 91,2	93
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	Certificado EV	Certificado SHA-2	Certificado ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário
Microsoft Internet Explorer (1–10)	1.x		Windows 3.1 , 95 , NT , Mac OS 7 , 8	Sem suporte SSL / TLS
	2			sim	Não	Não	Não	Não	Não	Não	Não	Não	Sem suporte SSL 3.0 ou TLS			Vulnerável	Vulnerável	Vulnerável	N / D
	3			sim	sim	Não	Não	Não	Não	Não	Não	Não	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Desconhecido
	4 , 5 , 6		Windows 3.1 , 95 , 98 , NT , 2000 Mac OS 7.1 , 8 , X , Solaris , HP-UX	Ativado por padrão	Ativado por padrão	Desativado por padrão	Não	Não	Não	Não	Não	Não	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	sim
	6		Windows XP	Ativado por padrão	Ativado por padrão	Desativado por padrão	Não	Não	Não	Não	sim	Não	Mitigado	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	sim
	7 , 8			Desativado por padrão	Ativado por padrão	sim	Não	Não	Não	sim	sim	Não	Mitigado	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	sim
	6		Server 2003	Ativado por padrão	Ativado por padrão	Desativado por padrão	Não	Não	Não	Não	sim	Não	Mitigado	Não afetado	Vulnerável	Vulnerável	Mitigado	Mitigado	sim
	7 , 8			Desativado por padrão	Ativado por padrão	sim	Não	Não	Não	sim	sim	Não	Mitigado	Não afetado	Vulnerável	Vulnerável	Mitigado	Mitigado	sim
	7 , 8 , 9		Windows Vista	Desativado por padrão	Ativado por padrão	sim	Não	Não	Não	sim	sim	sim	Mitigado	Não afetado	Vulnerável	Vulnerável	Mitigado	Mitigado	sim
	7 , 8 , 9		Server 2008	Desativado por padrão	Ativado por padrão	sim	Desativada por padrão (KB4019276)	Desativada por padrão (KB4019276)	Não	sim	sim	sim	Mitigado	Não afetado	Vulnerável	Vulnerável	Mitigado	Mitigado	sim
	8 , 9 , 10		O Windows 7 / 8 Servidor 2008 R2 / 2012	Desativado por padrão	Ativado por padrão	sim	Desativado por padrão	Desativado por padrão	Não	sim	sim	sim	Mitigado	Não afetado	Vulnerável	Prioridade mais baixa	Mitigado	Mitigado	sim
Internet Explorer 11	11		Windows 7 Server 2008 R2	Desativado por padrão	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows 8.1	Desativado por padrão	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
			Server 2012 Server 2012 R2
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	Certificado EV	Certificado SHA-2	Certificado ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário
Microsoft Edge (12–18) (baseado em EdgeHTML) Cliente apenas Internet Explorer 11	11	12-13	Windows 10 1507-1511	Desativado por padrão	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11	14-18 (apenas cliente)	Windows 10 1607–1909 Windows Server (SAC) 1709–1909	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11	18 (apenas cliente)	Windows 10 2004 Windows Server (SAC) 2004	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
Internet Explorer 11	11		Windows 10 20H2 Windows Server (SAC) 20H2	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows 10 21H1	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows 10 21H2	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows 11	Não	Desativado por padrão	sim	sim	sim	sim	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
Versões LTSC do Internet Explorer 11	11		Windows 10 LTSB 2015 (1507)	Desativado por padrão	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows 10 LTSB 2016 (1607)	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows Server 2016 (LTSB / 1607)	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows 10 LTSC 2019 (1809) Windows Server 2019 (LTSC / 1809)	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows 10 LTSC 2022 (21H2)	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
	11		Windows Server 2022 (LTSC / 21H2)	Não	Desativado por padrão	sim	sim	sim	sim	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	sim
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	Certificado EV	Certificado SHA-2	Certificado ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário
Microsoft Internet Explorer Mobile	7, 9		Windows Phone 7, 7.5, 7.8	Desativado por padrão	Ativado por padrão	sim	Não	Não	Não	Não	sim	sim	Desconhecido	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Apenas com ferramentas de terceiros
	10		Windows Phone 8	Desativado por padrão	Ativado por padrão	sim	Desativado por padrão	Desativado por padrão	Não	Não	sim	sim	Mitigado	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Apenas com ferramentas de terceiros
	11		Windows Phone 8.1	Desativado por padrão	Ativado por padrão	sim	sim	sim	Não	Não	sim	sim	Mitigado	Não afetado	Vulnerável	Apenas como reserva	Vulnerável	Vulnerável	Apenas com ferramentas de terceiros
Microsoft Edge (13–15) (baseado em EdgeHTML)	13		Windows 10 Mobile 1511	Desativado por padrão	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	Não
	14, 15		Windows 10 Mobile 1607-1709	Não	Desativado por padrão	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Desativado por padrão	Mitigado	Mitigado	Não
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	Certificado EV	Certificado SHA-2	Certificado ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário
Apple Safari	1		Mac OS X 10.2 , 10.3	Não	sim	sim	Não	Não	Não	Não	Não	Não	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	2-5		Mac OS X 10.4 , 10.5 , Win XP	Não	sim	sim	Não	Não	Não	desde v3.2	Não	Não	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	3-5		Vista , Win 7	Não	sim	sim	Não	Não	Não	desde v3.2	Não	sim	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	4-6		Mac OS X 10.6 , 10.7	Não	sim	sim	Não	Não	Não	sim	sim	sim	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	6		OS X 10.8	Não	sim	sim	Não	Não	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Vulnerável	Mitigado	Vulnerável	Não
	7, 9		OS X 10.9	Não	sim	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Vulnerável	Mitigado	Vulnerável	Não
	8-10		OS X 10.10	Não	sim	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Prioridade mais baixa	Mitigado	Mitigado	Não
	9-11		OS X 10.11	Não	Não	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Não afetado	Prioridade mais baixa	Mitigado	Mitigado	Não
	10–13		macOS 10.12 , 10.13	Não	Não	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	12, 13	14	macOS 10.14	Não	Não	sim	sim	sim	Sim (desde o macOS 10.14.4)	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	13, 14	15	macOS 10.15	Não	Não	sim	sim	sim	sim	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	14	15	macOS 11	Não	Não	sim	sim	sim	sim	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	15		macOS 12	Não	Não	sim	sim	sim	sim	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	Certificado EV	Certificado SHA-2	Certificado ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário
Apple Safari (celular)	3		iPhone OS 1 , 2	Não	sim	sim	Não	Não	Não	Não	Não	Não	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	4, 5		iPhone OS 3 , iOS 4	Não	sim	sim	Não	Não	Não	sim	sim	desde iOS 4	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	5, 6		iOS 5 , 6	Não	sim	sim	sim	sim	Não	sim	sim	sim	Vulnerável	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	7		iOS 7	Não	sim	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	8		iOS 8	Não	sim	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Mitigado	Prioridade mais baixa	Mitigado	Mitigado	Não
	9		iOS 9	Não	Não	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Não afetado	Prioridade mais baixa	Mitigado	Mitigado	Não
	10, 11		iOS 10 , 11	Não	Não	sim	sim	sim	Não	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	12		iOS 12	Não	Não	sim	sim	sim	Sim (desde iOS 12.2)	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	13, 14		iOS 13 , 14	Não	Não	sim	sim	sim	sim	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
			iPadOS 13, 14
	15		iOS 15	Não	Não	sim	sim	sim	sim	sim	sim	sim	Mitigado	Não afetado	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
			iPadOS 15
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	EV	SHA-2	ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário
SO Google Android	Android 1.0-4.0.4			Não	Ativado por padrão	sim	Não	Não	Não	Desconhecido	sim	desde 3.0	Desconhecido	Desconhecido	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	Android 4.1-4.4.4			Não	Ativado por padrão	sim	Desativado por padrão	Desativado por padrão	Não	Desconhecido	sim	sim	Desconhecido	Desconhecido	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	Android 5.0-5.0.2			Não	Ativado por padrão	sim	sim	sim	Não	Desconhecido	sim	sim	Desconhecido	Desconhecido	Vulnerável	Vulnerável	Vulnerável	Vulnerável	Não
	Android 5.1-5.1.1			Não	Desativado por padrão	sim	sim	sim	Não	Desconhecido	sim	sim	Desconhecido	Desconhecido	Não afetado	Apenas como reserva	Mitigado	Mitigado	Não
	Android 6.0 - 7.1.2			Não	Desativado por padrão	sim	sim	sim	Não	Desconhecido	sim	sim	Desconhecido	Desconhecido	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	Android 8.0			Não	Não	sim	sim	sim	Não	Desconhecido	sim	sim	Desconhecido	Desconhecido	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	Android 8.1 - 9			Não	Não	sim	sim	sim	Não	Desconhecido	sim	sim	Desconhecido	Desconhecido	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	Android 10			Não	Não	sim	sim	sim	sim	Desconhecido	sim	sim	Desconhecido	Desconhecido	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	Android 11			Não	Não	sim	sim	sim	sim	Desconhecido	sim	sim	Desconhecido	Desconhecido	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
	Android 12			Não	Não	Desconhecido	Desconhecido	sim	sim	Desconhecido	sim	sim	Desconhecido	Desconhecido	Não afetado	Desativado por padrão	Mitigado	Mitigado	Não
Navegador	Versão		Plataformas	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0 (obsoleto)	TLS 1.1 (obsoleto)	TLS 1.2	TLS 1.3	Certificado EV	Certificado SHA-2	Certificado ECDSA	FERA	CRIME	POODLE (SSLv3)	RC4	DOIDO	Logjam	Seleção de protocolo pelo usuário

Cor ou nota		Significado
Versão do navegador	Plataforma
Versão do navegador	Sistema operacional	Versão futura; em desenvolvimento
Versão do navegador	Sistema operacional	Versão mais recente atual
Versão do navegador	Sistema operacional	Versão anterior; ainda suportado
Versão do navegador	Sistema operacional	Versão anterior; suporte de longo prazo ainda ativo, mas terminará em menos de 12 meses
Versão do navegador	Sistema operacional	Versão anterior; Não mais suportado
n / D	Sistema operacional	Misto / Não Especificado
	Sistema operacional (versão +)	Versão mínima exigida do sistema operacional (para versões compatíveis do navegador)
	Sistema operacional	Não é mais compatível com este sistema operacional

Notas

Bibliotecas

A maioria das bibliotecas de programação SSL e TLS são softwares gratuitos e de código aberto .

• BoringSSL , um fork do OpenSSL para Chrome / Chromium e Android, bem como outros aplicativos do Google.
• Botan , uma biblioteca criptográfica licenciada por BSD escrita em C ++.
• BSAFE Micro Edition Suite: uma implementação multiplataforma de TLS escrito em C usando um módulo criptográfico validado por FIPS
• BSAFE SSL-J: uma biblioteca TLS que fornece uma API proprietária e uma API JSSE , usando módulo criptográfico validado por FIPS
• cryptlib : uma biblioteca de criptografia de código aberto portátil (inclui implementação TLS / SSL)
• Os programadores Delphi podem usar uma biblioteca chamada Indy que utiliza OpenSSL ou, alternativamente, ICS que suporta TLS 1.3 agora.
• GnuTLS : uma implementação gratuita (com licença LGPL)
• Java Secure Socket Extension : uma implementação Java incluída no Java Runtime Environment suportava TLS 1.1 e 1.2 começando com Java 7. (TLS 1.1 / 1.2 foram inicialmente desativados por padrão para o cliente em Java 7, mas foram ativados em janeiro de 2017). Java 11 suporta TLS 1.3.
• LibreSSL : um fork do OpenSSL pelo projeto OpenBSD.
• MatrixSSL : uma implementação com licença dupla
• mbed TLS (anteriormente PolarSSL): uma pequena implementação de biblioteca SSL para dispositivos incorporados que é projetada para ser fácil de usar
• Serviços de segurança de rede : biblioteca de código aberto validada FIPS 140
• OpenSSL : uma implementação gratuita (licença BSD com algumas extensões)
• SChannel : uma implementação de SSL e TLS Microsoft Windows como parte de seu pacote.
• Transporte seguro : uma implementação de SSL e TLS usado no OS X e iOS como parte de seus pacotes.
• wolfSSL (anteriormente CyaSSL): Biblioteca SSL / TLS incorporada com um forte foco em velocidade e tamanho.

Suporte de biblioteca para TLS / SSL

Implementação	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
Botan	Não	Não	sim	sim	sim
Suite BSAFE Micro Edition	Não	Desativado por padrão	sim	sim	sim	Em desenvolvimento
BSAFE SSL-J	Não	Desativado por padrão	sim	sim	sim	sim
cryptlib	Não	Desativado por padrão em tempo de compilação	sim	sim	sim
GnuTLS	Não	Desativado por padrão	sim	sim	sim	sim
Extensão Java Secure Socket	Não	Desativado por padrão	sim	sim	sim	sim
LibreSSL	Não	Não	sim	sim	sim	A partir da versão 3.2.2
MatrixSSL	Não	Desativado por padrão em tempo de compilação	sim	sim	sim	sim (versão de rascunho)
mbed TLS (anteriormente PolarSSL)	Não	Desativado por padrão	sim	sim	sim
Serviços de segurança de rede	Não	Desativado por padrão	sim	sim	sim	sim
OpenSSL	Não	Ativado por padrão	sim	sim	sim	sim
SChannel XP / 2003	Desativado por padrão pelo MSIE 7	Ativado por padrão	Ativado por padrão pelo MSIE 7	Não	Não	Não
SChannel Vista	Desativado por padrão	Ativado por padrão	sim	Não	Não	Não
SChannel 2008	Desativado por padrão	Ativado por padrão	sim	Desativado por padrão (KB4019276)	Desativado por padrão (KB4019276)	Não
SChannel 7/2008 R2	Desativado por padrão	Desativado por padrão no MSIE 11	sim	Ativado por padrão pelo MSIE 11	Ativado por padrão pelo MSIE 11	Não
SChannel 8/2012	Desativado por padrão	Ativado por padrão	sim	Desativado por padrão	Desativado por padrão	Não
SChannel 8.1 / 2012 R2, 10 v1507 e v1511	Desativado por padrão	Desativado por padrão no MSIE 11	sim	sim	sim	Não
SChannel 10 v1607 / 2016	Não	Desativado por padrão	sim	sim	sim	Não
SChannel 10 v1903	Não	Desativado por padrão	sim	sim	sim	Não
SChannel 10 v21H1	Não	Desativado por padrão	sim	sim	sim	Não
Secure Transport OS X 10.2–10.8 / iOS 1–4	sim	sim	sim	Não	Não
Secure Transport OS X 10.9-10.10 / iOS 5-8	Não	sim	sim	sim	sim
Transporte seguro OS X 10.11 / iOS 9	Não	Não	sim	sim	sim
Biblioteca Seed7 TLS / SSL	Não	sim	sim	sim	sim
wolfSSL (anteriormente CyaSSL)	Não	Desativado por padrão	sim	sim	sim	sim
Implementação	SSL 2.0 (inseguro)	SSL 3.0 (inseguro)	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3

Um artigo apresentado na conferência ACM de 2012 sobre segurança de computadores e comunicações mostrou que poucos aplicativos usavam algumas dessas bibliotecas SSL corretamente, levando a vulnerabilidades. De acordo com os autores

"a causa raiz da maioria dessas vulnerabilidades é o péssimo design das APIs para as bibliotecas SSL subjacentes. Em vez de expressar propriedades de segurança de alto nível de túneis de rede, como confidencialidade e autenticação, essas APIs expõem detalhes de baixo nível do protocolo SSL para desenvolvedores de aplicativos. Como consequência, os desenvolvedores costumam usar APIs SSL incorretamente, interpretando e entendendo erroneamente seus diversos parâmetros, opções, efeitos colaterais e valores de retorno. "

Outros usos

O protocolo SMTP ( Simple Mail Transfer Protocol ) também pode ser protegido por TLS. Esses aplicativos usam certificados de chave pública para verificar a identidade dos terminais.

O TLS também pode ser usado para encapsular uma pilha de rede inteira para criar uma VPN , que é o caso com OpenVPN e OpenConnect . Muitos fornecedores já combinaram os recursos de criptografia e autenticação do TLS com a autorização. Também houve um desenvolvimento substancial desde o final dos anos 1990 na criação de tecnologia de cliente fora dos navegadores da Web, a fim de habilitar o suporte para aplicativos cliente / servidor. Em comparação com as tecnologias VPN IPsec tradicionais , o TLS tem algumas vantagens inerentes ao firewall e passagem de NAT que o tornam mais fácil de administrar para grandes populações de acesso remoto.

TLS também é um método padrão para proteger a sinalização de aplicativo do Protocolo de Iniciação de Sessão (SIP). O TLS pode ser usado para fornecer autenticação e criptografia da sinalização SIP associada ao VoIP e outros aplicativos baseados em SIP.

Segurança

Ataques contra TLS / SSL

Ataques significativos contra TLS / SSL estão listados abaixo.

Em fevereiro de 2015, a IETF emitiu um RFC informativo resumindo os vários ataques conhecidos contra TLS / SSL.

Ataque de renegociação

Uma vulnerabilidade do procedimento de renegociação foi descoberta em agosto de 2009 que pode levar a ataques de injeção de texto simples contra SSL 3.0 e todas as versões atuais de TLS. Por exemplo, permite que um invasor que pode sequestrar uma conexão https junte suas próprias solicitações no início da conversa que o cliente tem com o servidor da web. O invasor não pode realmente descriptografar a comunicação cliente-servidor, por isso é diferente de um ataque man-in-the-middle típico. Uma correção de curto prazo é que os servidores da web parem de permitir a renegociação, o que normalmente não exigirá outras alterações, a menos que a autenticação do certificado do cliente seja usada. Para corrigir a vulnerabilidade, uma extensão de indicação de renegociação foi proposta para TLS. Exigirá que o cliente e o servidor incluam e verifiquem informações sobre apertos de mão anteriores em quaisquer apertos de mão de renegociação. Esta extensão tornou-se um padrão proposto e recebeu o número RFC  5746 . O RFC foi implementado por várias bibliotecas.

Ataques de downgrade: Ataque FREAK e Ataque de logjam

Um ataque de downgrade de protocolo (também chamado de ataque de reversão de versão) engana um servidor da web para negociar conexões com versões anteriores de TLS (como SSLv2) que há muito foram abandonadas como inseguras.

Modificações anteriores aos protocolos originais, como False Start (adotado e habilitado pelo Google Chrome) ou Snap Start , introduziram ataques limitados de downgrade do protocolo TLS ou permitiram modificações na lista do conjunto de criptografia enviada pelo cliente ao servidor. Ao fazer isso, um invasor pode ter sucesso em influenciar a seleção do conjunto de criptografia em uma tentativa de fazer o downgrade do conjunto de criptografia negociado para usar um algoritmo de criptografia simétrica mais fraco ou uma troca de chave mais fraca. Um documento apresentado em uma conferência ACM sobre segurança de computadores e comunicações em 2012 demonstrou que a extensão False Start estava em risco: em certas circunstâncias, ela poderia permitir que um invasor recuperasse as chaves de criptografia offline e acessasse os dados criptografados.

Ataques de downgrade de criptografia podem forçar servidores e clientes a negociar uma conexão usando chaves criptograficamente fracas. Em 2014, um ataque man-in-the-middle chamado FREAK foi descoberto afetando a pilha OpenSSL , o navegador da web Android padrão e alguns navegadores Safari . O ataque envolveu enganar os servidores para que negociassem uma conexão TLS usando chaves de criptografia de 512 bits criptograficamente fracas.

Logjam é um exploit de segurança descoberto em maio de 2015 que explora a opção de usar grupos Diffie – Hellman de 512 bits de "nível de exportação" legados que datam da década de 1990. Ele força os servidores suscetíveis a fazer o downgrade para grupos Diffie – Hellman de 512 bits criptograficamente fracos. Um invasor pode então deduzir as chaves que o cliente e o servidor determinam usando a troca de chaves Diffie – Hellman .

Ataques de protocolo cruzado: DROWN

O ataque DROWN é uma exploração que ataca servidores que suportam pacotes de protocolo SSL / TLS contemporâneos, explorando seu suporte para o protocolo SSLv2 obsoleto e inseguro para alavancar um ataque em conexões usando protocolos atualizados que de outra forma seriam seguros. O DROWN explora uma vulnerabilidade nos protocolos usados ​​e na configuração do servidor, em vez de qualquer erro de implementação específico. Todos os detalhes do DROWN foram anunciados em março de 2016, junto com um patch para o exploit. Naquela época, mais de 81.000 do 1 milhão de sites mais populares estavam entre os sites protegidos por TLS que eram vulneráveis ​​ao ataque DROWN.

Ataque BESTA

Em 23 de setembro de 2011, os pesquisadores Thai Duong e Juliano Rizzo demonstraram uma prova de conceito chamada BEAST ( Browser Exploit Against SSL / TLS ) usando um miniaplicativo Java para violar as restrições de política de mesma origem , para uma vulnerabilidade de encadeamento de blocos de criptografia (CBC) há muito conhecida em TLS 1.0: um invasor observando 2 blocos de texto cifrado consecutivos C0, C1 pode testar se o bloco de texto simples P1 é igual ax escolhendo o próximo bloco de texto simples P2 = x C0 C1; de acordo com a operação CBC, C2 = E (C1 P2) = E (C1 x C0 C1) = E (C0 x), que será igual a C1 se x = P1. Explorações práticas não haviam sido demonstradas anteriormente para esta vulnerabilidade , que foi descoberta originalmente por Phillip Rogaway em 2002. A vulnerabilidade do ataque foi corrigida com o TLS 1.1 em 2006, mas o TLS 1.1 não teve uma ampla adoção antes desta demonstração de ataque. ${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$

RC4 como uma cifra de fluxo é imune ao ataque BEAST. Portanto, o RC4 foi amplamente usado como uma forma de mitigar o ataque do BEAST no lado do servidor. No entanto, em 2013, os pesquisadores encontraram mais pontos fracos no RC4. Posteriormente, ativar o RC4 no lado do servidor não era mais recomendado.

O Chrome e o Firefox em si não são vulneráveis ​​ao ataque BEAST, no entanto, a Mozilla atualizou suas bibliotecas NSS para mitigar ataques do tipo BEAST . O NSS é usado pelo Mozilla Firefox e Google Chrome para implementar SSL. Como resultado, alguns servidores da web que apresentam uma implementação incorreta da especificação SSL podem parar de funcionar.

A Microsoft lançou o Boletim de Segurança MS12-006 em 10 de janeiro de 2012, que corrigiu a vulnerabilidade do BEAST mudando a maneira como o componente Windows Secure Channel ( SChannel ) transmite pacotes de rede criptografados da extremidade do servidor. Os usuários do Internet Explorer (anterior à versão 11) executados em versões anteriores do Windows ( Windows 7 , Windows 8 e Windows Server 2008 R2 ) podem restringir o uso de TLS para 1.1 ou superior.

A Apple corrigiu a vulnerabilidade do BEAST implementando a divisão 1 / n-1 e ativando-a por padrão no OS X Mavericks , lançado em 22 de outubro de 2013.

Ataques CRIME e BREACH

Os autores do ataque BEAST também são os criadores do ataque CRIME posterior , que pode permitir que um invasor recupere o conteúdo dos cookies da web quando a compactação de dados é usada junto com o TLS. Quando usado para recuperar o conteúdo de cookies de autenticação secretos , permite que um invasor execute o sequestro de sessão em uma sessão da web autenticada.

Embora o ataque CRIME tenha sido apresentado como um ataque geral que poderia funcionar com eficácia contra um grande número de protocolos, incluindo, mas não se limitando a, TLS e protocolos de camada de aplicativo como SPDY ou HTTP , apenas explorações contra TLS e SPDY foram demonstradas e amplamente mitigadas em navegadores e servidores. A exploração CRIME contra a compactação HTTP não foi mitigada, embora os autores do CRIME tenham alertado que essa vulnerabilidade pode ser ainda mais disseminada do que a compactação SPDY e TLS combinadas. Em 2013 , foi anunciada uma nova instância de ataque CRIME contra compressão HTTP, apelidada de BREACH . Com base no ataque CRIME, um ataque BREACH pode extrair tokens de login, endereços de e-mail ou outras informações confidenciais do tráfego da web criptografado por TLS em apenas 30 segundos (dependendo do número de bytes a serem extraídos), desde que o invasor engane a vítima para que o visite um link da web malicioso ou é capaz de injetar conteúdo em páginas válidas que o usuário está visitando (por exemplo: uma rede sem fio sob o controle do invasor). Todas as versões de TLS e SSL estão sob risco de BREACH, independentemente do algoritmo de criptografia ou cifra usado. Ao contrário das instâncias anteriores de CRIME, que podem ser evitadas com sucesso desativando a compactação TLS ou a compactação de cabeçalho SPDY, o BREACH explora a compactação HTTP que não pode ser desligada de forma realista, pois praticamente todos os servidores da Web dependem dela para melhorar a velocidade de transmissão de dados para os usuários. Essa é uma limitação conhecida do TLS, pois é suscetível a ataques de texto simples escolhido contra os dados da camada de aplicativo que deveria proteger.

Ataques cronometrados ao enchimento

As versões anteriores do TLS eram vulneráveis ​​contra o ataque de oráculo de preenchimento descoberto em 2002. Uma nova variante, chamada de ataque Lucky Thirteen , foi publicada em 2013.

Alguns especialistas também recomendaram evitar Triple-DES CBC. Desde as últimas cifras suportados desenvolvidos para apoiar qualquer programa usando Windows XP SSL 's / biblioteca TLS como o Internet Explorer no Windows XP são RC4 e Triple-DES, e desde RC4 agora está obsoleta (ver discussão de ataques RC4 ), o que torna difícil para oferecer suporte a qualquer versão de SSL para qualquer programa usando esta biblioteca no XP.

Uma correção foi lançada como a extensão Encrypt-then-MAC para a especificação TLS, lançada como RFC  7366 . O ataque Lucky Thirteen pode ser mitigado no TLS 1.2 usando apenas cifras AES_GCM; AES_CBC permanece vulnerável.

Ataque POODLE

Em 14 de outubro de 2014, os pesquisadores do Google publicaram uma vulnerabilidade no design do SSL 3.0, que torna o modo de operação CBC com SSL 3.0 vulnerável a um ataque de preenchimento ( CVE - 2014-3566 ). Eles chamaram esse ataque de POODLE ( Padding Oracle On Downgraded Legacy Encryption ). Em média, os invasores precisam apenas fazer 256 solicitações SSL 3.0 para revelar um byte de mensagens criptografadas.

Embora essa vulnerabilidade exista apenas em SSL 3.0 e a maioria dos clientes e servidores suportem TLS 1.0 e superior, todos os principais navegadores voluntariamente fazem downgrade para SSL 3.0 se os handshakes com versões mais recentes de TLS falharem, a menos que forneçam a opção para um usuário ou administrador desabilitar SSL 3.0 e o usuário ou administrador o faz. Portanto, o intermediário pode primeiro conduzir um ataque de reversão de versão e, em seguida, explorar esta vulnerabilidade.

Em 8 de dezembro de 2014, uma variante do POODLE foi anunciada que impacta as implementações de TLS que não impõem requisitos de byte de preenchimento de maneira adequada.

Ataques RC4

Apesar da existência de ataques ao RC4 que quebraram sua segurança, os pacotes de criptografia em SSL e TLS baseados em RC4 ainda eram considerados seguros antes de 2013 com base na forma como eram usados ​​em SSL e TLS. Em 2011, o pacote RC4 foi recomendado como uma solução alternativa para o ataque BEAST . Novas formas de ataque divulgadas em março de 2013 demonstraram conclusivamente a viabilidade de quebrar RC4 em TLS, sugerindo que não era uma boa solução alternativa para o BEAST. Um cenário de ataque foi proposto por AlFardan, Bernstein, Paterson, Poettering e Schuldt que usou tendências estatísticas recém-descobertas na tabela de chaves RC4 para recuperar partes do texto simples com um grande número de criptografias TLS. Um ataque ao RC4 em TLS e SSL que requer criptografias 13 × 2 ²⁰ para quebrar o RC4 foi revelado em 8 de julho de 2013 e posteriormente descrito como "viável" na apresentação que o acompanha em um Simpósio de Segurança USENIX em agosto de 2013. Em julho de 2015, melhorias subsequentes no ataque torna cada vez mais prático derrotar a segurança do TLS criptografado com RC4.

Como muitos navegadores modernos foram projetados para derrotar os ataques BEAST (exceto Safari para Mac OS X 10.7 ou anterior, para iOS 6 ou anterior e para Windows; consulte § Navegadores da Web ), RC4 não é mais uma boa escolha para TLS 1.0. As cifras CBC que foram afetadas pelo ataque BEAST no passado se tornaram uma escolha mais popular para proteção. A Mozilla e a Microsoft recomendam desativar o RC4 sempre que possível. O RFC  7465 proíbe o uso de conjuntos de criptografia RC4 em todas as versões do TLS.

Em 1º de setembro de 2015, a Microsoft, o Google e a Mozilla anunciaram que os pacotes de criptografia RC4 seriam desativados por padrão em seus navegadores ( Microsoft Edge , Internet Explorer 11 no Windows 7 / 8.1 / 10, Firefox e Chrome ) no início de 2016.

Ataque de truncamento

Um ataque de truncamento TLS (logout) bloqueia as solicitações de logout da conta da vítima para que o usuário, sem saber, permaneça conectado a um serviço da web. Quando a solicitação para sair é enviada, o invasor injeta uma mensagem TCP FIN não criptografada (sem mais dados do remetente) para fechar a conexão. O servidor, portanto, não recebe a solicitação de logout e não tem conhecimento do encerramento anormal.

Publicado em julho de 2013, o ataque faz com que serviços da web como Gmail e Hotmail exibam uma página que informa ao usuário que ele foi desconectado com sucesso, ao mesmo tempo que garante que o navegador do usuário mantenha a autorização com o serviço, permitindo que um invasor tenha acesso subsequente a o navegador para acessar e assumir o controle da conta conectada do usuário. O ataque não depende da instalação de malware no computador da vítima; os atacantes precisam apenas se colocar entre a vítima e o servidor web (por exemplo, configurando um hotspot sem fio nocivo). Essa vulnerabilidade também requer acesso ao computador da vítima. Outra possibilidade é ao usar FTP, a conexão de dados pode ter um FIN falso no fluxo de dados e, se as regras de protocolo para troca de alertas close_notify não forem respeitadas, um arquivo pode ser truncado.

Ataque PAC profano

Este ataque, descoberto em meados de 2016, explora os pontos fracos do Web Proxy Autodiscovery Protocol (WPAD) para expor a URL que um usuário da web está tentando acessar por meio de um link da web habilitado para TLS. A divulgação de um URL pode violar a privacidade de um usuário, não apenas por causa do site acessado, mas também porque os URLs às vezes são usados ​​para autenticar usuários. Os serviços de compartilhamento de documentos, como os oferecidos pelo Google e Dropbox, também funcionam enviando ao usuário um token de segurança incluído no URL. Um invasor que obtém tais URLs pode obter acesso total à conta ou aos dados da vítima.

A exploração funciona contra quase todos os navegadores e sistemas operacionais.

Ataque Sweet32

O ataque Sweet32 quebra todas as cifras de bloco de 64 bits usadas no modo CBC como usado no TLS, explorando um ataque de aniversário e um ataque man-in-the-middle ou injeção de um JavaScript malicioso em uma página da web. O objetivo do ataque man-in-the-middle ou da injeção de JavaScript é permitir que o invasor capture tráfego suficiente para montar um ataque de aniversário.

Erros de implementação: Bug Heartbleed, Ataque BERserk, bug Cloudflare

O bug Heartbleed é uma vulnerabilidade séria específica para a implementação de SSL / TLS na popular biblioteca de software criptográfico OpenSSL , afetando as versões 1.0.1 a 1.0.1f. Essa fraqueza, relatada em abril de 2014, permite que invasores roubem chaves privadas de servidores que normalmente deveriam ser protegidos. O bug Heartbleed permite que qualquer pessoa na Internet leia a memória dos sistemas protegidos pelas versões vulneráveis ​​do software OpenSSL. Isso compromete as chaves privadas secretas associadas aos certificados públicos usados ​​para identificar os provedores de serviço e criptografar o tráfego, os nomes e senhas dos usuários e o conteúdo real. Isso permite que os invasores bisbilhotem as comunicações, roubem dados diretamente dos serviços e usuários e se façam passar por serviços e usuários. A vulnerabilidade é causada por um bug de buffer over-read no software OpenSSL, em vez de um defeito na especificação do protocolo SSL ou TLS.

Em setembro de 2014, uma variante da vulnerabilidade PKCS # 1 v1.5 RSA Signature Forgery de Daniel Bleichenbacher foi anunciada pela Intel Security Advanced Threat Research. Este ataque, apelidado de BERserk, é o resultado da decodificação incompleta do comprimento ASN.1 de assinaturas de chave pública em algumas implementações SSL e permite um ataque man-in-the-middle forjando uma assinatura de chave pública.

Em fevereiro de 2015, depois que a mídia relatou a pré-instalação oculta do adware Superfish em alguns notebooks Lenovo, um pesquisador descobriu que um certificado raiz confiável em máquinas Lenovo afetadas era inseguro, pois as chaves podiam ser facilmente acessadas usando o nome da empresa, Komodia, como uma senha longa. A biblioteca Komodia foi projetada para interceptar o tráfego TLS / SSL do lado do cliente para controle e vigilância dos pais, mas também foi usada em vários programas de adware, incluindo Superfish, que muitas vezes eram instalados clandestinamente sem o conhecimento do usuário do computador. Por sua vez, esses programas potencialmente indesejados instalaram o certificado raiz corrompido, permitindo que os invasores controlem completamente o tráfego da web e confirmem os sites falsos como autênticos.

Em maio de 2016, foi relatado que dezenas de sites dinamarqueses protegidos por HTTPS pertencentes à Visa Inc. eram vulneráveis ​​a ataques que permitiam que hackers injetassem código malicioso e conteúdo forjado nos navegadores dos visitantes. Os ataques funcionaram porque a implementação de TLS usada nos servidores afetados reutilizou incorretamente números aleatórios ( nonces ) que deveriam ser usados ​​apenas uma vez, garantindo que cada handshake de TLS fosse exclusivo.

Em fevereiro de 2017, um erro de implementação causado por um único caractere incorreto no código usado para analisar HTML criou um erro de estouro de buffer nos servidores Cloudflare . Semelhante em seus efeitos ao bug Heartbleed descoberto em 2014, esse erro de estouro, amplamente conhecido como Cloudbleed , permitiu que terceiros não autorizados lessem dados na memória de programas em execução nos servidores - dados que, de outra forma, deveriam ser protegidos por TLS.

Pesquisa de sites vulneráveis ​​a ataques

Em julho de 2021, o Trustworthy Internet Movement estimou a proporção de sites vulneráveis ​​a ataques TLS.

Levantamento das vulnerabilidades TLS dos sites mais populares

Ataques	Segurança
	Inseguro	Depende	Seguro	De outros
Ataque de renegociação	0,1% apoiam renegociação insegura	<0,1% suportam ambos	99,2% apoiam renegociação segura	0,7% sem suporte
Ataques RC4	0,4% suporta suítes RC4 usadas com navegadores modernos	6,5% apóiam algumas suítes RC4	93,1% sem suporte	N / D
Compressão TLS (ataque CRIME)	> 0,0% vulnerável	N / D	N / D	N / D
Heartbleed	> 0,0% vulnerável	N / D	N / D	N / D
Ataque de injeção ChangeCipherSpec	0,1% vulnerável e explorável	0,2% vulnerável, não explorável	98,5% não vulnerável	1,2% desconhecido
Ataque POODLE contra TLS (POODLE original contra SSL 3.0 não está incluído)	0,1% vulnerável e explorável	0,1% vulnerável, não explorável	99,8% não vulnerável	0,2% desconhecido
Downgrade de protocolo	6,6% de defesa contra downgrade não suportado	N / D	72,3% de defesa de downgrade com suporte	21,0% desconhecido

Encaminhamento de sigilo

O sigilo direto é uma propriedade dos sistemas criptográficos que garante que uma chave de sessão derivada de um conjunto de chaves públicas e privadas não seja comprometida se uma das chaves privadas for comprometida no futuro. Sem o sigilo de encaminhamento, se a chave privada do servidor for comprometida, não apenas todas as futuras sessões criptografadas por TLS usando esse certificado de servidor serão comprometidas, mas também todas as sessões anteriores que o usaram (desde que essas sessões anteriores tenham sido interceptadas e armazenadas no momento da transmissão). Uma implementação de TLS pode fornecer sigilo de encaminhamento exigindo o uso de troca de chave Diffie – Hellman efêmera para estabelecer chaves de sessão, e algumas implementações notáveis ​​de TLS fazem isso exclusivamente: por exemplo, Gmail e outros serviços HTTPS do Google que usam OpenSSL . No entanto, muitos clientes e servidores que oferecem suporte a TLS (incluindo navegadores e servidores da web) não estão configurados para implementar tais restrições. Na prática, a menos que um serviço da web use a troca de chaves Diffie – Hellman para implementar o sigilo direto, todo o tráfego da web criptografado de e para esse serviço pode ser descriptografado por um terceiro se obtiver a chave mestre (privada) do servidor; por exemplo, por meio de uma ordem judicial.

Mesmo onde a troca de chaves Diffie – Hellman é implementada, os mecanismos de gerenciamento de sessão do lado do servidor podem impactar o sigilo de encaminhamento. O uso de tíquetes de sessão TLS (uma extensão TLS) faz com que a sessão seja protegida por AES128-CBC-SHA256, independentemente de quaisquer outros parâmetros TLS negociados, incluindo pacotes de criptografia de sigilo de encaminhamento e as chaves de tíquetes de sessão TLS de longa duração derrotam a tentativa de implementação sigilo para a frente. A pesquisa da Universidade de Stanford em 2014 também descobriu que de 473.802 servidores TLS pesquisados, 82,9% dos servidores que implantam troca de chave Diffie-Hellman (DHE) efêmera para oferecer suporte ao sigilo direto estavam usando parâmetros Diffie-Hellman fracos. Essas escolhas de parâmetros fracos podem comprometer a eficácia do sigilo direto que os servidores procuraram fornecer.

Desde o final de 2011, o Google fornece sigilo direto com TLS por padrão para os usuários de seu serviço Gmail , junto com o Google Docs e busca criptografada, entre outros serviços. Desde novembro de 2013, o Twitter fornece sigilo direto com TLS aos usuários de seu serviço. Desde agosto de 2019, cerca de 80% dos sites habilitados para TLS são configurados para usar pacotes de criptografia que fornecem sigilo de encaminhamento para a maioria dos navegadores da web.

Interceptação TLS

A interceptação TLS (ou interceptação HTTPS, se aplicada particularmente a esse protocolo) é a prática de interceptar um fluxo de dados criptografado para descriptografá-lo, lê-lo e possivelmente manipulá-lo e, em seguida, criptografá-lo novamente e enviar os dados novamente. Isso é feito por meio de um " proxy transparente ": o software de interceptação encerra a conexão TLS de entrada, inspeciona o texto simples HTTP e, em seguida, cria uma nova conexão TLS com o destino.

A interceptação TLS / HTTPS é usada como uma medida de segurança da informação por operadores de rede para poder fazer a varredura e proteger contra a intrusão de conteúdo malicioso na rede, como vírus de computador e outros malwares . De outra forma, tal conteúdo não poderia ser detectado, desde que protegido por criptografia, o que é cada vez mais o caso como resultado do uso rotineiro de HTTPS e outros protocolos seguros.

Uma desvantagem significativa da interceptação TLS / HTTPS é que ela apresenta novos riscos de segurança próprios. Uma limitação notável é que ele fornece um ponto em que o tráfego de rede está disponível sem criptografia, dando aos invasores um incentivo para atacar esse ponto, em particular, para obter acesso a conteúdo de outra forma seguro. A interceptação também permite que a operadora da rede, ou as pessoas que obtêm acesso ao seu sistema de interceptação, executem ataques man-in-the-middle contra os usuários da rede. Um estudo de 2017 descobriu que "a interceptação HTTPS tornou-se surpreendentemente difundida e que os produtos de interceptação como uma classe têm um impacto dramaticamente negativo na segurança da conexão".

Detalhes do protocolo

O protocolo TLS troca registros , que encapsulam os dados a serem trocados em um formato específico (veja abaixo). Cada registro pode ser compactado, preenchido, anexado a um código de autenticação de mensagem (MAC) ou criptografado, tudo dependendo do estado da conexão. Cada registro possui um campo de tipo de conteúdo que designa o tipo de dados encapsulados, um campo de comprimento e um campo de versão TLS. Os dados encapsulados podem ser mensagens de controle ou de procedimento do próprio TLS ou simplesmente os dados do aplicativo que precisam ser transferidos pelo TLS. As especificações (cipher suite, keys etc.) necessárias para trocar dados de aplicativos por TLS são acordadas no "handshake TLS" entre o cliente que solicita os dados e o servidor que responde às solicitações. O protocolo, portanto, define a estrutura das cargas úteis transferidas em TLS e o procedimento para estabelecer e monitorar a transferência.

Handshake TLS

Quando a conexão é iniciada, o registro encapsula um protocolo de "controle" - o protocolo de mensagens de handshake ( tipo de conteúdo 22). Este protocolo é usado para trocar todas as informações exigidas por ambos os lados para a troca dos dados reais do aplicativo por TLS. Ele define o formato das mensagens e a ordem de sua troca. Eles podem variar de acordo com as demandas do cliente e do servidor - ou seja, existem vários procedimentos possíveis para configurar a conexão. Essa troca inicial resulta em uma conexão TLS bem-sucedida (ambas as partes prontas para transferir dados do aplicativo com TLS) ou em uma mensagem de alerta (conforme especificado abaixo).

Handshake básico de TLS

Um exemplo típico de conexão a seguir, ilustrando um handshake em que o servidor (mas não o cliente) é autenticado por seu certificado:

1. Fase de negociação:
   • Um cliente envia uma mensagem ClientHello especificando a versão de protocolo TLS mais alta que suporta, um número aleatório, uma lista de conjuntos de criptografia sugeridos e métodos de compactação sugeridos. Se o cliente estiver tentando executar um handshake retomado, ele poderá enviar uma ID de sessão . Se o cliente puder usar a negociação de protocolo de camada de aplicativo , ela poderá incluir uma lista de protocolos de aplicativo compatíveis , como HTTP / 2 .
   • O servidor responde com uma mensagem ServerHello , contendo a versão do protocolo escolhida, um número aleatório, cipher suite e método de compressão a partir das opções oferecidas pelo cliente. Para confirmar ou permitir a retomada dos handshakes, o servidor pode enviar um ID de sessão . A versão do protocolo escolhida deve ser a mais alta que o cliente e o servidor suportam. Por exemplo, se o cliente oferece suporte a TLS versão 1.1 e o servidor oferece suporte à versão 1.2, a versão 1.1 deve ser selecionada; a versão 1.2 não deve ser selecionada.
   • O servidor envia sua mensagem de certificado (dependendo do pacote de criptografia selecionado, isso pode ser omitido pelo servidor).
   • O servidor envia sua mensagem ServerKeyExchange (dependendo do pacote de criptografia selecionado, isso pode ser omitido pelo servidor). Esta mensagem é enviada para todos os pacotes de criptografia DHE , ECDHE e DH_anon.
   • O servidor envia uma mensagem ServerHelloDone , indicando que é feita a negociação do handshake.
   • O cliente responde com uma mensagem ClientKeyExchange , que pode conter um PreMasterSecret , chave pública ou nada. (Novamente, isso depende da cifra selecionada.) Este PreMasterSecret é criptografado usando a chave pública do certificado do servidor.
   • O cliente e o servidor então usam os números aleatórios e PreMasterSecret para computar um segredo comum, chamado de "segredo mestre". Todos os outros dados de chave ( chaves de sessão como IV , chave de criptografia simétrica , chave MAC ) para esta conexão são derivados desse segredo mestre (e os valores aleatórios gerados pelo cliente e pelo servidor), que são passados ​​por uma função pseudo-aleatória cuidadosamente projetada .
2. O cliente agora envia um registro ChangeCipherSpec , essencialmente dizendo ao servidor, "Tudo o que eu disser a partir de agora será autenticado (e criptografado se parâmetros de criptografia estiverem presentes no certificado do servidor)." O próprio ChangeCipherSpec é um protocolo de nível de registro com tipo de conteúdo 20.
   • O cliente envia uma mensagem Concluída autenticada e criptografada , contendo um hash e MAC sobre as mensagens de handshake anteriores.
   • O servidor tentará descriptografar a mensagem Concluída do cliente e verificar o hash e o MAC. Se a descriptografia ou verificação falhar, o handshake é considerado como tendo falhado e a conexão deve ser interrompida.
3. Finalmente, o servidor envia um ChangeCipherSpec , dizendo ao cliente: "Tudo o que eu disser a partir de agora será autenticado (e criptografado, se a criptografia foi negociada)."
   • O servidor envia sua mensagem Concluída autenticada e criptografada .
   • O cliente executa o mesmo procedimento de descriptografia e verificação que o servidor fez na etapa anterior.
4. Fase de aplicação: neste ponto, o "handshake" está completo e o protocolo de aplicação está habilitado, com tipo de conteúdo 23. As mensagens de aplicação trocadas entre cliente e servidor também serão autenticadas e opcionalmente criptografadas exatamente como em sua mensagem Concluída . Caso contrário, o tipo de conteúdo retornará 25 e o cliente não será autenticado.

Handshake TLS autenticado pelo cliente

O exemplo completo a seguir mostra um cliente sendo autenticado (além do servidor como no exemplo acima; consulte autenticação mútua ) por meio de TLS usando certificados trocados entre os dois pares.

1. Fase de Negociação:
   • Um cliente envia uma mensagem ClientHello especificando a versão mais alta do protocolo TLS que suporta, um número aleatório, uma lista de conjuntos de criptografia sugeridos e métodos de compactação.
   • O servidor responde com uma mensagem ServerHello , contendo a versão do protocolo escolhida, um número aleatório, cipher suite e método de compressão a partir das opções oferecidas pelo cliente. O servidor também pode enviar um id de sessão como parte da mensagem para realizar um handshake retomado.
   • O servidor envia sua mensagem de certificado (dependendo do pacote de criptografia selecionado, isso pode ser omitido pelo servidor).
   • O servidor envia sua mensagem ServerKeyExchange (dependendo do pacote de criptografia selecionado, isso pode ser omitido pelo servidor). Esta mensagem é enviada para todos os ciphersuites DHE, ECDHE e DH_anon.
   • O servidor envia uma mensagem CertificateRequest , para solicitar um certificado do cliente.
   • O servidor envia uma mensagem ServerHelloDone , indicando que é feita a negociação do handshake.
   • O cliente responde com uma mensagem de certificado , que contém o certificado do cliente.
   • O cliente envia uma mensagem ClientKeyExchange , que pode conter um PreMasterSecret , chave pública ou nada. (Novamente, isso depende da cifra selecionada.) Este PreMasterSecret é criptografado usando a chave pública do certificado do servidor.
   • O cliente envia uma mensagem CertificateVerify , que é uma assinatura das mensagens de handshake anteriores usando a chave privada do certificado do cliente. Essa assinatura pode ser verificada usando a chave pública do certificado do cliente. Isso permite que o servidor saiba que o cliente tem acesso à chave privada do certificado e, portanto, possui o certificado.
   • O cliente e o servidor então usam os números aleatórios e PreMasterSecret para computar um segredo comum, chamado de "segredo mestre". Todos os outros dados de chave ("chaves de sessão") para esta conexão são derivados desse segredo mestre (e os valores aleatórios gerados pelo cliente e pelo servidor), que são passados ​​por uma função pseudo-aleatória cuidadosamente projetada.
2. O cliente agora envia um registro ChangeCipherSpec , essencialmente dizendo ao servidor: "Tudo que eu disser a partir de agora será autenticado (e criptografado se a criptografia foi negociada)." O ChangeCipherSpec é um protocolo de nível de registro e tem tipo 20 e não 22 .
   • Finalmente, o cliente envia uma mensagem finalizada criptografada , contendo um hash e MAC sobre as mensagens de handshake anteriores.
   • O servidor tentará descriptografar a mensagem Concluída do cliente e verificar o hash e o MAC. Se a descriptografia ou verificação falhar, o handshake é considerado como tendo falhado e a conexão deve ser interrompida.
3. Por fim, o servidor envia um ChangeCipherSpec , informando ao cliente: "Tudo o que eu disser a partir de agora será autenticado (e criptografado se a criptografia tiver sido negociada)."
   • O servidor envia sua própria mensagem Concluída criptografada .
   • O cliente executa o mesmo procedimento de descriptografia e verificação que o servidor fez na etapa anterior.
4. Fase de aplicação: neste ponto, o "handshake" é concluído e o protocolo de aplicação é habilitado, com conteúdo do tipo 23. As mensagens de aplicação trocadas entre cliente e servidor também serão criptografadas exatamente como em sua mensagem Concluída .

Aperto de mão TLS retomado

As operações de chave pública (por exemplo, RSA) são relativamente caras em termos de poder computacional. O TLS fornece um atalho seguro no mecanismo de handshake para evitar estas operações: sessões retomadas. As sessões retomadas são implementadas usando IDs de sessão ou tickets de sessão.

Além do benefício de desempenho, as sessões retomadas também podem ser usadas para logon único , pois isso garante que a sessão original e qualquer sessão retomada sejam originadas do mesmo cliente. Isso é de particular importância para o protocolo FTP sobre TLS / SSL , que, de outra forma, sofreria com um ataque man-in-the-middle no qual um invasor poderia interceptar o conteúdo das conexões de dados secundárias.

Handshake TLS 1.3

O handshake do TLS 1.3 foi condensado em apenas uma viagem de ida e volta em comparação com as duas viagens de ida e volta exigidas nas versões anteriores do TLS / SSL.

Primeiro, o cliente envia uma mensagem clientHello ao servidor que contém uma lista de cifras suportadas na ordem de preferência do cliente e adivinha qual algoritmo de chave será usado para que possa enviar uma chave secreta para compartilhar, se necessário. Ao adivinhar qual algoritmo-chave será usado, o servidor elimina uma viagem de ida e volta. Após receber o clientHello, o servidor envia um serverHello com sua chave, um certificado, o cipher suite escolhido e a mensagem finalizada.

Depois que o cliente recebe a mensagem finalizada do servidor, ela agora é coordenada com o servidor no qual o pacote de criptografia será usado.

IDs de sessão

Em um handshake completo comum , o servidor envia uma id de sessão como parte da mensagem ServerHello . O cliente associa este id de sessão ao endereço IP do servidor e à porta TCP, de forma que, quando o cliente se conectar novamente a esse servidor, ele possa usar o id de sessão para atuar no handshake. No servidor, o id da sessão mapeia para os parâmetros criptográficos previamente negociados, especificamente o "segredo mestre". Ambos os lados devem ter o mesmo "segredo mestre" ou o handshake retomado falhará (isso evita que um intruso use um id de sessão ). Os dados aleatórios nas mensagens ClientHello e ServerHello garantem virtualmente que as chaves de conexão geradas serão diferentes das da conexão anterior. Nas RFCs, esse tipo de handshake é chamado de handshake abreviado . Também é descrito na literatura como um handshake de reinicialização .

1. Fase de negociação:
   • Um cliente envia uma mensagem ClientHello especificando a versão mais alta do protocolo TLS que suporta, um número aleatório, uma lista de conjuntos de criptografia sugeridos e métodos de compactação. Incluído na mensagem está o ID da sessão da conexão TLS anterior.
   • O servidor responde com uma mensagem ServerHello , contendo a versão do protocolo escolhida, um número aleatório, cipher suite e método de compressão a partir das opções oferecidas pelo cliente. Se o servidor reconhecer o id de sessão enviado pelo cliente, ele responde com o mesmo id de sessão . O cliente usa isso para reconhecer que um handshake retomado está sendo executado. Se o servidor não reconhecer o id de sessão enviado pelo cliente, ele envia um valor diferente para seu id de sessão . Isso informa ao cliente que um handshake retomado não será executado. Neste ponto, o cliente e o servidor possuem o "segredo mestre" e dados aleatórios para gerar os dados-chave a serem usados ​​para esta conexão.
2. O servidor agora envia um registro ChangeCipherSpec , essencialmente dizendo ao cliente: "Tudo o que eu disser a partir de agora será criptografado." O ChangeCipherSpec é em si um protocolo de nível de registro e tem tipo 20 e não 22.
   • Finalmente, o servidor envia uma mensagem finalizada criptografada , contendo um hash e MAC sobre as mensagens de handshake anteriores.
   • O cliente tentará descriptografar a mensagem Concluída do servidor e verificar o hash e o MAC. Se a descriptografia ou verificação falhar, o handshake é considerado como tendo falhado e a conexão deve ser interrompida.
3. Por fim, o cliente envia um ChangeCipherSpec , informando ao servidor: "Tudo o que eu disser a partir de agora será criptografado."
   • O cliente envia sua própria mensagem Concluída criptografada .
   • O servidor executa o mesmo procedimento de descriptografia e verificação que o cliente fez na etapa anterior.
4. Fase de aplicação: neste ponto, o "handshake" é concluído e o protocolo de aplicação é habilitado, com conteúdo do tipo 23. As mensagens de aplicação trocadas entre cliente e servidor também serão criptografadas exatamente como em sua mensagem Concluída .

Tíquetes de sessão

O RFC  5077 estende o TLS por meio do uso de tickets de sessão, em vez de IDs de sessão. Ele define uma maneira de retomar uma sessão TLS sem exigir que o estado específico da sessão seja armazenado no servidor TLS.

Ao usar tíquetes de sessão, o servidor TLS armazena seu estado específico da sessão em um tíquete de sessão e envia o tíquete de sessão ao cliente TLS para armazenamento. O cliente retoma uma sessão TLS enviando o tíquete de sessão ao servidor, e o servidor retoma a sessão TLS de acordo com o estado específico da sessão no tíquete. O tíquete de sessão é criptografado e autenticado pelo servidor, e o servidor verifica sua validade antes de usar seu conteúdo.

Um ponto fraco desse método com OpenSSL é que ele sempre limita a criptografia e a segurança da autenticação do tíquete de sessão TLS transmitido AES128-CBC-SHA256, não importando quais outros parâmetros TLS foram negociados para a sessão TLS real. Isso significa que as informações de estado (o tíquete de sessão TLS) não estão tão protegidas quanto a própria sessão TLS. De particular preocupação é o armazenamento das chaves do OpenSSL em um contexto de todo o aplicativo ( SSL_CTX), ou seja, durante a vida útil do aplicativo, e não permitindo a redigitação dos AES128-CBC-SHA256tíquetes de sessão TLS sem redefinir o contexto do OpenSSL de todo o aplicativo (o que é incomum , sujeito a erros e frequentemente requer intervenção administrativa manual).

Registro TLS

Este é o formato geral de todos os registros TLS.

Formato de registro TLS, geral

Desvio	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	Tipo de conteúdo	N / D
Bytes 1..4	Versão legada		Comprimento
	(Principal)	(Menor)	(bits 15..8)	(bits 7..0)
Bytes 5 .. ( m -1)	Mensagem (ns) de protocolo
Bytes m .. ( p -1)	MAC (opcional)
Bytes p .. ( q −1)	Preenchimento (apenas cifras de bloco)

Tipo de conteúdo

Este campo identifica o tipo de protocolo da camada de registro contido neste registro.

Tipos de conteúdo

Hex	Dez	Modelo
0x14	20	ChangeCipherSpec
0x15	21	Alerta
0x16	22	Aperto de mão
0x17	23	Aplicativo
0x18	24	Batimento cardiaco

Versão legada

Este campo identifica a versão principal e secundária do TLS anterior ao TLS 1.3 para a mensagem contida. Para uma mensagem ClientHello, esta não precisa ser a versão mais recente suportada pelo cliente. Para TLS 1.3 e posterior, isso deve ser definido como 0x0303 e o aplicativo deve enviar versões com suporte em um bloco de extensão de mensagem extra.

Versões

Versão principal	Versão secundária	Tipo de versão
3	0	SSL 3.0
3	1	TLS 1.0
3	2	TLS 1.1
3	3	TLS 1.2
3	4	TLS 1.3

Comprimento

O comprimento dos campos "mensagem (ns) de protocolo", "MAC" e "preenchimento" combinados (ou seja, q −5), não deve exceder 2 ¹⁴ bytes (16 KiB).

Mensagem (ns) de protocolo

Uma ou mais mensagens identificadas pelo campo Protocolo. Observe que este campo pode ser criptografado dependendo do estado da conexão.

MAC e preenchimento

Um código de autenticação de mensagem calculado sobre o campo "mensagem (ns) de protocolo", com material de chave adicional incluído. Observe que este campo pode ser criptografado ou não incluído totalmente, dependendo do estado da conexão.

Nenhum campo "MAC" ou "preenchimento" pode estar presente no final dos registros TLS antes que todos os algoritmos e parâmetros de cifra tenham sido negociados e recebidos e, em seguida, confirmados enviando um registro CipherStateChange (veja abaixo) para sinalizar que esses parâmetros terão efeito em todos outros registros enviados pelo mesmo par.

Protocolo de handshake

A maioria das mensagens trocadas durante a configuração da sessão TLS são baseadas neste registro, a menos que um erro ou aviso ocorra e precise ser sinalizado por um registro de protocolo de Alerta (veja abaixo), ou o modo de criptografia da sessão seja modificado por outro registro ( consulte protocolo ChangeCipherSpec abaixo).

Formato de registro TLS para protocolo de handshake

Desvio	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	22	N / D
Bytes 1..4	Versão legada		Comprimento
	(Principal)	(Menor)	(bits 15..8)	(bits 7..0)
Bytes 5..8	Tipo de mensagem	Comprimento dos dados da mensagem de handshake
		(bits 23..16)	(bits 15..8)	(bits 7..0)
Bytes 9 .. ( n -1)	Dados da mensagem de handshake
Bytes n .. ( n +3)	Tipo de mensagem	Comprimento dos dados da mensagem de handshake
		(bits 23..16)	(bits 15..8)	(bits 7..0)
Bytes ( n +4) ..	Dados da mensagem de handshake

Tipo de mensagem

Este campo identifica o tipo de mensagem de handshake.

Tipos de mensagem

Código	Descrição
0	HelloRequest
1	Cliente Olá
2	ServerHello
4	NewSessionTicket
8	EncryptedExtensions (somente TLS 1.3)
11	Certificado
12	ServerKeyExchange
13	CertificateRequest
14	ServerHelloDone
15	CertificateVerify
16	ClientKeyExchange
20	Finalizado

Comprimento dos dados da mensagem de handshake

Este é um campo de 3 bytes que indica o comprimento dos dados do handshake, sem incluir o cabeçalho.

Observe que várias mensagens de handshake podem ser combinadas em um registro.

Protocolo de alerta

Este registro normalmente não deve ser enviado durante o handshaking normal ou trocas de aplicativos. No entanto, essa mensagem pode ser enviada a qualquer momento durante o handshake e até o encerramento da sessão. Se for usado para sinalizar um erro fatal, a sessão será encerrada imediatamente após o envio deste registro, portanto, este registro é usado para dar um motivo para o encerramento. Se o nível de alerta for sinalizado como um aviso, o controle remoto pode decidir fechar a sessão se decidir que a sessão não é confiável o suficiente para suas necessidades (antes de fazer isso, o controle remoto também pode enviar seu próprio sinal).

Formato de registro TLS para protocolo de alerta

Desvio	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	21	N / D
Bytes 1..4	Versão legada		Comprimento
	(Principal)	(Menor)	0	2
Bytes 5..6	Nível	Descrição	N / D
Bytes 7 .. ( p −1)	MAC (opcional)
Bytes p .. ( q −1)	Preenchimento (apenas cifras de bloco)

Nível

Este campo identifica o nível de alerta. Se o nível for fatal, o remetente deve fechar a sessão imediatamente. Caso contrário, o destinatário pode decidir encerrar a sessão por conta própria, enviando seu próprio alerta fatal e fechando a própria sessão imediatamente após enviá-lo. O uso de registros de Alerta é opcional, porém se faltarem antes do encerramento da sessão, a sessão poderá ser reiniciada automaticamente (com seus apertos de mão).

O fechamento normal de uma sessão após o término do aplicativo transportado deve, preferencialmente, ser alertado com pelo menos o tipo Alerta de notificação de fechamento (com um nível de aviso simples) para evitar o reinício automático de uma nova sessão. Sinalizar explicitamente o fechamento normal de uma sessão segura antes de fechar efetivamente sua camada de transporte é útil para prevenir ou detectar ataques (como tentativas de truncar os dados transportados com segurança, se intrinsecamente não tiver um comprimento ou duração predeterminada que o destinatário dos dados protegidos pode esperar).

Tipos de nível de alerta

Código	Tipo de nível	Estado de conexão
1	aviso	a conexão ou a segurança podem ser instáveis.
2	fatal	a conexão ou a segurança podem estar comprometidas ou ocorreu um erro irrecuperável.

Descrição

Este campo identifica qual tipo de alerta está sendo enviado.

Tipos de descrição de alerta

Código	Descrição	Tipos de nível	Observação
0	Fechar notificação	aviso / fatal
10	Mensagem inesperada	fatal
20	Mau registro MAC	fatal	Possivelmente, uma implementação SSL incorreta ou carga útil foi adulterada, por exemplo, regra de firewall de FTP no servidor FTPS.
21	A desencriptação falhou	fatal	Apenas TLS, reservado
22	Estouro de registro	fatal	Apenas TLS
30	Falha de descompressão	fatal
40	Falha de handshake	fatal
41	Sem certificado	aviso / fatal	SSL 3.0 apenas, reservado
42	Certificado ruim	aviso / fatal
43	Certificado não suportado	aviso / fatal	por exemplo, o certificado tem apenas o uso de autenticação de servidor habilitado e é apresentado como um certificado de cliente
44	Certificado revogado	aviso / fatal
45	Certificado expirado	aviso / fatal	Verifique a expiração do certificado do servidor também verifique se nenhum certificado da cadeia apresentada expirou
46	Certificado desconhecido	aviso / fatal
47	Parâmetro ilegal	fatal
48	CA desconhecido ( autoridade de certificação )	fatal	Apenas TLS
49	Acesso negado	fatal	Apenas TLS - por exemplo, nenhum certificado de cliente foi apresentado (TLS: mensagem de certificado em branco ou SSLv3: Nenhum alerta de certificado), mas o servidor está configurado para exigir um.
50	Erro de decodificação	fatal	Apenas TLS
51	Erro de descriptografia	aviso / fatal	Apenas TLS
60	Restrição de exportação	fatal	Apenas TLS, reservado
70	Versão do protocolo	fatal	Apenas TLS
71	Segurança insuficiente	fatal	Apenas TLS
80	Erro interno	fatal	Apenas TLS
86	Fallback impróprio	fatal	Apenas TLS
90	Usuário cancelado	fatal	Apenas TLS
100	Sem renegociação	aviso	Apenas TLS
110	Extensão não suportada	aviso	Apenas TLS
111	Certificado não obtido	aviso	Apenas TLS
112	Nome não reconhecido	aviso / fatal	Apenas TLS; O indicador de nome do servidor do cliente especificou um nome de host não suportado pelo servidor
113	Resposta de status de certificado ruim	fatal	Apenas TLS
114	Valor de hash de certificado inválido	fatal	Apenas TLS
115	Identidade PSK desconhecida (usada em TLS-PSK e TLS-SRP )	fatal	Apenas TLS

Protocolo ChangeCipherSpec

Formato de registro TLS para protocolo ChangeCipherSpec

Desvio	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	20	N / D
Bytes 1..4	Versão legada		Comprimento
	(Principal)	(Menor)	0	1
Byte 5	Tipo de protocolo CCS	N / D

Tipo de protocolo CCS

Atualmente, apenas 1.

Protocolo de aplicação

Formato de registro TLS para protocolo de aplicativo

Desvio	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	23	N / D
Bytes 1..4	Versão legada		Comprimento
	(Principal)	(Menor)	(bits 15..8)	(bits 7..0)
Bytes 5 .. ( m -1)	Dados de aplicativos
Bytes m .. ( p -1)	MAC (opcional)
Bytes p .. ( q −1)	Preenchimento (apenas cifras de bloco)

Comprimento

Comprimento dos dados do aplicativo (excluindo o cabeçalho do protocolo e incluindo o MAC e trailers de preenchimento)

MAC

32 bytes para o HMAC baseado em SHA-256 , 20 bytes para o HMAC baseado em SHA-1 , 16 bytes para o HMAC baseado em MD5 .

Preenchimento

Comprimento variável; o último byte contém o comprimento de preenchimento.

Suporte para servidores virtuais baseados em nomes

Do ponto de vista do protocolo de aplicativo, o TLS pertence a uma camada inferior, embora o modelo TCP / IP seja muito grosseiro para mostrá-lo. Isso significa que o handshake TLS é geralmente (exceto no caso STARTTLS ) executado antes que o protocolo do aplicativo possa ser iniciado. No recurso de servidor virtual baseado em nome fornecido pela camada de aplicativo, todos os servidores virtuais co-hospedados compartilham o mesmo certificado porque o servidor deve selecionar e enviar um certificado imediatamente após a mensagem ClientHello. Este é um grande problema em ambientes de hospedagem porque significa compartilhar o mesmo certificado entre todos os clientes ou usar um endereço IP diferente para cada um deles.

Existem duas soluções alternativas conhecidas fornecidas pelo X.509 :

• Se todos os servidores virtuais pertencerem ao mesmo domínio, um certificado curinga pode ser usado. Além da seleção flexível do nome do host, que pode ser um problema ou não, não há um acordo comum sobre como combinar certificados curinga. Regras diferentes são aplicadas dependendo do protocolo do aplicativo ou software usado.
• Adicione cada nome de host virtual na extensão subjectAltName. O principal problema é que o certificado precisa ser reemitido sempre que um novo servidor virtual é adicionado.

Para fornecer o nome do servidor, as extensões TLS (Transport Layer Security) RFC  4366 permitem que os clientes incluam uma extensão de indicação de nome de servidor (SNI) na mensagem ClientHello estendida. Esta extensão indica ao servidor imediatamente qual nome o cliente deseja se conectar, para que o servidor possa selecionar o certificado apropriado para enviar aos clientes.

A RFC  2817 também documenta um método para implementar hospedagem virtual baseada em nome, atualizando HTTP para TLS por meio de um cabeçalho de atualização HTTP / 1.1 . Normalmente, isso é para implementar com segurança HTTP sobre TLS dentro do esquema URI "http" principal (que evita a bifurcação do espaço de URI e reduz o número de portas usadas); no entanto, poucas implementações suportam isso atualmente.

Padrões

Padrões primários

A versão aprovada atual do TLS é a versão 1.3, que é especificada em:

• RFC  8446 : "O protocolo TLS (Transport Layer Security) versão 1.3".

O padrão atual substitui essas versões anteriores, que agora são consideradas obsoletas:

• RFC  2246 : "O protocolo TLS versão 1.0".
• RFC  4346 : "The Transport Layer Security (TLS) Protocol Version 1.1".
• RFC  5246 : "O protocolo TLS (Transport Layer Security) versão 1.2".

Além dos nunca padronizados SSL 2.0 e 3.0, considerados obsoletos:

• Rascunho da Internet (1995) , SSL Versão 2.0
• RFC  6101 : "O protocolo Secure Sockets Layer (SSL) versão 3.0".

Extensões

Outras RFCs estenderam posteriormente o TLS.

As extensões para TLS 1.0 incluem:

• RFC  2595 : "Usando TLS com IMAP, POP3 e ACAP". Especifica uma extensão para os serviços IMAP, POP3 e ACAP que permitem que o servidor e o cliente usem a segurança da camada de transporte para fornecer comunicação privada autenticada pela Internet.
• RFC  2712 : "Adição de Kerberos Cipher Suites ao Transport Layer Security (TLS)". Os conjuntos de criptografia de 40 bits definidos neste memorando aparecem apenas com o propósito de documentar o fato de que esses códigos de conjunto de criptografia já foram atribuídos.
• RFC  2817 : "Atualizando para TLS em HTTP / 1.1", explica como usar o mecanismo de atualização em HTTP / 1.1 para iniciar o Transport Layer Security (TLS) em uma conexão TCP existente. Isso permite que o tráfego HTTP não seguro e protegido compartilhe a mesma porta conhecida (neste caso, http: em 80 em vez de https: em 443).
• RFC  2818 : "HTTP sobre TLS", distingue o tráfego seguro do tráfego inseguro pelo uso de uma 'porta de servidor' diferente.
• RFC  3207 : "Extensão do serviço SMTP para SMTP seguro sobre segurança da camada de transporte". Especifica uma extensão para o serviço SMTP que permite que um servidor e cliente SMTP usem a segurança da camada de transporte para fornecer comunicação privada autenticada pela Internet.
• RFC  3268 : "AES Ciphersuites para TLS". Adiciona conjuntos de cifras Advanced Encryption Standard (AES) às cifras simétricas existentes anteriormente.
• RFC  3546 : "Extensões de Segurança da Camada de Transporte (TLS)", adiciona um mecanismo para negociar extensões de protocolo durante a inicialização da sessão e define algumas extensões. Tornado obsoleto pela RFC  4366 .
• RFC  3749 : "Métodos de compactação de protocolo de segurança da camada de transporte", especifica a estrutura para métodos de compactação e o método de compactação DEFLATE .
• RFC  3943 : "Compactação de protocolo de segurança da camada de transporte (TLS) usando Lempel-Ziv-Stac (LZS)".
• RFC  4132 : "Adição de Camellia Cipher Suites ao Transport Layer Security (TLS)".
• RFC  4162 : "Adição de SEED Cipher Suites ao Transport Layer Security (TLS)".
• RFC  4217 : "Protegendo o FTP com TLS ".
• RFC  4279 : "Conjuntos de criptografia de chave pré-compartilhada para segurança da camada de transporte (TLS)", adiciona três conjuntos de novos conjuntos de criptografia para o protocolo TLS para oferecer suporte à autenticação baseada em chaves pré-compartilhadas.

As extensões para TLS 1.1 incluem:

• RFC  4347 : " Segurança da camada de transporte de datagrama " especifica uma variante TLS que funciona sobre protocolos de datagrama (como UDP).
• RFC  4366 : "Extensões de Segurança da Camada de Transporte (TLS)" descreve um conjunto de extensões específicas e um mecanismo de extensão genérico.
• RFC  4492 : " Conjuntos de criptografia de criptografia de curva elíptica (ECC) para segurança da camada de transporte (TLS)".
• RFC  4680 : "Mensagem de handshake TLS para dados suplementares".
• RFC  4681 : "Extensão de mapeamento de usuário TLS".
• RFC  4785 : "Conjuntos de criptografia de chave pré-compartilhada (PSK) com criptografia NULL para segurança da camada de transporte (TLS)".
• RFC  5054 : "Usando o protocolo de senha remota segura (SRP) para autenticação TLS". Define os pacotes de criptografia TLS-SRP .
• RFC  5077 : "Reinício da sessão do Transport Layer Security (TLS) sem o estado do lado do servidor".
• RFC  5081 : "Usando chaves OpenPGP para autenticação TLS (Transport Layer Security)", obsoleto pelo RFC  6091 .

As extensões para TLS 1.2 incluem:

• RFC  5288 : " Conjuntos de cifras do modo de contador AES Galois (GCM) para TLS".
• RFC  5289 : "TLS Elliptic Curve Cipher Suites com SHA-256/384 e AES Galois Counter Mode (GCM)".
• RFC  5746 : "Extensão de indicação de renegociação do Transport Layer Security (TLS)".
• RFC  5878 : "Extensões de autorização do Transport Layer Security (TLS)".
• RFC  5932 : "Camellia Cipher Suites for TLS"
• RFC  6066 : "Extensões de Segurança da Camada de Transporte (TLS): Definições de Extensão", inclui Indicação de Nome de Servidor e grampeamento OCSP .
• RFC  6091 : "Usando chaves OpenPGP para autenticação TLS (Transport Layer Security)".
• RFC  6176 : "Proibindo Secure Sockets Layer (SSL) Versão 2.0".
• RFC  6209 : "Adição dos ARIA Cipher Suites ao Transport Layer Security (TLS)".
• RFC  6347 : "Datagram Transport Layer Security Versão 1.2".
• RFC  6367 : "Adição dos Camellia Cipher Suites ao Transport Layer Security (TLS)".
• RFC  6460 : "Perfil Suite B para Transport Layer Security (TLS)".
• RFC  6655 : "AES-CCM Cipher Suites para Transport Layer Security (TLS)".
• RFC  7027 : "Curvas Brainpool da Criptografia da Curva Elíptica (ECC) para Segurança da Camada de Transporte (TLS)".
• RFC  7251 : "Conjuntos de criptografia de criptografia de curva elíptica (ECC) AES-CCM para TLS".
• RFC  7301 : " Extensão de negociação de protocolo de camada de aplicativo Transport Layer Security (TLS) ".
• RFC  7366 : "Encrypt-then-MAC for Transport Layer Security (TLS) e Datagram Transport Layer Security (DTLS)".
• RFC  7465 : "Proibindo suítes de criptografia RC4".
• RFC  7507 : "TLS Fallback Signaling Cipher Suite Value (SCSV) para prevenir ataques de downgrade de protocolo".
• RFC  7568 : "Reprovação do Secure Sockets Layer versão 3.0".
• RFC  7627 : "Hash da sessão do Transport Layer Security (TLS) e extensão do segredo mestre estendido".
• RFC  7685 : "Uma extensão de preenchimento de ClientHello do Transport Layer Security (TLS)".

Os encapsulamentos de TLS incluem:

• RFC  5216 : "O protocolo de autenticação EAP -TLS"

RFCs informativos

• RFC  7457 : "Resumindo Ataques Conhecidos na Segurança da Camada de Transporte (TLS) e no Datagrama TLS (DTLS)"
• RFC  7525 : "Recomendações para o uso seguro de Transport Layer Security (TLS) e Datagram Transport Layer Security (DTLS)"

Veja também

• Negociação de protocolo de camada de aplicativo - uma extensão TLS usada para SPDY e TLS False Start
• Bullrun (programa de descriptografia) - um programa secreto de anti-criptografia executado pela Agência de Segurança Nacional dos Estados Unidos
• Autoridade certificadora
• Transparência de certificado
• HTTP Strict Transport Security - HSTS
• Arquivo de chaveiro
• QUIC (Quick UDP Internet Connections) - "... foi projetado para fornecer proteção de segurança equivalente a TLS / SSL"; O objetivo principal do QUIC é melhorar o desempenho percebido de aplicativos da web orientados a conexão que estão usando TCP atualmente
• Criptografia controlada por servidor
• tcpcrypt
• DTLS
• Aceleração TLS

Referências

Leitura adicional

• Wagner, David; Schneier, Bruce (novembro de 1996). "Análise do protocolo SSL 3.0" (PDF) . O Segundo Workshop USENIX sobre Procedimentos de Comércio Eletrônico . USENIX Press. pp. 29–40.
• Eric Rescorla (2001). SSL e TLS: Projetando e criando sistemas seguros . Estados Unidos: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
• Stephen A. Thomas (2000). Fundamentos de SSL e TLS protegendo a web . Nova York: Wiley. ISBN 978-0-471-38354-3.
• Bard, Gregory (2006). "Um desafio de texto simples e adaptável em bloco, desafiador, mas viável, em SSL" . International Association for Cryptologic Research (136) . Página visitada em 2011-09-23 .
• Canvel, Brice. "Interceptação de senha em um canal SSL / TLS" . Página visitada em 2007-04-20 .
• Autores múltiplos da IETF. "RFC de mudança para renegociação de TLS" . Página visitada em 11/12/2009 .
• Artigo Criando VPNs com IPsec e SSL / TLS Linux Journal por Rami Rosen
• Joshua Davies (2010). Implementando SSL / TLS . Wiley. ISBN 978-0470920411.
• Polk, Tim; McKay, Kerry; Chokhani, Santosh (abril de 2014). "Diretrizes para a seleção, configuração e uso de implementações de segurança da camada de transporte (TLS)" (PDF) . Instituto Nacional de Padrões e Tecnologia. Arquivado do original (PDF) em 08/05/2014 . Página visitada em 07-05-2014 .
• Abdou, AbdelRahman; van Oorschot, Paul (agosto de 2017). "Server Location Verification (SLV) e Server Location Pinning: Augmenting TLS Authentication" . Transações sobre privacidade e segurança . ACM. 21 (1): 1: 1-1: 26. doi : 10.1145 / 3139294 . S2CID  5869541 .

links externos

• Grupo de trabalho TLS da IETF (Internet Engineering Task Force)