O que é TLS e como funciona?

O TLS (Transport Layer Security) é um dos protocolos de segurança mais importantes e amplamente utilizados. Ele protege uma proporção significativa dos dados que são transmitidos online. É mais proeminente usado para proteger os dados que trafegam entre um navegador da web e um site via HTTPS, mas também pode ser usado para proteger email e vários outros protocolos.

O TLS é valioso porque garante que a outra parte da conexão seja quem eles dizem ser, mostra se os dados mantêm sua integridade inicial e fornece confidencialidade por meio de criptografia.

O TLS usa uma variedade de diferentes algoritmos e esquemas para atingir esses objetivos. Pode parecer complicado, mas este artigo abordará um aspecto de cada vez para fornecer uma visão detalhada de como o TLS funciona para proteger conexões.

O que o TLS faz?

Ao enviar informações on-line, encontramos três grandes problemas de segurança:

• Como podemos saber se a pessoa com quem estamos nos comunicando é realmente quem eles dizem ser?
• Como podemos saber que os dados não foram adulterados desde que foram enviados?
• Como podemos impedir que outras pessoas vejam e acessem os dados?

Essas questões são cruciais, especialmente quando estamos enviando informações confidenciais ou valiosas. O TLS usa uma variedade de técnicas criptográficas para resolver cada um desses três problemas. Juntos, eles permitem que o protocolo autenticar a outra parte em uma conexão, verificar a integridade dos dados e fornecer proteção criptografada.

Vamos simplificar as coisas e fingir que você está tentando transferir informações com um amigo que mora em todo o país. Se a informação for sensível, você ficará muito preocupado com os três principais problemas mencionados acima.

Você não pode simplesmente enviar uma carta e esperar o melhor, especialmente se suspeitar que suas comunicações serão direcionadas pelos invasores. Em vez disso, você precisa de um sistema que permita verificar se o destinatário é legítimo, uma maneira de verificar se as mensagens foram alteradas e uma maneira de protegê-las de olhares indiscretos..

O TLS atende a esses requisitos usando vários processos diferentes. Começa com o que é conhecido como Aperto de mão TLS, onde a autenticação ocorre e as chaves são estabelecidas.

Para retornar à nossa analogia com as cartas, a parte de autenticação do TLS seria como enviar uma carta por um correio que requer identificação. Quando o correio entrega a carta, eles comparam o ID da pessoa com o rosto e verificam se o destinatário era ou não a pessoa correta.

A principal fase de estabelecimento seria um pouco como se sua carta contivesse metade de um número de PIN que você pretendia usar em comunicações futuras. Você pediria ao destinatário que apresentasse a segunda metade do número e o enviasse na carta de retorno.

Depois que o correio verificar a identidade e o número do PIN tiver sido estabelecido, você terá tudo o que precisa para enviar informações com segurança. Na realidade, esses estágios são muito mais complexos, mas chegaremos a isso mais tarde.

O TLS troca informações com segurança com o protocolo do aplicativo. Para continuar nossa analogia, transmitir dados com segurança via TLS seria como escrever uma mensagem e colocá-la em um envelope. Você escreveria sua assinatura no selo, para que, se a carta fosse adulterada, seu destinatário pudesse saber pela assinatura rasgada (na verdade, isso é feito com matemática, mas, novamente, abordaremos isso mais tarde).

Você colocaria a carta em uma pequena caixa de metal com uma trava combinada, definindo a combinação como o número do pino que você estabeleceu em conjunto com o destinatário. Você enviaria a caixa pelo correio que verifica a identificação quando os pacotes são entregues. Seu destinatário responderia da mesma maneira e qualquer comunicação futura seguiria as mesmas etapas.

O TLS resolve todos os três problemas de maneira relativamente semelhante. O correio serve para autenticar o destinatário e garantir que a caixa esteja sendo entregue à pessoa pretendida. A caixa bloqueada serve como uma forma de criptografia, impedindo que qualquer pessoa, exceto seu parceiro, acesse as letras. O envelope assinado permite que você saiba se a mensagem não foi violada.

