Capítulo 2 — Redes e serviços de internet
Mapa da aula
Aula 02 publicada. Mapa, exemplo, EX003.
flowchart TD
N0["2.1 Os serviços e os seus canais seguros"]
N1["2.2 Troca de chaves híbrida por protocolo"]
N2["2.3 Efeitos de tamanho"]
N3["2.4 Caso resolvido"]
N4["2.5 Atividade prática"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX003"]
Desenho lógico
flowchart LR
N0["2.1 Os serviços e os seus canais seguros"]
N1["2.2 Troca de chaves híbrida por protocolo"]
N2["2.3 Efeitos de tamanho"]
N3["2.4 Caso resolvido"]
N4["2.5 Atividade prática"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX003"]
[2.1 Os serviços e os seus canais seguros]
|
v
[2.2 Troca de chaves híbrida por protocolo]
|
v
[2.3 Efeitos de tamanho]
|
v
[2.4 Caso resolvido]
|
v
[2.5 Atividade prática]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX003]
Objetivos de aprendizagem
Você vai (1) explicar DNS, HTTP, TLS, SSH e IPsec no nível de implementação; (2) identificar o estabelecimento de chaves e a autenticação em cada um; (3) reconhecer como as mensagens pós-quânticas mudam de tamanho; e (4) nomear as normas que definem a troca de chaves híbrida no TLS, no SSH e no IKEv2.
2.1 Os serviços e os seus canais seguros
Os clientes da KLS chegam à API por DNS e HTTPS; os parceiros trocam arquivos por SFTP (SSH); os escritórios se conectam por VPNs IPsec. Cada canal seguro faz dois trabalhos: o estabelecimento de chaves (combinar as chaves de sessão) e a autenticação (provar a identidade com certificados, chaves de host ou chaves pré-compartilhadas). O risco quântico para o primeiro é colher agora, decifrar depois; para o segundo, a falsificação futura.
A distinção decide a ordem do trabalho da KLS. Sessões SFTP gravadas que transportam documentos aduaneiros de dez anos podem ser decifradas depois se a troca de chaves for clássica, então o estabelecimento de chaves vem primeiro. Uma chave de host ou um certificado falsificados só ajudam um atacante quando existir um computador quântico e enquanto essa chave ainda for confiável, então a autenticação pode vir depois, quando as bibliotecas e os repositórios de confiança estiverem prontos.
2.2 Troca de chaves híbrida por protocolo
No TLS 1.3 (RFC 8446), o grupo híbrido X25519MLKEM768 (RFC 10024) combina o ML-KEM-768 com o X25519; o key share do cliente cresce de 32 para 1.216 bytes e o do servidor para 1.120 bytes. No SSH, o OpenSSH acrescentou uma troca de chaves híbrida ML-KEM/X25519, mlkem768x25519-sha256, e depois a tornou o padrão (notas de versão do OpenSSH), depois de ter oferecido antes um híbrido baseado no sntrup761. No IKEv2, a RFC 9370 permite até sete trocas de chaves adicionais, usadas para acrescentar o ML-KEM ao lado do Diffie–Hellman clássico; a RFC 8784 mistura chaves pré-compartilhadas pós-quânticas como medida provisória. A terminologia dessas combinações está na RFC 9794.
2.3 Efeitos de tamanho
Um ClientHello que transporta um key share ML-KEM geralmente ultrapassa um pacote de 1.500 bytes. A maioria das pilhas lida com isso; alguns middleboxes e balanceadores de carga antigos, não. As assinaturas pós-quânticas são ainda maiores (ML-DSA-44: 2.420 bytes por assinatura na FIPS 204), o que importa quando os certificados mudarem. O DNSSEC, que roda sobre UDP com limites de tamanho apertados, é especialmente sensível ao tamanho das assinaturas.
Na KLS, o efeito de tamanho é medido, não suposto: o key share híbrido do cliente acrescenta 1.184 bytes, o que empurra um ClientHello típico para além de um segmento. O Laboratório H, no Capítulo 20, mostra a assinatura da falha: ClientHellos de 1.530 bytes expirando num caminho de proxy. Os certificados ainda não foram alterados, então a assinatura de 2.420 bytes do ML-DSA-44 é uma preocupação posterior; a zona DNS continua clássica até que os tamanhos de assinatura e o comportamento dos resolvedores sejam entendidos.
2.4 Caso resolvido
A KLS habilita o X25519MLKEM768 num gateway de API de homologação. Os navegadores modernos e o SDK do cliente baseado em Go o negociam de imediato; o cliente Java legado de um cliente oferece apenas grupos clássicos e recua para o X25519, como previsto. Uma sonda de monitoramento de terceiros expira — o seu appliance descarta o ClientHello de dois segmentos. A correção é atualizar a sonda, não desabilitar o grupo.
A execução em homologação também deu à KLS a sua primeira regra de implantação. O recuo do cliente Java é aceitável e é acompanhado como uma fração das sessões; um timeout não é aceitável e precisa ser rastreado até um dispositivo. O fornecedor do monitoramento recebeu um chamado com o tamanho do ClientHello capturado no laboratório, e a lista de grupos da homologação ficou inalterada enquanto a sonda era atualizada.
2.5 Atividade prática
Em laboratório, conecte-se a um servidor de teste com um cliente TLS que imprima o grupo negociado, uma vez com o híbrido oferecido e outra sem ele. Registre os tamanhos do ClientHello a partir de uma captura do tráfego do seu próprio laboratório.
Use dois clientes se uma biblioteca não conseguir desabilitar o key share híbrido: por exemplo, um cliente OpenSSL 3.5 com os grupos padrão e o mesmo cliente forçado a usar apenas X25519. Registre, para cada execução, o grupo negociado, o comprimento do ClientHello na sua própria captura e se o hello ocupa um ou dois segmentos TCP. Espere cerca de 1.200 bytes a mais com o híbrido. Escreva uma frase explicando o que um middlebox que remonta apenas o primeiro segmento faria com cada execução.
2.6 Erros comuns e limites
- Acreditar que a troca de chaves híbrida muda os algoritmos dos certificados.
- Tratar as migrações de SSH e de TLS como uma única tarefa.
- Capturar tráfego que você não tem autorização para capturar.
A troca de chaves híbrida muda apenas a extensão do key share; o certificado e a sua assinatura RSA ou ECDSA ficam intactos, e é por isso que a KLS acompanha os certificados separadamente. SSH e TLS compartilham a ideia, mas não o software: a lista KexAlgorithms do OpenSSH nos hosts SFTP e a lista de grupos TLS do gateway são configuradas, testadas e revertidas de forma independente. As capturas se restringem ao tráfego de laboratório ou a escopos autorizados, porque os pacotes dos clientes contêm os dados deles.
Exercícios
- EX003 — Mapa de protocolos. Para o TLS 1.3, o SSH e o IKEv2, nomeie o mecanismo híbrido e o documento que o define. Rubrica: 3 = três corretos, com fontes.
- EX004 — Diferença em bytes. Quantos bytes o key share do servidor no X25519MLKEM768 tem a mais do que um key share X25519? Rubrica: 3 = 1.088 bytes (1.120 − 32), observando que isso é igual ao texto cifrado do ML-KEM-768.
Síntese
Cada canal seguro separa o estabelecimento de chaves da autenticação. A troca de chaves híbrida é padronizada para o TLS, está disponível no SSH e é especificada para o IKEv2; ela aumenta os handshakes e pode expor middleboxes antigos.
Continue estudando — capítulo 02 de 30
← Capítulo 01 · Índice de capítulos do curso · Capítulo 03 →
Siga para a próxima lição escrita.