Capítulo 2 — Redes e protocolos

Capítulo 2 — Redes e protocolos

Mapa da aula

Aula 02 publicada. Mapa, exemplo, EX004.

flowchart TD
  N0["2.1 Três canais seguros"]
  N1["2.2 Troca de chaves híbrida"]
  N2["2.3 Lendo o grupo negociado"]
  N3["2.4 Handshakes maiores"]
  N4["2.5 Caso resolvido"]
  N5["2.6 Atividade prática"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX004"]

Desenho lógico

flowchart LR
  N0["2.1 Três canais seguros"]
  N1["2.2 Troca de chaves híbrida"]
  N2["2.3 Lendo o grupo negociado"]
  N3["2.4 Handshakes maiores"]
  N4["2.5 Caso resolvido"]
  N5["2.6 Atividade prática"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX004"]

[2.1 Três canais seguros]
    |
    v
[2.2 Troca de chaves híbrida]
    |
    v
[2.3 Lendo o grupo negociado]
    |
    v
[2.4 Handshakes maiores]
    |
    v
[2.5 Caso resolvido]
    |
    v
[2.6 Atividade prática]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX004]

Objetivos de aprendizagem

Você vai (1) explicar TLS, SSH e IPsec no nível necessário para verificá-los; (2) identificar as partes de troca de chaves e de autenticação de cada um; (3) ler qual grupo de troca de chaves uma conexão TLS usou; e (4) explicar por que os handshakes pós-quânticos são maiores.

2.1 Três canais seguros

O TLS protege o tráfego web e de APIs; o SSH protege os logins de administradores e as transferências de arquivos (SFTP); o IPsec protege as VPNs entre sites. Cada um primeiro acorda uma chave de sessão (troca de chaves) e prova a identidade (certificados, chaves de host ou chaves pré-compartilhadas), e depois cifra os dados com uma cifra simétrica.

Para cada canal, faça duas perguntas: como a chave é acordada e como a identidade é provada? O trabalho pós-quântico muda a primeira parte com a troca de chaves híbrida e, mais tarde, a segunda com novos certificados ou chaves. No HHG, as VPNs de site usam IPsec, a troca de arquivos dos canais usa SFTP e o portal do hóspede usa TLS.

2.2 Troca de chaves híbrida

O projeto de transição combina um método pós-quântico e um clássico, de modo que ambos teriam de ser quebrados — o que se chama híbrido (RFC 9794). No TLS 1.3, o grupo híbrido X25519MLKEM768 é definido na RFC 10024. No SSH, o OpenSSH oferece mlkem768x25519-sha256 (notas de versão do OpenSSH). No IPsec, a RFC 9370 acrescenta trocas de chaves extras, como o ML-KEM.

Consulte a documentação do produto para saber o nome que ele usa.

2.3 Lendo o grupo negociado

Numa máquina de laboratório com um OpenSSL atual, openssl s_client -connect lab-server:443 -groups X25519MLKEM768:X25519 imprime detalhes do handshake, incluindo o grupo negociado nas versões recentes. Os logs do servidor podem registrar o grupo, se configurados para isso. No SSH, ssh -v imprime o algoritmo de troca de chaves escolhido ("kex: algorithm: …"). Execute esses comandos apenas contra sistemas que você está autorizado a testar.

Salve a saída com a data e a versão do cliente, já que um cliente antigo não consegue mostrar um grupo híbrido mesmo quando o servidor o oferece. No portal do hóspede de homologação do HHG, foi assim que o problema de ordem dos grupos do Capítulo 5 foi visto pela primeira vez.

2.4 Handshakes maiores

O compartilhamento de chave TLS do cliente cresce de 32 bytes (X25519) para 1.216 bytes (X25519MLKEM768), de modo que a primeira mensagem muitas vezes já não cabe num único pacote de rede. A maioria das redes lida com isso; alguns firewalls antigos não. As assinaturas pós-quânticas acrescentam mais quando os certificados mudam: uma assinatura ML-DSA-44 tem 2.420 bytes.

Para os operadores, o efeito prático é que um handshake híbrido pode falhar num caminho de rede e funcionar nos outros. Quando você vir timeouts apenas através de um firewall ou proxy, pense no tamanho da mensagem antes de culpar o algoritmo. Anote o modelo e o firmware do dispositivo, como fez o operador do HHG na unidade Summit.

2.5 Caso resolvido

Um operador do HHG se conecta do laboratório ao portal do hóspede de homologação com um cliente atual e vê o grupo híbrido negociado. Com um cliente mais antigo, a conexão é bem-sucedida com X25519 — o fallback esperado. Através da cópia de laboratório do firewall antigo da unidade Summit, a conexão expira por timeout; o operador registra o modelo e o firmware do firewall para acompanhamento.

Os três resultados significam coisas diferentes: o resultado híbrido mostra que o servidor funciona, o fallback mostra que os clientes mais antigos continuam sendo atendidos e o timeout aponta para o caminho de rede, não para o servidor. O operador não muda o portal; o firewall vira um item de acompanhamento.

2.6 Atividade prática

No seu laboratório, execute um cliente TLS contra um servidor de teste duas vezes — com e sem o grupo híbrido oferecido — e registre o grupo negociado em cada vez. Repita no SSH com ssh -v.

Registre, para cada execução, o comando, a versão do cliente, o alvo, o horário e o grupo negociado ou o algoritmo de troca de chaves. Depois explique em uma ou duas frases por que os resultados diferem. Se o seu cliente não conseguir mostrar o grupo, anote isso e use um cliente mais novo. Use apenas os seus próprios servidores de laboratório. Guarde os arquivos de saída com nomes datados, porque os capítulos seguintes pedem que você compare execuções e escreva constatações a partir delas.

2.7 Erros comuns e limites

• Achar que a troca de chaves híbrida muda os certificados.
• Testar sistemas sem autorização.
• Culpar o algoritmo por uma falha de firewall.

Cada erro leva a uma conclusão errada ou a um ato inseguro. A troca de chaves híbrida protege as chaves de sessão, mas o servidor continua provando a sua identidade com um certificado clássico. Testar sem autorização pode derrubar um serviço e custar à sua equipe o direito de testar. Um firewall que descarta mensagens grandes, como no Summit, é um problema de rede, e remover o híbrido para resolvê-lo deixaria todo o resto do tráfego desprotegido. Confira as suas anotações contra esses três antes de escrever uma constatação.

Exercícios

• EX004 — Duas partes. Para TLS, SSH e IPsec, nomeie a parte de troca de chaves e a de identidade. Rubrica: 3 = seis entradas corretas.
• EX005 — Ler a saída. Uma linha de ssh -v diz kex: algorithm: curve25519-sha256. A sessão é híbrida? O que você verificaria em seguida? Rubrica: 3 = não é híbrida; verificar as listas de KEX/versões do servidor e do cliente.
• EX006 — Tamanho. Quanto maior é o compartilhamento do cliente no X25519MLKEM768 do que no X25519? Rubrica: 3 = 1.184 bytes.

Síntese

TLS, SSH e IPsec acordam chaves e provam identidade. A troca de chaves híbrida está disponível nos três; os operadores leem os algoritmos negociados na saída dos clientes e nos logs.

Continue estudando — capítulo 02 de 18

← Capítulo 01 · Índice de capítulos do curso · Capítulo 03 →

Siga para a próxima lição escrita.