Essa é uma aproximação aproximada do que o TLS faz. Na realidade, TLS ocorre entre clientes e servidores, em vez de duas pessoas que estão enviando mensagens uma para a outra. A analogia é apenas para fornecer uma visualização do que está acontecendo e o raciocínio por trás disso. Nas seções a seguir, abordaremos o que realmente acontece em detalhes.

TLS vs. SSL

Ao ler sobre TLS, você verá frequentemente menções de SSL ou mesmo como TLS / SSL. O Secure Sockets Layer (SSL) é a versão antiga do TLS, mas muitos no setor ainda se referem ao TLS sob o apelido antigo. Este artigo usará o termo TLS por toda parte, mas é importante observar que os nomes geralmente são usados ​​de forma intercambiável. Você pode ler mais sobre SSL em nosso guia.

A história do TLS

Tudo começou com a necessidade de proteger a camada de transporte. Como mencionamos acima, o precursor do TLS era o SSL. As primeiras versões do SSL foram desenvolvidas nos anos noventa pela Netscape, uma empresa que construiu um dos primeiros navegadores da web.

O SSL 1.0 nunca foi lançado porque continha vulnerabilidades graves. A versão 2.0 saiu com o Netscape Navigator 1.1 em 1995, no entanto, ainda continha uma série de falhas sérias. O SSL 3.0 era uma versão fortemente redesenhada e saiu em 1996, com muitos dos problemas de segurança resolvidos.

Em 1996, o IETF lançou um rascunho do SSL 3.0 no RFC 6101. A IETF formou um grupo de trabalho para padronizar o SSL, publicando os resultados em 1999 como TLS 1.0. Foi documentado na RFC 2246 e a padronização incluiu algumas alterações no protocolo original, além da alteração do nome. Essas modificações surgiram como resultado de negociações entre a Netscape, a Microsoft e o grupo de trabalho da IETF.

Em 2006, a IETF lançou o RFC 4346, que documenta o TLS 1.1. Esta versão continha novas disposições de segurança e várias outras atualizações. A versão 1.2 foi lançada apenas dois anos depois em 2008. Ela incluía suporte para cifras de criptografia autenticadas, várias alterações na forma como as funções de hash foram usadas e muitas outras melhorias.

A próxima versão não chegou até 2023, quando o TLS 1.3 foi definido. Ele apresenta uma série de alterações, incluindo sigilo direto forçado, remoção de suporte a algoritmos mais fracos e muito mais.

O TLS 1.0 e 1.1 agora está definido para ser descontinuado em 2023, mas a versão 1.2 está em uso generalizado. A versão 1.3 está começando a ver uma maior adoção.

TLS: Os detalhes técnicos

O TLS consiste em muitos elementos diferentes. A parte fundamental é o protocolo de registro, o protocolo subjacente responsável pela estrutura abrangente de todo o resto.

Diagrama mostrando a pilha TLS. Pilha de protocolos TLS de Jeffreytedjosukmono. Licenciado sob CC0.

O protocolo de registro contém cinco subprotocolo separados, cada um deles formatado como registros:

• Aperto de mão – Este protocolo é usado para configurar os parâmetros para uma conexão segura.
• Inscrição – O protocolo de aplicação começa após o processo de handshake e é onde os dados são transmitidos com segurança entre as duas partes.
• Alerta – O protocolo de alerta é usado por uma das partes em uma conexão para notificar a outra se houver algum erro, problema de estabilidade ou possível comprometimento.
• Alterar especificação de cifra – Este protocolo é usado pelo cliente ou pelo servidor para modificar os parâmetros de criptografia. É bem direto, então não abordaremos detalhadamente neste artigo.
• Batimento cardiaco – Esta é uma extensão TLS que permite que um lado da conexão saiba se seu par ainda está ativo e impede que os firewalls fechem conexões inativas. Não é uma parte essencial do TLS, portanto, vamos ignorá-lo neste guia.

