Transport Layer Security

Pilha de protocolos TCP/IP
Camada de aplicação
DHCP DNS FTP HTTP HTTPS IMAP LDAP MGCP NNTP NTP POP ONC/RPC RTP SIP SMTP SNMP SSH Telnet TLS/SSL XMPP outros…
Camada de transporte
TCP UDP DCCP SCTP RSVP outros…
Camada de rede
OSPF IP IPv4 IPv6 ICMP ICMPv6 ECN IGMP IPsec
Camada de enlace de dados
NDP ARP túneis… L2TP PPP MAC Ethernet DSL RDIS FDDI outros…

O Transport Layer Security (TLS), assim como o seu antecessor Secure Sockets Layer (SSL), é um protocolo de segurança projetado para fornecer segurança nas comunicações sobre uma rede de computadores. Várias versões do protocolo encontram amplo uso em aplicativos como navegação na web, email, mensagens instantâneas e voz sobre IP (VoIP). Os sites podem usar o TLS para proteger todas as comunicações entre seus servidores e navegadores web.

O protocolo TLS visa principalmente fornecer privacidade e integridade de dados entre dois ou mais aplicativos de computador que se comunicam. Quando protegidos por TLS, 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 a criptografia simétrica é usada 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 (veja § Handshake TLS). 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 (ver § Algoritmo 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 coloque no meio da conexão) e confiável (nenhum invasor pode modificar as comunicações durante a negociação sem ser detectado).
• A identidade das partes em comunicação pode ser autenticada usando criptografia de chave pública. Essa autenticação pode ser opcional, mas geralmente é necessária para pelo menos uma das partes (geralmente o servidor).
• A conexão é confiável porque cada mensagem transmitida inclui uma verificação de integridade de 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 das propriedades acima, a configuração cuidadosa do 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 as comunicações TLS registradas no passado.

O TLS suporta muitos métodos diferentes para trocar chaves, criptografar dados e autenticar a integridade da mensagem (consulte § Algoritmo abaixo). Como resultado, a configuração segura do TLS envolve muitos parâmetros configuráveis ​​e nem todas as opções fornecem todas as propriedades relacionadas à privacidade descritas na lista acima (consulte § Troca de chave (autenticação), § Segurança de codificação e § Tabelas de integridade de dados).

Tentativas foram feitas para subverter aspectos da segurança das comunicações que o TLS procura fornecer, e o protocolo foi revisado várias vezes para lidar com essas ameaças de segurança (ver § Segurança). Os desenvolvedores de navegadores da Web também revisaram seus produtos para se defenderem de potenciais pontos fracos de segurança depois que eles foram descobertos (veja o histórico de suporte a TLS / SSL dos navegadores da Web).

O protocolo TLS compreende duas camadas: o registro TLS e os protocolos de handshake TLS.

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

Descrição

Aplicações cliente-servidor fazem uso do protocolo TLS para se comunicar através de uma rede de forma a prevenir a interceptação e adulteração da informação.

Uma vez que aplicações podem se comunicar tanto através de TLS (ou SSL) como sem ele, é necessário que o cliente sinalize ao servidor para a configuração de uma conexão TLS. Uma das maneiras de se obter isso é utilizar números de porta diferentes, por exemplo a porta 443 para HTTPS. Outro mecanismo é uma requisição específica por parte do cliente ao servidor para uma transição para a conexão TLS; por exemplo, ao fazer uma requisição STARTTLS ao utilizar protocolos de email.

Uma vez que o cliente e o servidor concordaram quanto ao uso do TLS, eles negociam uma conexão de estado por meio de um procedimento de handshake. Os protocolos utilizam um handshake com uma chave pública para estabelecer as configurações de criptografia e uma chave de sessão única compartilhada através da qual toda a comunicação é criptografada utilizando uma chave simétrica. Durante esse handshake, o cliente e o servidor concordam a respeito dos vários parâmetros necessários para estabelecer a segurança da conexão:

• O handshake é iniciado quando o cliente se conecta a um servidor habilitado para TLS requisitando uma conexão segura e apresentando uma lista de algoritmos suportados (cifras e funções hash).
• A partir dessa lista, o servidor seleciona uma cifra e uma função hash para as quais também tenha suporte e notifica ao cliente a decisão.
• O servidor então geralmente apresenta informações de identificação na forma de um certificado digital. O certificado contém o nome do servidor, a autoridade de certificação (CA) que concedeu o certificado, e a chave pública do servidor.
• O cliente confirma a validade do certificado antes de continuar.
• Para gerar as chaves de sessão utilizadas na conexão segura, o cliente:
  • criptografa um número aleatório com a chave pública recebida e envia o resultado ao servidor (o único capaz de descriptografar a mensagem com sua chave privada); ambas as partes então fazem uso do número aleatório para gerar uma chave de sessão única para a criptografia subsequente dos dados durante a sessão, ou
  • inicia uma troca de chaves de Diffie-Hellman para gerar seguramente uma chave de sessão aleatória e única, utilizada para criptografar e descriptografar os dados e que ainda possui a propriedade de foward secrecy: caso a chave privada do servidor seja vazada no futuro, ela é incapaz de descriptografar a sessão atual, mesmo que esta tenha sido 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é o fim da conexão. Se qualquer um dos passos acima falhar, o handshake TLS também falha e a conexão não é criada.

