TLS: como funciona a en­crip­ta­ção na Internet

O TLS (Transport Layer Security) é um protocolo de en­crip­ta­ção que garante a trans­mis­são segura de dados na Internet. É o sucessor do já obsoleto SSL e, atu­al­mente, é utilizado quase ex­clu­si­va­mente na sua versão TLS 1.3.

O que é o TLS?

Nos primeiros anos da Internet, a segurança dos dados não era uma pri­o­ri­dade como é hoje. Todas as co­mu­ni­ca­ções eram trans­mi­ti­das de forma aberta e sem en­crip­ta­ção entre com­pu­ta­do­res, algo se­me­lhante a enviar um postal: qualquer pessoa que o trans­por­tasse podia ler o seu conteúdo.

Com a chegada do protocolo TLS, também conhecido como SSL/TLS, foi in­tro­du­zida a en­crip­ta­ção dos dados trans­mi­ti­dos. Con­ti­nu­ando com o mesmo exemplo, esta en­crip­ta­ção seria como colocar o postal num envelope selado que só o des­ti­na­tá­rio legítimo pode abrir.

TLS é a sigla de Transport Layer Security, que se traduz para o português como «segurança da camada de trans­porte». Esta de­sig­na­ção refere-se à camada de trans­porte do modelo TCP/IP. O TLS é um processo que encripta os fluxos de dados da Internet para que apenas os seus des­ti­na­tá­rios legítimos possam lê-los.

Como funciona o TLS?

O TLS encripta, através de en­crip­ta­ção simétrica, todo o tráfego de dados que passa pelo TCP.

Embora pareça fácil na teoria, na prática a situação é mais com­pli­cada. O principal problema é que o servidor tem de comunicar a chave ao cliente e, além disso, tem de o fazer antes de a co­mu­ni­ca­ção ser protegida por TLS. Se costuma enviar ficheiros en­crip­ta­dos por e-mail, já deve conhecer este problema: encripta um ficheiro e depois tem de partilhar a palavra-passe com o des­ti­na­tá­rio, por exemplo, por telefone.

O protocolo TLS, cuja versão atual é a 1.3 desde 2018, utiliza o seguinte pro­ce­di­mento para garantir uma ligação segura:

1. Cli­entHello: o cliente (por exemplo, um navegador) inicia a ligação enviando uma mensagem chamada Cli­entHello, que contém in­for­ma­ções sobre os métodos de en­crip­ta­ção que suporta. Estes dados incluem conjuntos de en­crip­ta­ção, versões do protocolo, um valor aleatório e o seu próprio valor de troca de chaves Diffie-Hellman (valor ECDHE). Op­ci­o­nal­mente, pode já incluir um primeiro bloco de dados en­crip­ta­dos.
2. Ser­verHello: o servidor responde com uma mensagem chamada Ser­verHello, na qual seleciona os pa­râ­me­tros adequados e responde com as suas próprias in­for­ma­ções, que incluem o seu valor ECDHE e o seu cer­ti­fi­cado digital. Este cer­ti­fi­cado SSL confirma que o servidor é autêntico e não está a usurpar uma iden­ti­dade. Ao mesmo tempo, inicia-se o cálculo da chave de sessão.
3. Cálculo de chaves: ambas as partes calculam de forma in­de­pen­dente a mesma chave de sessão (session key) a partir da chave pre­vi­a­mente acordada.
4. O servidor conclui a troca inicial e inicia a co­mu­ni­ca­ção en­crip­tada. O cliente faz o mesmo e, a partir desse momento, a ligação fica to­tal­mente segura.

A razão pela qual a crip­to­gra­fia as­si­mé­trica com Diffie-Hellman é utilizada apenas para a trans­mis­são da chave de sessão (mas não para a en­crip­ta­ção do próprio fluxo de dados) deve-se à des­van­ta­gem que re­pre­senta em termos de ve­lo­ci­dade: a crip­to­gra­fia as­si­mé­trica é re­la­ti­va­mente lenta e atrasaria a co­mu­ni­ca­ção de dados.

Prós e contras do TLS

O TLS é uma solução simples para tornar o tráfego de dados na Web mais seguro, uma vez que não exige que as partes encriptem elas próprias o conteúdo, como, por exemplo, os dados de um for­mu­lá­rio. Em vez disso, basta que o tráfego seja realizado através do protocolo TLS, in­de­pen­den­te­mente do sistema operativo e das apli­ca­ções in­for­má­ti­cas uti­li­za­das pelas partes en­vol­vi­das. Durante a trans­mis­são, todos os fluxos de dados são en­crip­ta­dos au­to­ma­ti­ca­mente.

O preço a pagar por esta segurança é uma ligação li­gei­ra­mente mais lenta, uma vez que as etapas do processo que acabámos de descrever —cer­ti­fi­cado, número aleatório e troca de chaves— são muito exigentes em termos com­pu­ta­ci­o­nais.

Áreas de aplicação do TLS