Cada um desses subprotocolo é usado em diferentes estágios para comunicar informações diferentes. Os mais importantes a serem entendidos são os protocolos de handshake e de aplicativo, porque eles são responsáveis ​​por estabelecer a conexão e depois transmitir com segurança os dados.

O protocolo de handshake TLS

É aqui que a conexão é estabelecida de maneira segura. Pode parecer complexo se você é novo em alguns conceitos, mas cada um deles será abordado mais adiante neste artigo, se precisar consultá-los.

Existem três tipos básicos de handshake TLS: o aperto de mão TLS básico, a handshake TLS autenticado pelo cliente e a aperto de mão abreviado.

O handshake básico do TLS

Diagrama mostrando o processo de handshake TLS. Aperto de mão TLS 1.2 completo da FleshGrinder. Licenciado sob CC0.

Nesse tipo de handshake, apenas o servidor é autenticado e não o cliente. Começa com a fase de negociação, na qual um cliente envia uma Olá cliente mensagem. Ele contém a versão mais alta do TLS que o cliente suporta, possíveis conjuntos de criptografia, uma indicação sobre se ele suporta compactação, um número aleatório e outras informações.

A mensagem Hello do cliente é recebida com um Olá servidor mensagem. Esta resposta contém o ID da sessão, a versão do protocolo, o conjunto de cifras e a compactação (se houver alguma em uso) que o servidor selecionou na lista do cliente. Também inclui um número aleatório diferente.

Depende do conjunto de cifras selecionado, mas o servidor geralmente segue isso enviando um Certificado mensagem para autenticação. Isso valida sua identidade e contém sua chave pública.

Se estiverem sendo usadas trocas de chaves efêmeras Diffie-Hellman ou Diffie-Hellman anônimas, isso será seguido por um Troca de Chaves do Servidor mensagem. Outros métodos de troca de chaves pulam esta parte. Quando o servidor termina o seu lado da negociação, ele envia um Olá Servidor Concluído mensagem.

Agora é a vez do cliente novamente. Dependendo do conjunto de cifras escolhido, ele enviará um Troca de Chaves do Cliente mensagem. Isso pode conter uma chave pública ou um segredo de pré-mestre, criptografado com a chave pública do servidor.

Ambas as partes usam os números aleatórios e o segredo do pré-mestre para criar um segredo principal. As chaves são derivadas do segredo principal, que são usadas para autenticar e criptografar as comunicações.

O cliente então envia uma Alterar especificação de cifra mensagem. Isso informa ao servidor que as seguintes mensagens agora serão autenticadas e criptografadas (embora algumas vezes a criptografia não possa ser usada).

O cliente então segue isso com um Acabado , criptografada e também contém um código de autenticação de mensagens (MAC) para autenticação. O servidor descriptografa essa mensagem e verifica o MAC. Se algum desses processos falhar, a conexão deverá ser rejeitada.

Agora é a vez do servidor enviar um Alterar especificação de cifra mensagem, bem como uma Acabado mensagem com o mesmo conteúdo acima. O cliente também tenta descriptografar e verificar o conteúdo. Se tudo isso for concluído com êxito, o handshake será concluído. Neste ponto, o protocolo do aplicativo é estabelecido. Os dados podem ser trocados com segurança da mesma maneira que o Acabado mensagem de cima, com autenticação e criptografia opcional.

Handshake TLS autenticado pelo cliente

Esse handshake é muito parecido com o handshake TLS básico, mas o cliente também é autenticado. A principal diferença é que, após o servidor enviar sua Certificado mensagem, também envia uma Solicitação de certificado mensagem, solicitando o certificado do cliente. Após a conclusão do servidor, o cliente envia seu certificado em um Certificado mensagem.

