A Internet vai ficar mais segura! IETF aprovou o TLS 1.3
A Internet tem como base protocolos e serviços indispensáveis ao seu bom funcionamento, mas que também garantem a segurança desta rede de escala mundial.
Como em qualquer situação, estes protocolos necessitam de ser atualizados, quer para garantir novas funcionalidades quer para eliminar falhas. O IETF acaba de dar mais um passo importante ao aprovar o TLS 1.3.
A IETF (Internet Engineering Task Force) - organização que aprova os protocolos e padrões da Internet propostos - aprovou formalmente o TLS 1.3 como a próxima versão principal do protocolo TLS (Transport Layer Security).
A decisão vem após quatro anos de discussões e 28 rascunhos de protocolo, com o 28º a ser selecionado como a versão final.
Espera-se agora que o TLS 1.3 se torne o método padrão no qual um cliente e um servidor estabelecem um canal de comunicação criptografado através da Internet - ligações HTTPS.
O TLS 1.3 traz melhor criptografia e menos latência nas comunicações
O protocolo tem várias vantagens em relação à sua versão anterior, o TLS 1.2.
- O TLS 1.3 abandona os algoritmos mais antigos de criptografia e hash (como MD5 e SHA-224) para alternativas mais recentes e mais difíceis de decifrar (como ChaCha20, Poly1305, Ed25519, x25519 e x448).
- O TLS 1.3 também é muito mais rápido na negociação do inicial entre o cliente e o servidor, reduzindo a latência da ligação que muitos citaram.
- O TLS 1.3 também suportará recursos como o TLS False Start e o Zero Round Trip Time (0-RTT) também ajudam a reduzir o tempo necessário para estabelecer handshakes de criptografia com os hosts sobre os quais o cliente já falou anteriormente.
- O TLS 1.3 também é superior às versões anteriores do TLS porque vem com proteção contra ataques de downgrade que impedem que um invasor engane o servidor usando uma versão mais antiga do protocolo, suscetível a vulnerabilidades conhecidas.
IETF evita esforços para inserir "backdoor"
Em resumo, o TLS 1.3 é um grande impulso para a segurança da Internet, sendo considerado como quase impossível de decifrar, pelo menos com os recursos atuais.
Os membros do IETF votaram o protocolo por unanimidade, mesmo após membros do setor financeiro solicitarem a introdução de uma "backdoor" na estrutura do protocolo, para que as instituições financeiras pudessem decifrar o tráfego TLS 1.3, dentro das redes internas.
A proposta foi ridicularizada por especialistas, que apontaram que a "backdoor" efetivamente tornaria o TLS 1.3 inútil antes de ser adotado.
Este artigo tem mais de um ano
Estes Engenheiros de Redes aliados ao mágicos da Criptografia, acabam de lançar 155 páginas que dá imenso gosto ler. Apesar de ter lido aos ziguezagues (irei ler no final de semana com calma), é um documento no mínimo brilhante.
Bem…no fundo estamos perante algo assim:
TLS 1.3, é SEGURO porque é MAIS RÁPIDO e ao mesmo tempo é mais rápido, devido às MELHORIAS EM SEGURANÇA.
No fundo é o que todos desejamos, penso eu: mais velocidade por intermédio desta nova versão do TLS e ao mesmo tempo, mais segurança nas ligações via Internet.
Estes trabalhos não têm sempre NSA, Russos por trás. Ou seja, os criadores desenham sempre formas alternativas para criar backdoors?
Espero que fique um pouco mais esclarecido (https://www.ietf.org/about/); (https://www.ietf.org/about/mission/) e (https://www.ietf.org/about/who/)
https://tools.ietf.org/html/draft-ietf-tls-tls13-28 <= que se tornou o standard:
Basta ler um pouquinho para ver que os backdoors lá continuam! Leiam a parte do "0-RTT" por exemplo… se aquilo não parece um desastre à espera de acontecer não sei o que será. E no próprio documento fazem múltiplos alertas para os potenciais problemas de segurança… no fundo eles sabem que aquilo é um "backdoor" à espera de ser utilizado mas que se viram forçados a colocar para satisfazer as necessidades de alguém… pelo menos no Firefox dá para desactivar mas no Google Chrome não parece dar.
Também têm lá as cifras com PSK que podem ser mal implementadas… e basta dar umas vista de olhos pelas VPNs para ver que alguns esquemas de VPNs que usam cifras com PSK são mal usadas ao dar a mesma chave para toda a gente!
Para a troca de chaves o secp256r1 (criado pela NSA) tem de estar OBRIGATORIAMENTE implementado que os especializados no assunto não consideram seguro ( https://safecurves.cr.yp.to/ ), o secp384r1 também está presente e que também não é considerado seguro… e o X25519 que já é considerado como seguro é apenas opcional… a quem é que será que isto interessa?…
Já para não falar que não existe no standard algoritmos em todas as categorias que ofereçam protecção contra a computação quântica apesar de já existirem claros sinais de avanços nessa área mesmo no sector comercial e sabe-se lá o que os militares e agências de espionagem já podem ter.
Claro que era ridícula as propostas da banca e outras instituições porque eles podem terminar a ligação segura no limite interno/ externo e analisar tudo em claro a partir da fronteira para dentro… e se fizerem muita questão podem continuar a utilizar o TLS 1.2 que provavelmente só daqui a mais de 20 anos é que provavelmente desaparecerá dos clientes tendo em conta a velocidade com que as coisas se movem na indústria.
oh colega. A CE secp256r1 não foi criado pela NSA mas sim pela NIST. A NSA descobriu a relação entre dois pontos da curva que fazia prever com exatidão os números a serem gerados. Já ninguém usa esse polinómio por essa mesma razão. Podes sempre usar DH sem EC (com uma fonte de ruido das medições de algo quântico – ex: principio da incerteza).
“Também têm lá as cifras com PSK que podem ser mal implementadas…”
?? sabes do que falas? Tens noção do que é “PSK”?
“e basta dar umas vista de olhos pelas VPNs para ver que alguns esquemas de VPNs que usam cifras com PSK são mal usadas ao dar a mesma chave para toda a gente!”
Que VPNs? A tecnologia? Providers? O que entendes por ” esquemas de VPNs”? Quem dá PSK a toda a gente?!
“Já para não falar que não existe no standard algoritmos em todas as categorias que ofereçam protecção contra a computação quântica apesar de já existirem claros sinais de avanços nessa área mesmo no sector comercial e sabe-se lá o que os militares e agências de espionagem já podem ter.”
Acho que é desta que tens que usar papel de alumínio por cima da cabeça. Mas infelizmente nem percebes como é que se quebra matematicamente algo em criptografia.
O secp256r1 foi criado pela NSA sim, e tornado um padrão pelo NIST após pressão da NSA nesse sentido.
O secp256r1 pode ser utilizado (e é na maior parte das vezes, quando não é usado o RSA, ou o também criado pela NSA e vulnerável secp384r1) nos certificados digitais e na fase de negociação da ligação segura quando utilizam ECDHE para estabelecer a ligação.
O algoritmo em si tem várias vulnerabilidades tal como indicado no link que indiquei.
Cifras com PSK utilizam uma chave, supostamente secreta, para estabelecer ligações seguras. O problema não está no PSK em si, pois por exemplo os routers wireless utilizam tal (chaves secretas), mas sim no facto de tais chaves poderem ser simples de quebrar ou estarem até disponíveis publicamente. Que VPNs? As L2TP/IPSec PSK das quais existem várias, é só procurar utilizando “ipsec free” num motor de busca… para ver um exemplo de utilização errada da tecnologia… abrindo assim a porta a espionagem (para além é claro dos próprios prestadores do serviço claro).
Utilizar papel de alumínio só chamaria a atenção de toda a gente com mais facilidade! Quanto muito um boné com um emissor de infra-vermelhos para bloquear algumas câmaras de vigilância é que poderia ser útil.
O que eu percebo é que ter algoritmos vulneráveis como o secp256r1 e o secp384r1 criados pela NSA e tornados padrão pelo NIST é uma péssima ideia a nível de segurança/ privacidade, em especial quando a sua implementação (secp256r1) é obrigatória.
Curiosamente o secp521r1 que também foi criado pela NSA tem sido mantido afastado das normas padrão, embora finalmente apareça agora no TLS 1.3, mas não como obrigatório… esse (secp521r1), ao contrário dos outros dois, parece ter sido feito de outra forma e quem li que o analisou não demonstrou preocupação com ele, parecendo esse estar bem feito.
Acho que a “paranóia” como quer dar a entender faz sentido em especial depois do DES e do Dual_EC_DRBG… e de existirem evidências de que o secp256r1 e o secp384r1 não são algoritmos sólidos existindo outros (que até estão no próprio do TLS 1.3 como o ed25519, ed448, x25519 e x448 que os podem substituir perfeitamente e deveriam).
As curvas não são algoritmos. São funções polinomiais….
Volto a frisar que a curva 256r1 foi criado pela NIST e a NSA não tocou no assunto à NIST. Só tocou no assunto foi nos equipamentos e serviços em que forçou a usarem o algoritmo Dual_EC_DRBG usando essa mesma curva porque tinham matematicamente quebrado a relação secreta entre p e q e o algoritmo tinha um erro de implementação.
O que é que as “VPNs” públicas tem a ver com isto? A pŕopria definição de público cai por terra a utilização disto de forma segura. Não faz sentido sequer discutir isto.
Em relação ao IPSec acho que falhas em perceber o protocolo porque o mesmo tem 2 fases. Mesmo que tu saibas a PSK tens que ter o conhecimento da configuração do outro lado. Os access points com PSK só sabendo a PSK é que consegues decifrar o tráfego. Por isso uma PSK que supostamente deveria de ser secreta para quem tem acesso, estar publicamente exposta é o mesmo que tu publicamente dizeres as tuas credenciais e esperar que continues seguro. É ilógico sequer falar no assunto.
O Dual_EC_DRBG isto sim é um algoritmo !! Boa! O algoritmo sim é o mais fácil de inserir uma backdoor. Já ninguém usa isto.
Recomendo-te pesquisares e aprenderes perfundamente. Tens vários meios de partilhares chaves secretas por DH sem recorreres a curvas. Tens vários outros algoritmos de PRNG ou mesmo TRNG que é o caso de ruído quântico. https://www.idquantique.com/random-number-generation/products/quantis-random-number-generator/
Já agora, quebrar ligações cifradas recorrendo ao processamento quântico não é tão garantido como pareces estar a dizer. O resultado não te é um valor fixo mas sim um conjunto de probabilidades em que pode ou não ser correto. Anyway, já se está a desenvolver meios de estabelecer links seguros com criptografia quântica. 🙂
Sempre na vanguarda do conhecimento. Um obrigado pelos esclarecimentos e pelo resumo da questão