en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

TLS 1.3 Está aqui para ficar

O mundo está se movendo para TLS 1.3, o que é muito bom! Este artigo oferece uma visão geral de alto nível TLS 1.3, e uma discussão sobre a eficácia de seus novos recursos.

Transport Layer Security

Segurança da Camada de Transporte, ou TLS, é um protocolo criptográfico que protege os dados trocados em uma rede de computadores. TLS tornou-se famoso como o S in HTTPS. Mais especificamente, TLS é usado para proteger os dados do usuário da web contra ataques à rede.

TLS foi projetado como uma alternativa mais segura para seu antecessor Secure Sockets Layer (SSL). Ao longo dos anos, pesquisadores de segurança descobriram montes de vulnerabilidades que afetam SSL, o que motivou a IETF a projetar TLS em um esforço para mitigá-los.

Ironicamente, as versões anteriores do TLS também foram afetados por vulnerabilidades perigosas, o que acabou levando a TLS 1.2 (ou seja, a versão padrão recomendada por profissionais da indústria).

A maioria das vulnerabilidades de protocolo conhecidas foram mitigadas em TLS 1.2, mas esse nível de segurança ainda era o resultado de uma série de patches sobre um design defeituoso.

Como resposta, TLS 1.3 foi elaborado do zero em um esforço para projetar de forma limpa um moderno e seguro TLS protocolo. Cinco anos de testes depois, finalmente foi aprovado e agora está perto de ser o padrão de segurança padrão da Internet.

TLS versões e seus respectivos documentos RFC podem ser encontrados na lista abaixo:

  • TLS 1.0 foi publicado como RFC 2246 em 1996
  • TLS 1.1 foi publicado como RFC 4346 em 2006
  • TLS 1.2 foi publicado como RFC 5246 em 2008
  • TLS 1.3 foi publicado como padrão proposto em RFC 8446 em 2018.

Como envelhecer TLS versões funcionam?

Para discutir efetivamente os benefícios de TLS 1.3, devemos primeiro falar sobre quantos anos TLS versões funcionam (e como não funcionam).

TLS é um híbrido sistema de criptografia, o que significa que ele usa ambos assimétrico (chave pública) e simétrico (com base em senha / frase). Isso é devido ao criptografia assimétrica sendo ordens de magnitude mais lentas do que seus equivalentes simétricos.

Consequentemente, TLS só emprega chaves públicas para que clientes e servidores possam trocar com segurança uma chave simétrica. Essa chave pode então ser usada para criptografar todas as comunicações subsequentes, evitando a sobrecarga de desempenho imposta pela criptografia assimétrica.

TLS 1.2 suporta vários algoritmos de troca de chave (por exemplo, RSA, DH, etc.), juntamente com vários algoritmos (também conhecido como cifras) usado para criptografar e descriptografar mensagens. Esta grande quantidade de opções alternativas requer que clientes e servidores negociem, de modo que todas as partes utilizem o mesmo TLS parâmetros.

Essa negociação é padronizada em um protocolo chamado aperto de mão. Se você não estiver familiarizado, consulte Este artigo Para obter mais informações.

Então, o que há de errado com TLS 1.2?

Apesar TLS 1.2 provou funcionar bem na maioria dos casos, existem preocupações sobre o nível geral de segurança e privacidade que ele fornece após anos de patching e revisões.

Além de considerações de segurança, porém, TLS 1.2 também impõe desempenho desnecessário e sobrecarga de rede.

TLS Problemas de segurança 1.2