O cliente então envia sua Troca de Chaves do Cliente mensagem, assim como no handshake TLS básico. Isto é seguido pelo Verificação de certificado mensagem, que inclui a assinatura digital do cliente. Como é calculado a partir da chave privada do cliente, o servidor pode verificar a assinatura usando a chave pública que foi enviada como parte do certificado digital do cliente. O resto do Handshake TLS autenticado pelo cliente segue as mesmas linhas do handshake TLS básico.

Aperto de mão TLS abreviado

Depois que um aperto de mão já ocorre, o TLS permite que grande parte do processo seja cortado usando um aperto de mão abreviado. Esses handshakes usam o ID da sessão para vincular a nova conexão aos parâmetros anteriores.

Um handshake abreviado permite que ambas as partes continuem a conexão segura com a mesma configuração que foi negociada anteriormente. Como parte da criptografia normalmente envolvida no início de um aperto de mão pode ser bastante pesada em recursos computacionais, isso economiza tempo e facilita a conexão.

O processo começa com o Olá cliente mensagem. É muito parecido com a mensagem anterior do Client Hello, mas também contém o identificação de sessão da conexão anterior. Se o servidor souber o ID da sessão, ele será incluído em seu Olá servidor mensagem. Se ele não reconhecer o ID da sessão, ele retornará um número diferente e um handshake TLS completo terá que ocorrer..

Se o servidor reconhecer o ID da sessão, o Certificado e Troca de chaves etapas podem ser puladas. o Alterar especificação de cifra e Acabado as mensagens são enviadas da mesma maneira que o handshake TLS básico mostrado acima. Depois que o cliente descriptografa a mensagem e verifica o MAC, os dados podem ser enviados através da conexão TLS segura.

Há também uma extensão TLS que permite que as conexões sejam retomadas com tickets de sessão em vez de IDs de sessão. O servidor criptografa os dados sobre a sessão e os envia para o cliente. Quando o cliente deseja retomar essa conexão, envia o tíquete da sessão ao servidor, que o descriptografa para revelar os parâmetros.

Os tíquetes de sessão não são usados ​​com tanta frequência porque exigem a extensão. Apesar disso, eles podem ser vantajosos em determinadas situações, porque o servidor não precisa armazenar nada.

Como desembalar o handshake TLS

As três etapas mais importantes do aperto de mão incluem:

• os parâmetros são selecionados,
• realiza autenticação e
• as chaves são estabelecidas.

Vamos abordá-los um pouco mais detalhadamente para que você possa entender o que realmente está acontecendo.

Os parametros

No início do handshake, o cliente e o servidor negociam os parâmetros da conexão de comum acordo. A primeira delas é qual versão do TLS será usada. Esta é a versão mais alta suportada por ambas as partes, que tende a ser a mais segura.

As partes também decidem qual algoritmo de troca de chaves serão usadas para estabelecer a chave mestra. A função hash, o algoritmo de criptografia e o método de compactação também são acordados neste estágio. Estes serão abordados em detalhes quando discutirmos o Protocolo de aplicação mais adiante no artigo.

Autenticação: certificados digitais

A autenticação é uma parte essencial da segurança de um canal de comunicação, porque permite que ambas as partes saibam que estão realmente conversando com quem elas pensam que são e não como impostoras. No TLS e em muitos outros mecanismos de segurança, isso é alcançado com o que chamamos de certificados digitais.

Certificados digitais são documentos eletrônicos que mostram o link entre um indivíduo ou entidade e sua chave pública. Esse link é validado por uma autoridade de certificação (CA), que é uma organização confiável que verifica se os dois estão realmente relacionados e, em seguida, usa sua própria reputação para conceder confiança ao certificado.   

Diferentes níveis de certificado representam diferentes graus de confiança. O importante é saber que, se um cliente ou servidor tiver um certificado confiável e válido, é razoável supor que a chave pública é legítima e que você não está lidando com um invasor.

Uma nota sobre chaves públicas