Os protocolos TLS e SSL não se encaixam perfeitamente em nenhuma camada dos modelos OSI ou TCP/IP. O TLS é implementado "sobre um protocolo de comunicação confiável (por exemplo, o TCP)", o que implica que ele está acima da camada de transporte. Ele serve para criptografar as camadas superiores, o que normalmente seria função da camada de apresentação. Contudo, as aplicações geralmente fazem uso do TLS como se fosse uma camada de transporte, mesmo que essas aplicações devam controlar ativamente o início dos procedimentos de handshake e o gerenciamento dos certificados de autenticação compartilhados.

Protocolo TLS

Funcionamento

O servidor do site que está sendo acessado envia uma chave pública ao browser, usada por este para enviar uma chave secreta simetrica, criada aleatoriamente. Desta forma, fica estabelecida a troca de dados criptografados entre dois computadores.Baseia-se no protocolo TCP da suíte TCP/IP e utiliza-se do conceito introduzido por Diffie-Hellman nos anos 70 (criptografia de chave pública) e Phil Zimmermann (criador do conceito PGP).

História e desenvolvimento

A primeira versão foi desenvolvida pela Netscape em 1994. O SSL versão 3.0 foi lançado em 1996, e serviu posteriormente de base para o desenvolvimento do TLS versão 1.0, um protocolo padronizado da IETF originalmente definido pelo RFC 2246. Grandes instituições financeiras como Visa, MasterCard, American Express, dentre outras, aprovaram o SSL para comércio eletrônico seguro na Internet.O SSL opera de forma modular, possui design extensível e apresenta compatibilidade entre pares com versões diferentes do mesmo.O SSL executa a autenticação das 2 partes envolvidas nas comunicações (cliente e servidor) baseando-se em certificados digitais.

O TLS passou por várias versões ao longo dos anos, cada uma trazendo melhorias em segurança e desempenho. Aqui está um resumo das principais versões e suas novidades:

• TLS 1.0 (1999): Essa foi a primeira versão do TLS, projetada como uma atualização segura do SSL 3.0. Apesar de aprimorar a segurança, ela ainda tinha algumas vulnerabilidades e foi amplamente usada até ser considerada insegura para contextos modernos.

• TLS 1.1 (2006): Trouxe melhorias na segurança, como a proteção contra ataques de injeção de IV (Initialization Vector), mas ainda apresentava falhas em alguns aspectos, sendo logo substituída em favor de uma versão mais segura.

• TLS 1.2 (2008): Esta versão trouxe melhorias significativas, com suporte para algoritmos de criptografia mais fortes, como SHA-256, e mais flexibilidade nas suítes de criptografia, além de ser resistente a vários tipos de ataques conhecidos na época. Até hoje, é uma das versões mais amplamente utilizadas, embora a adoção do TLS 1.3 esteja crescendo.

• TLS 1.3 (2018): A versão mais recente, o TLS 1.3, removeu algoritmos obsoletos e inseguros, simplificou o processo de handshake (tornando a conexão mais rápida e segura) e aumentou a privacidade dos dados. Além disso, o TLS 1.3 permite menos idas e vindas entre o cliente e o servidor, reduzindo a latência e melhorando a eficiência.

Segurança

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

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

A Apple corrigiu a vulnerabilidade 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.

A falha POODLE (Padding Oracle On Downgraded Legacy Encryption) é uma vulnerabilidade descoberta em 2014 que afeta o protocolo SSL 3.0, mas também impacta o TLS nas versões até o TLS 1.1. Para mitigar o POODLE, a recomendação foi desabilitar o suporte ao SSL 3.0 nos servidores e nos navegadores.

Ver também

• PGP
• OpenPGP
• GnuPG
• Certificado EV SSL
• Criptografia

Ligações externas

• The TLS Protocol, Version 1.0 (em inglês). RFC 2246 (descrição do protocolo TLS 1.0). Visitado em 15 de outubro de 2014.
• TLS The Transport Layer Security (TLS) Protocol Version 1.2(RFC)
• The Transport Layer Security (TLS) Protocol Version 1.1(RFC)
• Especificação Original Arquivado em 13 de junho de 2006, no Wayback Machine.
• Biblioteca aberta que implementa SSL
• Transport Layer Security (TLS) e Secure Sockets Layer (SSL)