Ao longo dos anos, pesquisadores (e invasores) descobriram uma série de vulnerabilidades em muitos TLS 1.2 componentes, incluindo algoritmos de troca de chaves, cifras e assinaturas digitais. Alguns deles eram bugs de implementação dos quais você deve ter ouvido falar, como heartbleed or BERserk. No entanto, alguns eram vulnerabilidades de protocolo - isto é, eles exploram decisões de design ruins anteriores TLS versões (ou seja, antes TLS

Embora a maioria da implementação e outros bugs tenham sido corrigidos em TLS 1.2, infelizmente, as vulnerabilidades no projeto do protocolo não podem ser corrigidas usando apenas um patch de software. Acontece que, para fazer isso, a IETF teve que redesenhar completamente o protocolo de handshake em TLS 1.3.

Tem havido muitas preocupações sobre TLS segurança, mas uma das mais impactantes foi a percepção de que TLS 1.2 (e todas as versões anteriores, incluindo SSL) é vulnerável a ataques de downgrade devido a uma falha no design do protocolo de handshake. Mais especificamente, TLS 1.2 não usa assinaturas digitais para proteger a integridade do handshake. As assinaturas protegem parte do handshake, somente após a negociação do pacote de criptografia.

Como conseqüência, os invasores podem manipular qualquer negociação de suíte de cifras de terceiros que ocorra na mesma rede de computadores (por exemplo, wifi do aeroporto) e forçar o uso de uma cifra insegura. Eles podem então quebrar essa cifra vulnerável e obter acesso injustificado a toda a conversa.

TLS 1.2 problemas de desempenho

Além dessas considerações de segurança, TLS 1.2 precisa negociar vários TLS parâmetros podem impor uma sobrecarga de desempenho em HTTPS (ou outro TLS protegidos) comunicações.

TLS O handshake de 1.2 etapas do 4 requer duas trocas de ida e volta, primeiro para selecionar o conjunto de criptografia e, em seguida, para trocar os certificados e chaves simétricas (ou compartilhamentos de chaves).

Isso significa que para cada TLS conexão a ser estabelecida, duas transações adicionais com o servidor são necessários. Como um resultado, TLS as conexões requerem mais largura de banda e energia do que HTTP (não criptografado), o que pode ser particularmente caro para aplicativos de Internet das Coisas (IoT), em que baixo consumo de energia e largura de banda são restrições rígidas.

TLS 1.2 questões de privacidade

Por último, TLS 1.2 foi criticado por comprometer a privacidade do usuário da web.

Mais especificamente, TLS oferece uma extensão conhecida como Indicação do nome do servidor ou SNI. O SNI permite que o nome do host de um servidor seja incluído no handshake SSL inicial. Esta extensão é usada para hospedagem virtual, onde os servidores podem servir vários domínios no mesmo endereço IP e porta, enquanto apresentam um certificado diferente para cada domínio.

In TLS 1.2, SNIs são enviados sem criptografia, portanto, apesar do uso de HTTPS, um invasor de rede pode vazar essas informações e rastrear as páginas da web visitadas por um usuário.

como funciona TLS 1.3 consertar tudo isso?

TLS 1.2 (e versões anteriores) focavam em manter a compatibilidade com versões anteriores. Cada versão construída sobre as anteriores com pequenas revisões tentando eliminar as vulnerabilidades publicadas entre TLS versões.

Lamentavelmente, isso também significou que más decisões de projeto de protocolo (por exemplo, handshake desprotegido) também foram herdadas nas versões mais recentes.

TLS 1.3 abandona a compatibilidade com versões anteriores em favor de um projeto de segurança adequado. Ele foi projetado do zero para fornecer funcionalidade semelhante (mas não compatível) para TLS 1.2, mas com desempenho, privacidade e segurança significativamente aprimorados.

TLS Segurança 1.3

Um princípio fundamental de TLS 1.3 é simplicidade. Na nova versão, todos os algoritmos de troca de chaves, exceto o Diffie-Hellman (DH) troca de chaves, foram removidos. TLS 1.3 também definiu um conjunto de parâmetros DH testados e comprovados, eliminando a necessidade de negociar parâmetros com o servidor.

O que mais, TLS 1.3 não suporta mais cifras desnecessárias ou vulneráveis, como o modo CBC e a cifra RC4. Essas cifras são conhecidas por serem suscetíveis a ataques, mas ainda eram suportadas na maioria TLS implementações para compatibilidade de legado. Felizmente, a recente onda de ataques de downgrade afetando TLS versões motivaram a IETF a remover inteiramente tais cifras de TLS 1.3.

Além disso, TLS 1.3 requer que os servidores assinem criptograficamente todo o handshake, incluindo a negociação de criptografia, o que impede que invasores modifiquem quaisquer parâmetros de handshake. Isso significa que TLS 1.3 é arquitetonicamente impermeável aos ataques de downgrade que afetaram anteriormente TLS versões.

Por fim, as próprias assinaturas também foram aprimoradas com a implementação de um novo padrão, chamado RSA-PSS. As assinaturas RSA-PSS são imunes a ataques criptográficos que afetam os esquemas de assinatura empregados anteriormente TLS versões.

TLS SEM desempenho

Além da segurança aprimorada, o conjunto reduzido de parâmetros e o handshake simplificado em TLS 1.3 também contribui para melhorar o desempenho geral. Uma vez que há apenas um algoritmo de troca de chave (com parâmetros embutidos) e apenas um punhado de cifras suportadas, a largura de banda absoluta necessária para configurar um TLS 1.3 canal é consideravelmente menor do que as versões anteriores.

Além disso, TLS 1.3 agora suporta um novo protocolo de handshake, chamado Modo 1-RTT. No 1-RTT, o cliente pode enviar compartilhamentos de chaves DH na primeira mensagem de handshake, pois pode ter certeza dos parâmetros que o servidor usará. Nos raros casos em que o servidor não os suporta, pode gerar um erro para que o cliente envie uma configuração diferente.

Em vez de negociar os parâmetros primeiro e, em seguida, trocar chaves ou compartilhamentos de chaves, TLS 1.3 permite que um cliente configure um TLS canal com apenas uma transação de ida e volta (em vez de duas, como era feito anteriormente). Isso pode ter um grande efeito cumulativo nos recursos de processamento, energia e rede que são necessários para um cliente se comunicar com um servidor por meio TLS 1.3.

As otimizações de desempenho não param por aqui, com outro TLS Recurso 1.3, chamado de Modo de Reinício 0-RTT. Quando um navegador visita um servidor pela primeira vez e conclui com sucesso um TLS handshake, o cliente e o servidor podem armazenar uma chave de criptografia pré-compartilhada localmente.

Se o navegador visitar o servidor novamente, poderá usar essa chave de retomada para enviar dados criptografados do aplicativo em sua primeira mensagem ao servidor. Isso tem a mesma latência que o HTTP não criptografado, porque os handshakes iniciais não são necessários.

Note-se que houve alguma segurança preocupações sobre o modo 0-RTT no passado.

TLS Privacidade 1.3

Aprendendo com os erros do passado, TLS 1.3 agora oferece um extensão que criptografa as informações SNI. Quando usada corretamente, esta extensão evita que invasores vazem o nome de domínio do servidor remoto, portanto, eles não têm nenhum método para rastrear o histórico do usuário HTTPS. Este recurso oferece maior privacidade aos usuários da Internet do que as versões anteriores do TLS.

Conclusão

Enquanto TLS 1.2 serviu com honra todos esses anos, TLS 1.3 é comprovadamente mais seguro e eficiente. TLS 1.3 foi amplamente testado em implementações experimentais de navegadores e agora está pronto para substituir TLS 1.2 como protocolo de segurança de rede de escolha. Publicação TLS 1.3 é um grande passo em direção a uma Internet mais rápida e segura para todos.

Obrigado por escolher SSL.com, onde acreditamos que um mais segura Internet é uma better Internet.

Artigos Relacionados

Inscreva-se no boletim informativo de SSL.com

O que é SSL /TLS?

Reproduzir Vídeo

Inscreva-se no boletim informativo de SSL.com

Não perca novos artigos e atualizações de SSL.com