A criptografia de chave pública (também conhecida como criptografia assimétrica) é uma parte importante da criptografia e é amplamente utilizada nos diferentes aspectos do TLS. Aqui está uma cartilha rápida para aqueles que não estão familiarizados com o funcionamento.

A breve explicação é que a criptografia de chave pública usa um par de chaves para criptografia e descriptografia, em vez de apenas uma única chave. O remetente usa a chave pública do destinatário pretendido para criptografar dados. Depois de criptografada, ela só pode ser descriptografada pela chave privada correspondente do destinatário. Obviamente, a chave pública pode ser compartilhada publicamente, enquanto a chave privada deve ser mantida em segredo.

A criptografia de chave pública permite que as partes compartilhem informações com segurança, mesmo que nunca tenham se encontrado ou tenham tido a oportunidade de trocar chaves com antecedência. Isso é feito através de algumas propriedades exclusivas dos números primos. Você pode descobrir mais em nosso artigo sobre criptografia de chave pública.

Estabelecendo um segredo principal

Como vimos acima, quando discutimos o processo do handshake TLS básico, depois que uma parte (ou ambas as partes) prova sua identidade com seu certificado público, o próximo passo é estabelecer o segredo principal, também conhecido como segredo compartilhado. O segredo principal é a base para derivar as chaves usadas para criptografar e verificar a integridade dos dados transmitidos entre as duas partes..

O handshake TLS pode usar vários mecanismos diferentes para compartilhar esse segredo com segurança. Isso inclui o RSA, vários tipos diferentes de troca de chaves Diffie-Hellman, PSK, Kerberos e outros. Cada um tem suas próprias vantagens e desvantagens, como fornecer sigilo adiante, mas essas diferenças estão fora do escopo deste artigo..

O processo exato dependerá de qual método de troca de chaves foi escolhido, mas segue as etapas básicas mencionadas em O handshake básico do TLS seção.

O segredo do pré-mestre é derivado de acordo com o método de troca de chaves previamente selecionado. O cliente criptografa o segredo do pré-mestre com a chave pública do servidor para enviá-lo com segurança pela conexão.

O cliente e o servidor usam o segredo do pré-mestre e os números aleatórios que eles enviaram no início da comunicação para criar o segredo do mestre. Depois que a chave mestra foi calculada, ela é usada para criar quatro ou seis chaves separadas. Estes são os:

• Chave MAC de gravação do cliente – Essa chave é usada pelo servidor para verificar a integridade dos dados enviados pelo cliente.
• Chave MAC de gravação do servidor – A chave MAC de gravação do servidor é usada pelo cliente para verificar a integridade dos dados enviados pelo servidor.
• Chave de criptografia de gravação do cliente – O servidor usa essa chave para criptografar dados que foram enviados pelo cliente.
• Chave de criptografia de gravação do servidor – O cliente usa essa chave para criptografar dados que foram enviados pelo servidor.
• Chave IV de gravação do cliente – A chave IV de gravação do cliente é usada pelo servidor nas cifras AEAD, mas não quando outros algoritmos de troca de chaves são usados.
• Chave IV de gravação do servidor – Da mesma forma, essa chave é usada pelo cliente nas cifras AEAD, mas não quando outros algoritmos de troca de chaves são usados.

O estabelecimento da chave mestra é uma parte importante do handshake TLS, pois permite que ambos os lados da conexão derivem com segurança chaves que podem ser usadas para autenticação e criptografia. Chaves separadas são usadas para ambos os processos como precaução.

Depois de derivadas as chaves de autenticação e criptografia, elas são usadas para proteger Acabado mensagens, bem como registros enviados através do protocolo do aplicativo.

O protocolo de aplicação

Depois que uma conexão segura é estabelecida pelo handshake TLS, o protocolo do aplicativo é usado para proteger os dados transmitidos. Ele pode ser configurado para usar uma ampla variedade de algoritmos para se adequar a diferentes cenários.

Algoritmos de autenticação

A integridade das mensagens pode ser verificada com muitos algoritmos diferentes. Esses incluem:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

