O trabalho na nova versão do protocolo TLS 1.3 está quase completo. Após quatro anos de discussão em março de 2018, a IETF aprovou a
28ª versão do rascunho como um padrão proposto, portanto deve ser o último antes de adotar as especificações finais.
O TLS 1.3 acelera o processo de estabelecer uma conexão segura pela metade, combinando várias etapas neste momento. Além disso, implementa um regime de perfeito sigilo direto por meio das chaves efêmeras (CE) DH. Este modo garante a proteção das chaves da sessão, mesmo no caso de comprometimento das chaves de longo prazo.
Várias outras melhorias foram implementadas, incluindo suporte à cifra de fluxo ChaCha20, algoritmos de assinatura digital Ed25519 e Ed448, protocolos de troca de chaves x25519 e x448, etc. Suporte removido para funções de hash obsoletas MD5 e SHA-224, curvas elípticas fracas e raramente usadas
Mas o mais interessante é a nova idéia que está sendo
discutida na IETF . Os especialistas do Google sugerem periodicamente a geração aleatória de uma nova versão do protocolo TLS com pequenas alterações. A idéia é que atualizações frequentes serão um antídoto para a ossificação perigosa.
Qual é esse problema?
A chamada "ossificação" é uma situação em que os desenvolvedores do protocolo percebem subitamente que é difícil introduzir melhorias devido à ampla distribuição da versão antiga, que por algum motivo é adequada aos usuários. Na realidade, a versão antiga não atende mais aos requisitos de segurança modernos e às novas especificações, mas não pode ser implementada de fato.
Acredita-
se que os chamados nós intermediários, ou seja, os fornecedores de soluções no campo da "segurança", tenham se tornado o principal "freio" especificamente com a implementação do TLS 1.3. Eles aconselham seus clientes a prescrever
regras específicas de firewall com verificação de certificado ao apertar a mão com o TLS. Na nova versão do padrão, os
certificados SSL são criptografados, para que os intermediários não possam mais examiná-los.
Como a atualização constante resolverá o problema de ossificação do protocolo?
A atualização contínua a cada seis semanas é um padrão familiar no navegador Chrome. Nessa situação, os "executores" são
forçados a cumprir as especificações, pois uma implementação incompatível não funcionará para uma grande proporção de usuários.
Na lista de discussão da IETF, essa idéia foi
sugerida por David Benjamin, do projeto Chromium. Ele escreve que o TLS 1.3 é um protocolo extensível compatível com o TLS 1.2. Pode ser rolado gradualmente, atualizando as implementações atuais do TLS 1.2. E aqui há problemas. Vários servidores incompatíveis não conseguirão estabelecer uma conexão no estágio TLS 1.3 ClientHello, portanto, você precisará reverter para estabelecer uma conexão usando a versão de protocolo suportada.
David Benjamin propõe a idéia de como evitar esse problema no futuro. Discutindo medidas preventivas, ele menciona
invariantes de protocolo listados na cláusula 9.3 das especificações. Todos os terminais e nós intermediários
devem estar em conformidade com os invariantes descritos. Em particular, novos clientes e novos servidores não têm o direito de reduzir o nível de parâmetros para a versão antiga. Da mesma maneira, os nós intermediários não têm o direito de fazer isso ao transferir a conexão entre o cliente e o servidor atualizados e não podem afetar o handshake. No entanto, dada a velocidade desigual de atualização, clientes e servidores atualizados podem oferecer suporte ao estabelecimento de comunicação usando o protocolo antigo, mas apenas da maneira correta descrita na cláusula 9.3.
Mas a prática mostra que não é suficiente descrever o comportamento necessário nas especificações. Como
forçar os nós intermediários a cumprir a regra principal do processamento do ClientHello - a ignorar parâmetros não reconhecidos? Para isso, o método
GREASE é proposto.
GRAXA: antídoto contra ossificação
O GREASE (Gerar Extensões Aleatórias e Sustentar a Extensibilidade) é um método para gerar extensões
aleatórias no TLS e o lançamento constante de novas versões do protocolo. David Benjamin propõe estabelecer um ciclo de lançamento padrão de seis semanas, que coincidirá com o lançamento de novas versões do Chrome.
O lançamento desse "lixo" em grandes números forçará os servidores a cumprir com a regra principal do processamento do ClientHello a ignorar parâmetros não reconhecidos. Também se espalhará para nós intermediários. Para que eles não interfiram na comunicação entre o cliente e o servidor, a regra principal para eles é esta: se você não enviou uma solicitação ClientHello, não tem o direito de processar a resposta. Da mesma forma, o ecossistema deve ser inundado com um grande número dessas respostas.
"Em resumo, planejamos lançar regularmente novas versões do TLS (e provavelmente outros parâmetros sensíveis, como extensões)", diz Benjamin, aparentemente expressando o ponto de vista do Google. - aproximadamente a cada seis semanas, de acordo com o cronograma de lançamento do Chrome. Em seguida, o Chrome, os servidores do Google e todos os outros que desejam participar oferecerão suporte a duas (ou mais) versões do TLS 1.3: o padrão estável 0x0304 e a versão alternativa temporária. A cada seis semanas, selecionamos aleatoriamente um novo ponto de código. Em todos os outros aspectos, essas versões são idênticas à 1.3, com a possível exceção de pequenos detalhes para separar chaves e fazer alterações sintáticas permitidas. O objetivo é pavimentar o caminho para futuras versões do TLS imitando-as (rascunho de uma versão negativa). ”
Esse esquema tem certos riscos, incluindo colisões de pontos de código. Além disso, devem ser desenvolvidas precauções, pois a tarefa é manter e manter a extensibilidade do TLS, e não interferir no desenvolvimento do protocolo. Das medidas de precaução:
- Documentação detalhada de todos os pontos de código (ao trabalhar um ponto em um mês e meio, eles serão suficientes por mais de 7000 anos).
- Prevenção de colisão proativa: rejeitando números que o IETF pode escolher.
- O BoringSSL não ativará esta opção por padrão. Ele será ativado apenas onde puder ser desativado: nos servidores e no navegador. Na realidade, provavelmente, a cada momento, apenas os últimos pontos de código serão usados. Por estarem mudando rapidamente, o ecossistema não deve estar ligado a nenhuma expansão temporária e as implementações permanecerão compatíveis entre si.
- Se, por algum motivo, o método não funcionar, o experimento poderá ser interrompido a qualquer momento.
A idéia é interessante e, se o Google começar a agir dessa maneira, ele poderá realmente salvar o ecossistema da perigosa "ossificação" devido a fornecedores de soluções no campo da "segurança" e outros sistemas corporativos específicos. Um representante da Cloudflare
apoiou esta proposta. De qualquer forma, ele disse, pelo menos algo precisa ser feito para evitar o problema que encontramos ao tentar implementar o TLS 1.3. Outro membro do grupo de trabalho da IETF
chamou de "idéia fantástica" e sugeriu que o Google crie uma página wiki que descreva os pontos de código que usa ou planeja usar no futuro.