Tal como já ex­pli­cá­mos, o TLS pode ser utilizado de forma universal, in­de­pen­den­te­mente da aplicação ou do sistema operativo. Con­se­quen­te­mente, existem muitos pro­to­co­los de aplicação que dispõem de uma versão segura do TLS. O esquema de no­men­cla­tura é, em muitos casos, muito simples: quando um protocolo utiliza o TLS, basta adicionar um «S» ao final do seu nome.

O principal âmbito de aplicação do TLS é a World Wide Web ou, mais con­cre­ta­mente, o protocolo HTTP. A sua variante en­crip­tada é designada por HTTPS.

Outras apli­ca­ções comuns são:

• POP3S: os e-mails do servidor são recebidos através do protocolo POP3.
• IMAPS: a caixa de entrada é sin­cro­ni­zada com o servidor uti­li­zando o protocolo IMAP.
• SMTPS: envio de e-mails.
• FTPS: trans­fe­rên­cia de ficheiros através do protocolo FTP.
• SIPS: telefonia de voz sobre IP uti­li­zando o protocolo SIP.
• IRCS: conversas en­crip­ta­das.
• QUIC: protocolo de trans­porte de­sen­vol­vido pela Google que integra di­re­ta­mente o TLS 1.3; apresenta-se como uma al­ter­na­tiva ao TCP para obter ligações web mais rápidas e seguras (por exemplo, em HTTP/3)

O OpenVPN, um software livre para criar uma rede privada virtual (VPN), também utiliza o protocolo TLS.

Apli­ca­ções do TLS

Algumas apli­ca­ções im­por­tan­tes do TLS são:

• OpenSSL: de longe, a sua aplicação mais comum, uma vez que a maioria dos sites utiliza HTTPS.
• GnuTLS: de­sen­vol­vido pela Free Software Foun­da­tion*.*
• LibreSSL: de­sen­vol­vida pela OpenBSD.
• NSS: de­sen­vol­vida pela Network Security Services*.*
• BoringSSL: de­sen­vol­vida pela Google.
• Rustls: de­sen­vol­vida por Joe Birr-Pixton, Dirkjan Ochtman, Daniel McCarney, Josh Aas e a co­mu­ni­dade de código aberto.
• Botan: licença BSD, de­sen­vol­vida por Jack Lloyd.
• JSSE: de­sen­vol­vida pela Java Secure Socket Extension e pela Oracle.
• S2n: de­sen­vol­vida pela Amazon.

Esta lista não é exaustiva. En­con­trará mais in­for­ma­ções sobre as uti­li­za­ções do TLS no artigo da Wikipédia «Com­pa­ra­ção de im­ple­men­ta­ções TLS».

Ataques co­nhe­ci­dos ao TLS

O TLS não está to­tal­mente imune a ataques e fugas de in­for­ma­ção. Alguns pontos de ataque co­nhe­ci­dos são:

• Erros de pro­gra­ma­ção: como a famosa falha de segurança He­art­bleed, um grave erro de pro­gra­ma­ção nas primeiras versões do OpenSSL, que foi corrigido em 2014.
• Crip­to­gra­fia fraca: em con­sequên­cia das res­tri­ções norte-ame­ri­ca­nas à ex­por­ta­ção de crip­to­gra­fia, foram de­sen­vol­vi­das versões ex­por­tá­veis mais fáceis de decifrar do que as originais.
• Ataques de com­pres­são: utilizar a com­pres­são HTTP em vez da com­pres­são TLS torna mais fácil para os piratas in­for­má­ti­cos adi­vi­nha­rem o conteúdo en­crip­tado com TLS através de di­fe­ren­tes processos.
• O ataque BEAST afetou a versão 1.0 do TLS e já foi descrito em 2014. As versões atuais do TLS são mais seguras contra esse tipo de ataques.
• O**ataque Padding Oracle* foi des­co­berto em 2002 e só foi corrigido na versão 3.0 do SSL. A versão atual 1.3 do TLS não é afetada.
• O ataque ALPACA, des­co­berto em 2021, demonstra como é possível explorar cer­ti­fi­ca­dos TLS em ser­vi­do­res mal con­fi­gu­ra­dos para re­di­re­ci­o­nar os uti­li­za­do­res para outros serviços e, assim, in­ter­cep­tar ou manipular dados.

Além disso, procurou-se evitar a im­ple­men­ta­ção de uma en­crip­ta­ção TLS to­tal­mente segura, para que as au­to­ri­da­des pudessem ins­pe­ci­o­nar as co­mu­ni­ca­ções en­crip­ta­das, por exemplo, caso es­ti­ves­sem re­la­ci­o­na­das com tran­sa­ções fi­nan­cei­ras ou ati­vi­da­des cri­mi­no­sas. Uma das or­ga­ni­za­ções que mais se empenhou para que o TLS apre­sen­tasse um ponto fraco deste tipo foi o ETSI (Instituto Europeu de Normas de Te­le­co­mu­ni­ca­ções).