Para provar a integridade dos dados enviados, o remetente executa as informações por meio de uma função de hash para retornar uma seqüência única de caracteres. Estas são fórmulas especiais que sempre retornam o mesmo resultado sempre que recebem a mesma entrada.

O remetente assina esses dados com sua chave privada para formar o que é conhecido como assinatura digital. A assinatura digital é anexada à mensagem e enviada ao destinatário. Para verificar se os dados mantêm sua integridade e não foram adulterados, o destinatário descriptografa o hash com a chave pública do remetente. Eles então usam a mesma função de hash nos dados que foram enviados. O destinatário então compara os dois valores.

Se forem iguais, significa que os dados não foram alterados desde que foram assinados pelo remetente. Se eles forem diferentes, é provável que os dados tenham sido adulterados ou se ocorreu algum outro erro..

Essa é a versão curta de como as funções de hash podem ser usadas para mostrar a integridade dos dados. Se você deseja uma compreensão mais aprofundada, consulte nosso artigo sobre criptografia, salga e hash.

Algoritmos de criptografia

O TLS usa criptografia de chave simétrica para fornecer confidencialidade aos dados que ele transmite. Diferentemente da criptografia de chave pública, apenas uma chave é usada nos processos de criptografia e descriptografia. Depois que os dados forem criptografados com um algoritmo, eles aparecerão como uma mistura de texto cifrado. Enquanto um algoritmo apropriado for usado, os invasores não poderão acessar os dados reais, mesmo se eles os interceptarem.

O TLS pode usar muitos algoritmos diferentes, como Camellia ou ARIA, embora o mais popular seja o AES.

Compressão

Compactação é o processo de codificação de dados para ocupar menos espaço. O TLS suporta compactação se os dois lados da conexão decidirem usá-lo. Apesar dessa capacidade, geralmente é recomendável evitar o uso do TLS para compactar dados, especialmente desde o ataque do CRIME (consulte o Problemas de segurança do TLS seção abaixo) foi capaz de tirar proveito dos dados compactados para o seqüestro de sessões.

Preenchimento

O preenchimento adiciona dados extras a uma mensagem antes de ser criptografada. É um processo criptográfico comum usado para ajudar a impedir que dicas na estrutura de dados criptografados revelem seu verdadeiro significado. O TLS geralmente aplica o preenchimento PKCS # 7 aos registros antes de serem criptografados.

Protocolo de alerta

Se a conexão ou segurança ficar instável, comprometida ou ocorrer um erro grave, o protocolo de alerta permite que o remetente notifique a outra parte. Essas mensagens têm dois tipos, aviso ou fatal. Uma mensagem de aviso indica que a sessão é instável e permite que o destinatário determine se a sessão deve ou não continuar.

Uma mensagem fatal informa ao destinatário que a conexão foi comprometida ou que ocorreu um erro grave. O remetente deve fechar a conexão depois de enviar a mensagem. O protocolo de alerta também contém informações sobre o que está causando o problema de conexão específico. Isso pode incluir coisas como falha de descriptografia, uma autoridade de certificação desconhecida, um parâmetro ilegal e muito mais.

TLS & o modelo OSI

O modelo OSI é uma maneira de conceituar e padronizar como olhamos para nossos diferentes sistemas e protocolos de comunicação. É importante observar que é apenas um modelo, e alguns de nossos protocolos não estão em conformidade com ele.

O OSI possui sete camadas separadas que mostram os níveis em que os protocolos operam, no entanto, O TLS não se encaixa em nenhum. Ele flui sobre outro protocolo de transporte como o TCP, o que implica que está acima da quarta camada, a camada de transporte. É usado de maneira mais proeminente como uma camada de transporte, mas, como realiza apertos de mão, isso implica que faz parte das camadas de apresentação ou aplicativo.

Como você pode ver, o TLS simplesmente não está em conformidade com o modelo OSI. Isso não significa que o TLS esteja quebrado ou errado, se houver, apenas mostra que o modelo OSI é defeituoso e não é capaz de responder por todos os nossos protocolos de comunicação.

Uso de TLS

O TLS é usado para garantir uma proporção significativa de nossas comunicações online. Normalmente é implementado em protocolos como o Protocolo de controle de transmissão (TCP), mas também pode ser usado no DCCP (Datagram Congestion Control Protocol) e no UDP (User Datagram Protocol).

Pode proteger protocolos como HTTP, SMTP, FTP, XMPP e NNTP, assim como outros. O aplicativo mais comum é o protocolo HTTPS (Hypertext Transfer Protocol Secure), que protege a conexão entre um navegador da web e um site. Você pode saber quando o HTTPS está sendo usado para proteger sua conexão online, porque um pequeno ícone de cadeado verde aparecerá à esquerda do URL na parte superior do navegador..

O TLS também pode ser usado para criar VPNs, como no OpenConnect e OpenVPN. Ele usa seus recursos de criptografia e autenticação para formar um túnel que pode conectar hosts e redes entre si. As tecnologias VPN baseadas em TLS, como o OpenVPN, são vantajosas em relação a alternativas como IPsec, porque não se sabe que o OpenVPN tenha problemas graves de segurança. Essas VPNs também podem ser mais fáceis de configurar.

Outro de seus usos é email seguro através do STARTTLS. Quando o TLS é implementado, impede que os invasores possam acessar mensagens enquanto viajam entre servidores de email.

Problemas de segurança TLS

Como a maioria dos protocolos, o TLS teve várias vulnerabilidades passadas e ataques teóricos contra suas várias implementações. Apesar disso, as versões mais recentes são consideradas seguras para fins práticos.

Versões anteriores, como SSL 2.0 e 3.0 (e TLS 1.0, que é essencialmente o mesmo que SSL 3.0) apresentam inúmeras falhas de segurança, mas como são protocolos antigos e obsoletos, não entraremos em detalhes. Você deve usar o TLS 1.2 e 1.3 para proteger suas conexões..

As versões mais recentes do TLS possuem inúmeras atualizações que o tornam menos vulnerável que o SSL. Apesar disso, o protocolo ainda teve os seguintes problemas de segurança:

Ataques de renegociação

Um dos recursos do TLS é que ele permite que pares de clientes e servidores renegociem os parâmetros de sua conexão existente. Em 2009, foi descoberto que isso poderia ser explorado por invasores, para que eles possam injetar tráfego para parecer que vem do cliente. Os servidores aceitarão a solicitação como legítima, o que significa que os invasores podem estar manipulando as mensagens enviadas.

Esse ataque não permite que o invasor veja a resposta, mas ainda tem o potencial de ser prejudicial. Uma extensão que impedirá esses ataques é atualmente um padrão proposto.

FERA

O ataque de exploração do navegador contra SSL / TLS (BEAST) foi descoberto pelos pesquisadores em 2011. Ele aproveita a vulnerabilidade de encadeamento de blocos de criptografia no TLS, que pode ser usada para descriptografar mensagens. Esse ataque afeta apenas o TLS 1.0, que é uma versão antiga e mais fraca do protocolo. Embora não seja preterido até 2023, os usuários devem usar as versões 1.2 e 1.3.

Ataques de tempo

Esses ataques de canal lateral analisam quanto tempo leva para um algoritmo ser executado, depois usam essas informações para retroceder e descobrir a chave. Em 2013, o ataque Lucky Treze foi descoberto para alavancar um ataque de tempo e um ataque de oracle padding enquanto o código de autenticação de mensagens (MAC) está sendo verificado. Esse ataque pode ser usado para interromper o algoritmo TLS, embora não seja considerado perigoso para a maioria dos usuários do TLS.

CRIME & VIOLAÇÃO

O ataque CRIME funciona contra uma variedade de protocolos. Quando os dados são compactados, eles podem obter conteúdo de cookies de autenticação. Esta informação pode ser usada para seqüestro de sessão. Embora afete vários protocolos, o ataque é particularmente preocupante quando a compactação HTTP está sendo usada, porque não há estratégias de mitigação eficazes.

Em 2013, a exploração de Reconhecimento e Exfiltração do Navegador por Compressão Adaptativa de Hipertexto (BREACH) afetou a compactação HTTP de maneira semelhante. Essa versão do ataque pode recuperar endereços de email e outros dados valiosos que foram criptografados com o TLS. O ataque BREACH pode ser mitigado desativando a compactação HTTP ou usando técnicas como a proteção de solicitação de falsificação de site entre sites (CSRF).

Ataques de downgrade

São ataques que induzem os servidores a usar versões anteriores e menos seguras do TLS. Os invasores podem usar essas técnicas para negociar o uso de trocas e cifras de chaves menos seguras. O ataque do Logjam é um bom exemplo, pois pode fazer com que servidores vulneráveis ​​usem o Diffie-Hellman de 512 bits, que é fraco. Os invasores podem então quebrar esse mecanismo de troca de chaves e extrair as chaves, permitindo acesso completo à sessão.

Heartbleed

Heartbleed foi uma falha de segurança que foi acidentalmente introduzida na biblioteca de criptografia OpenSSL em 2012, mas não divulgada até 2014. Como essa é uma implementação comumente usada do TLS, causou danos globais significativos.

Um dos desenvolvedores da extensão de pulsação TLS adicionou uma vulnerabilidade de over-read do buffer, que permite que alguns dados extras sejam expostos. O erro não foi detectado quando o código foi revisado, o que levou a vários ataques significativos.

Como a biblioteca OpenSSL é implementada tão amplamente, o custo internacional de mitigar o problema acabou sendo bastante caro. Os administradores de servidor tiveram que instalar o novo patch e regenerar certificados e pares de chaves que podem ter sido comprometidos durante o período de dois anos em que a vulnerabilidade existia..

AFOGAR

O ataque Descriptografando RSA com Obsoleto e enfraquecido eNcryption (DROWN) foi anunciado em 2016 e aproveita o suporte ao servidor para SSL 2.0. Ele usa um ataque de texto cifrado escolhido contra servidores que ainda suportam SSL 2.0, bem como aqueles que compartilham o mesmo certificado de chave pública com outro servidor que suporta SSL 2.0.

Quando o ataque foi anunciado, ele poderia ser lançado com custos iniciais de instalação de cerca de US $ 18.000 e cerca de US $ 400 para cada ataque separado. Quando o ataque DROWN é bem-sucedido, ele adquire as chaves da sessão.

O ataque pode ser atenuado não compartilhando certificados do servidor. O grupo OpenSSL também lançou patches que removem o suporte a protocolos e cifras mais antigos, mas só funcionam se o certificado do servidor não for compartilhado com outros servidores compatíveis com SSL 2.0..

PAC profano

Este ataque foi encontrado em 2016. Ele aproveita os pontos fracos encontrados no Web Proxy Autodiscovery Protocol (WPAD). Quando um usuário tenta visitar um site por uma conexão criptografada TLS, a falha pode tornar o URL visível. Como às vezes os URLs são enviados aos usuários como uma forma de autenticação, o ataque do Unholy PAC torna possível que um invasor assuma a conta de um usuário.

O TLS é seguro?

Embora pareça haver muitos problemas de segurança, a realidade é que a maioria deles é bem menor e pode ou foi atenuada. À medida que a tecnologia avança, as vulnerabilidades são descobertas e novos ataques são desenvolvidos, o TLS continuará tendo mais problemas de segurança. Apesar disso, por enquanto e no futuro próximo, parece que o TLS ainda será uma das principais e mais confiáveis ​​ferramentas que usamos para proteger nosso mundo online.

Tecnologia de negócios de segurança cibernética por TheDigitalArtist licenciado sob CC0