Módulo 15 – BÔNUS: O Handshake TCP e TLS explicado de forma simples
+==============================================================================+
| MÓDULO 15 (BÔNUS): HANDSHAKE TCP + TLS (HTTPS) |
| Duração estimada: 1 hora | Nível: Iniciante absoluto |
+==============================================================================+
Índice
- Por que esta página?
- Vocabulário básico – Os “flags” TCP
- O handshake TCP em 3 etapas (SYN / SYN-ACK / ACK)
- E depois do handshake? Troca de dados (PSH, ACK)
- Como fechar a conexão? (FIN / FIN-ACK)
- Resumo completo de uma conexão TCP
- O handshake TLS – Adicionando o cadeado
- Exemplo concreto: Abrindo https://google.com
- O que você vê no Wireshark
- Resumo final – A analogia completa
Por que esta página?
Quando você abre um site, seu navegador e o servidor conversam. Mas antes de trocarem qualquer coisa, eles precisam:
- Verificar se conseguem se comunicar (handshake TCP)
- Combinar como vão criptografar (handshake TLS, se for HTTPS)
- Trocar os dados (a página web)
- Encerrar a ligação corretamente (fechamento da conexão)
Todas essas trocas usam pequenos flags nos pacotes de rede. É isso que vamos explicar aqui, como se você nunca tivesse estudado redes.
Vocabulário básico – Os “flags” TCP
Imagine que cada mensagem de rede é uma carta enviada pelo correio. Em cada envelope, há um ou mais carimbos (flags) que dizem que tipo de mensagem é.
Aqui estão os principais flags TCP:
| Flag | Nome completo | Analogia simples | Significado técnico |
|---|---|---|---|
| SYN | Synchronize | 📞 “Alô? Você está aí?” | “Quero abrir uma conexão” |
| ACK | Acknowledge | ✅ “Recebido!” | “Recebi sua mensagem” |
| PSH | Push | 📦 “Aqui está o pacote, abra já!” | “Aqui estão dados, processe imediatamente” |
| FIN | Finish | 👋 “Tchau, estou desligando” | “Quero fechar a conexão” |
| RST | Reset | ❌ “PARE! Desliguei à força!” | “Conexão cancelada / recusada abruptamente” |
O mais importante para lembrar
- SYN = “quero começar”
- ACK = “entendi / recebido”
- PSH = “aqui estão os dados reais”
- FIN = “terminei, tchau”
O handshake TCP em 3 etapas (SYN / SYN-ACK / ACK)
A analogia do telefone
Imagine que você liga para um amigo:
┌─────────────────────────────────────────────────────────────────────┐
│ LIGAÇÃO TELEFÔNICA │
│ │
│ Você (Cliente) Seu amigo (Servidor) │
│ │
│ 1. 📞 “Alô? Você me ouve?” ──────► │
│ (O telefone toca) │
│ │
│ ◄────── 2. 📞 “Sim, estou ouvindo! │
│ E você, me ouve?” │
│ │
│ 3. 📞 “Sim, perfeito, podemos falar!” ──────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ ✅ CONVERSA ESTABELECIDA — Agora vocês podem conversar! │
└─────────────────────────────────────────────────────────────────────┘
O mesmo em TCP
┌─────────────────────────────────────────────────────────────────────┐
│ HANDSHAKE TCP (3-WAY HANDSHAKE) │
│ │
│ Cliente (seu PC) Servidor (ex: google.com)│
│ │
│ ETAPA 1: SYN │
│ ──────────────────────────────────────► │
│ “Quero me conectar. Meu número │
│ de sequência inicial é 100.” │
│ │
│ ETAPA 2: SYN-ACK │
│ ◄────────────────────────────────────── │
│ “OK, aceito (ACK do seu 100). │
│ Meu número de sequência é 300.” │
│ │
│ ETAPA 3: ACK │
│ ──────────────────────────────────────► │
│ “Perfeito, recebido (ACK do seu 300). │
│ Podemos começar!” │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ ✅ CONEXÃO TCP ESTABELECIDA │
│ ❌ Mas NADA está criptografado por enquanto! │
└─────────────────────────────────────────────────────────────────────┘
Por que 3 etapas e não 1?
É para garantir que a comunicação funciona nos dois sentidos:
| Etapa | Prova que... |
|---|---|
| SYN (Cliente → Servidor) | O cliente consegue enviar para o servidor |
| SYN-ACK (Servidor → Cliente) | O servidor recebeu E consegue responder |
| ACK (Cliente → Servidor) | O cliente recebeu a resposta do servidor |
Sem essas 3 etapas, não saberíamos se as duas máquinas realmente se entendem.
E depois do handshake? Troca de dados (PSH, ACK)
Depois que a conexão está aberta, os dados reais circulam. É aí que vemos PSH e ACK:
A analogia da entrega de pacotes
┌─────────────────────────────────────────────────────────────────────┐
│ TROCA DE DADOS (após o handshake) │
│ │
│ Cliente (navegador) Servidor (site) │
│ │
│ 📦 PSH,ACK: “Aqui está meu pedido: │
│ quero a página inicial” ──────────────► │
│ (= requisição HTTP GET /) │
│ │
│ ◄────────────── ✅ ACK: │
│ “Recebi seu pedido” │
│ │
│ ◄────────────── 📦 PSH,ACK: │
│ “Aqui está a página HTML!” │
│ (= resposta HTTP 200 OK) │
│ │
│ ✅ ACK: “Recebi a página, │
│ obrigado!” ──────────────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 📄 A página aparece no seu navegador! │
└─────────────────────────────────────────────────────────────────────┘
Por que PSH + ACK juntos?
Você verá frequentemente PSH,ACK no Wireshark (os dois flags ao mesmo tempo). Isso é normal:
| Flag | Papel neste pacote |
|---|---|
| PSH | “Aqui estão dados, processe já” |
| ACK | “A propósito, recebi suas mensagens anteriores” |
PSH = “Estou enviando um pacote”
ACK = “E confirmo o recebimento do que você enviou antes”
Os dois juntos = eficiência: fazemos duas coisas em um só pacote!
E se não usar PSH?
Sem PSH, os dados chegam mas o sistema pode esperar antes de processar (ele coloca em "buffer"). Com PSH, é “processe isso agora!”
Pense na diferença entre:
- 📬 Colocar uma carta na caixa de correio (sem PSH → o carteiro processa quando quiser)
- 🚨 Tocar a campainha e dizer “é urgente, leia agora!” (com PSH)
Como fechar a conexão? (FIN / FIN-ACK)
Quando a conversa termina, desligamos corretamente:
┌─────────────────────────────────────────────────────────────────────┐
│ FECHAMENTO DE CONEXÃO (4-WAY) │
│ │
│ Cliente Servidor │
│ │
│ 👋 FIN,ACK: “Terminei, │
│ quero desligar” ──────────────► │
│ │
│ ◄────────────── ✅ ACK: │
│ “OK, entendi” │
│ │
│ ◄────────────── 👋 FIN,ACK: │
│ “Eu também terminei” │
│ │
│ ✅ ACK: “OK, tchau!” ──────────────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 🔌 CONEXÃO FECHADA CORRETAMENTE │
└─────────────────────────────────────────────────────────────────────┘
E o RST nisso tudo?
RST (Reset) é quando desligamos abruptamente, sem despedida:
| Situação | O que acontece |
|---|---|
| A porta está fechada no servidor | O servidor responde RST → “Esse serviço não existe!” |
| O firewall bloqueia a conexão | Pode ser RST, ou nenhuma resposta (timeout) |
| O aplicativo travou | O sistema envia RST para cortar a conexão |
FIN = desligar educadamente 👋
RST = bater o telefone na cara ❌
Resumo completo de uma conexão TCP
Aqui está todo o ciclo de vida de uma conexão TCP, do início ao fim:
┌─────────────────────────────────────────────────────────────────────┐
│ CICLO DE VIDA COMPLETO DE UMA CONEXÃO TCP │
│ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ FASE 1: ABERTURA (3-way handshake) ║ │
│ ║ ║ │
│ ║ Cliente ──── SYN ────────► Servidor ║ │
│ ║ Cliente ◄─── SYN,ACK ──── Servidor ║ │
│ ║ Cliente ──── ACK ────────► Servidor ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ FASE 2: TROCA DE DADOS ║ │
│ ║ ║ │
│ ║ Cliente ──── PSH,ACK ───► Servidor (requisição) ║ │
│ ║ Cliente ◄─── ACK ──────── Servidor (confirmação) ║ │
│ ║ Cliente ◄─── PSH,ACK ──── Servidor (resposta) ║ │
│ ║ Cliente ──── ACK ────────► Servidor (confirmação) ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ FASE 3: FECHAMENTO (4-way) ║ │
│ ║ ║ │
│ ║ Cliente ──── FIN,ACK ───► Servidor ║ │
│ ║ Cliente ◄─── ACK ──────── Servidor ║ │
│ ║ Cliente ◄─── FIN,ACK ──── Servidor ║ │
│ ║ Cliente ──── ACK ────────► Servidor ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │
│ 🏁 FIM — Conexão encerrada corretamente │
└─────────────────────────────────────────────────────────────────────┘
O handshake TLS – Adicionando o cadeado
Quando o TLS entra em ação?
O TLS fica entre o handshake TCP e os dados:
Etapa 1: Handshake TCP → “Abrimos a porta”
Etapa 2: Handshake TLS → “Colocamos o cadeado + verificamos a identidade”
Etapa 3: Dados criptografados → “Conversamos, mas ninguém pode ouvir”
A analogia do banco
Imagine que você quer enviar uma mensagem secreta para seu banco:
┌─────────────────────────────────────────────────────────────────────┐
│ HANDSHAKE TLS (simplificado) │
│ │
│ Você (Cliente) O Banco (Servidor) │
│ │
│ ETAPA 1 — ClientHello │
│ ──────────────────────────────────────► │
│ “Olá! Quero me comunicar em segredo. │
│ Aqui estão os métodos de criptografia que conheço: │
│ AES-256, ChaCha20, etc.” │
│ │
│ ETAPA 2 — ServerHello + Certificado │
│ ◄────────────────────────────────────── │
│ “OK! Vamos usar AES-256. │
│ E aqui está minha IDENTIDADE (certificado): │
│ - Eu sou mesmo o 'Banco Nacional' │
│ - Assinado por uma autoridade confiável (Let's Encrypt, etc.) │
│ - Válido até 2026-12-31” │
│ │
│ ETAPA 3 — Verificação (lado do cliente) │
│ 🔍 Você verifica a identidade: │
│ ✅ O nome bate com o site? │
│ ✅ Assinado por uma autoridade reconhecida? │
│ ✅ Não expirou? │
│ → Se tudo OK, continua. Se não = erro de certificado. │
│ │
│ ETAPA 4 — Troca de chaves │
│ ──────────────────────────────────────► │
│ 🔐 Cliente e servidor combinam um │
│ SEGREDO COMPARTILHADO (sem nunca enviar em texto claro!) │
│ Método: Diffie-Hellman ou similar. │
│ │
│ Analogia: imagine que cada um mistura uma cor │
│ de tinta em segredo. Vocês trocam o resultado, │
│ e ambos chegam à MESMA cor final, │
│ mas quem observa não consegue adivinhar qual é. │
│ │
│ ETAPA 5 — Finished │
│ ◄─────────── (ambos os lados) ──────────► │
│ “Temos as mesmas chaves secretas. │
│ Daqui pra frente, TUDO é criptografado!” │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 🔒 TÚNEL TLS ESTABELECIDO — Toda a comunicação é criptografada! │
└─────────────────────────────────────────────────────────────────────┘
Perguntas frequentes
O que é um certificado?
É a identidade digital do servidor. Ela contém:
- O nome do site (ex:
google.com) - A chave pública do servidor
- A assinatura de uma autoridade certificadora (ex: Let's Encrypt, DigiCert)
- A data de expiração
Seu navegador verifica tudo isso automaticamente. Se algo não bater → 🔴 “Sua conexão não é privada”.
O que é Diffie-Hellman?
É um método matemático para que duas pessoas combinem um segredo em comum, mesmo que alguém esteja ouvindo todas as mensagens.
Analogia das cores de tinta:
Você: escolhe secretamente AZUL 🔵
Banco: escolhe secretamente VERMELHO 🔴
Cor base pública: AMARELO 🟡
Você: mistura AMARELO + AZUL = VERDE 🟢 → você envia o VERDE
Banco: mistura AMARELO + VERMELHO = LARANJA 🟠 → ele envia o LARANJA
Você: recebe LARANJA + seu AZUL secreto = MARROM 🟤
Banco: recebe VERDE + seu VERMELHO secreto = MARROM 🟤
✅ Vocês têm a mesma cor final (MARROM)!
❌ O espião só vê VERDE e LARANJA... não consegue descobrir o MARROM!
Na prática, não são cores, mas números grandes matemáticos, mas o princípio é o mesmo.
Exemplo concreto: Abrindo https://google.com
Veja o que acontece de verdade quando você digita https://google.com no seu navegador:
┌─────────────────────────────────────────────────────────────────────┐
│ SEU PC (192.168.1.50) GOOGLE (142.250.80.46) │
│ │
│ ── ETAPA 1: RESOLUÇÃO DNS ─────────────────────────────────── │
│ “Qual é o IP do google.com?” │
│ → Resposta DNS: 142.250.80.46 │
│ │
│ ── ETAPA 2: HANDSHAKE TCP ─────────────────────────────────── │
│ Pacote 1: [SYN] 192.168.1.50:54321 → 142.250.80.46:443 │
│ Pacote 2: [SYN,ACK] 142.250.80.46:443 → 192.168.1.50:54321 │
│ Pacote 3: [ACK] 192.168.1.50:54321 → 142.250.80.46:443 │
│ ✅ Conexão TCP estabelecida na porta 443 (HTTPS) │
│ │
│ ── ETAPA 3: HANDSHAKE TLS ─────────────────────────────────── │
│ Pacote 4: ClientHello → versões TLS, algoritmos propostos │
│ Pacote 5: ServerHello ← algoritmo escolhido │
│ Pacote 6: Certificate ← certificado do google.com │
│ Pacote 7: Key Exchange ↔ troca Diffie-Hellman │
│ Pacote 8: Finished ↔ verificação dos dois lados │
│ 🔒 Túnel TLS estabelecido — agora tudo é criptografado │
│ │
│ ── ETAPA 4: DADOS CRIPTOGRAFADOS ─────────────────────────── │
│ Pacote 9: [PSH,ACK] (criptografado) → GET / HTTP/1.1 │
│ (sua requisição para a página inicial) │
│ Pacote 10: [ACK] ← confirmação de recebimento │
│ Pacote 11: [PSH,ACK] (criptografado) ← HTTP/1.1 200 OK + página HTML │
│ (a página inicial do Google) │
│ Pacote 12: [ACK] → confirmação de recebimento │
│ 📄 A página do Google aparece no seu navegador! │
│ │
│ ── ETAPA 5: FECHAMENTO ────────────────────────────────────── │
│ Pacote 13: [FIN,ACK] → “Terminei” │
│ Pacote 14: [FIN,ACK] ← “Eu também” │
│ Pacote 15: [ACK] → “OK, tchau” │
│ 🔌 Conexão encerrada │
└─────────────────────────────────────────────────────────────────────┘
Porta 443 vs Porta 80
- Porta 80 = HTTP (não criptografado) → sem handshake TLS
- Porta 443 = HTTPS (criptografado) → handshake TLS obrigatório
Por isso a URL https:// sempre usa a porta 443 por padrão.
O que você vê no Wireshark
Captura HTTP (porta 80) – NÃO criptografado
┌──────┬────────────────────┬────────────────────┬──────────┬──────────────────────┐
│ No │ Source │ Destination │ Protocol │ Info │
├──────┼────────────────────┼────────────────────┼──────────┼──────────────────────┤
│ 1 │ 192.168.1.50 │ 93.184.216.34 │ TCP │ SYN │
│ 2 │ 93.184.216.34 │ 192.168.1.50 │ TCP │ SYN, ACK │
│ 3 │ 192.168.1.50 │ 93.184.216.34 │ TCP │ ACK │
│ 4 │ 192.168.1.50 │ 93.184.216.34 │ HTTP │ GET / HTTP/1.1 ⚠️ │
│ 5 │ 93.184.216.34 │ 192.168.1.50 │ TCP │ ACK │
│ 6 │ 93.184.216.34 │ 192.168.1.50 │ HTTP │ 200 OK ⚠️ │
└──────┴────────────────────┴────────────────────┴──────────┴──────────────────────┘
⚠️ Dá para ver TUDO em texto claro! A requisição, a resposta, o conteúdo da página...
Qualquer pessoa na rede pode ler esses dados!
Captura HTTPS (porta 443) – Criptografado
┌──────┬────────────────────┬────────────────────┬──────────┬──────────────────────┐
│ No │ Source │ Destination │ Protocol │ Info │
├──────┼────────────────────┼────────────────────┼──────────┼──────────────────────┤
│ 1 │ 192.168.1.50 │ 142.250.80.46 │ TCP │ SYN │
│ 2 │ 142.250.80.46 │ 192.168.1.50 │ TCP │ SYN, ACK │
│ 3 │ 192.168.1.50 │ 142.250.80.46 │ TCP │ ACK │
│ 4 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Client Hello │
│ 5 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Server Hello │
│ 6 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Certificate │
│ 7 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Key Exchange │
│ 8 │ ... │ ... │ TLSv1.3 │ Finished │
│ 9 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Application Data 🔒 │
│ 10 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Application Data 🔒 │
└──────┴────────────────────┴────────────────────┴──────────┴──────────────────────┘
🔒 "Application Data" = dados criptografados. Não dá para ler o conteúdo!
Só dá para ver que há tráfego, mas não O QUE está sendo trocado.
O que um atacante pode ver em HTTPS
Mesmo com HTTPS, um atacante na rede pode ver:
- O endereço IP do servidor (ex: 142.250.80.46)
- O nome do site (pelo campo SNI no ClientHello, ex:
google.com) - A quantidade de dados trocados
- O momento da conexão
Mas ele NÃO pode ver:
- ❌ A URL completa (ex:
/search?q=meu+segredo) - ❌ O conteúdo da página
- ❌ Cookies, senhas, formulários
- ❌ Os dados enviados nos dois sentidos
Resumo final – A analogia completa
HTTP vs HTTPS em uma imagem
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ HTTP (porta 80) HTTPS (porta 443) │
│ │
│ 📞 Handshake TCP 📞 Handshake TCP │
│ (SYN → SYN,ACK → ACK) (SYN → SYN,ACK → ACK) │
│ │ │ │
│ │ 🔒 Handshake TLS │
│ │ (ClientHello → Certificate → Keys) │
│ │ │ │
│ ▼ ▼ │
│ 📦 Dados EM TEXTO CLARO 📦 Dados CRIPTOGRAFADOS │
│ (todo mundo pode ler) (ninguém pode ler) │
│ │ │ │
│ 👋 Fechamento TCP 👋 Fechamento TCP │
│ (FIN → ACK) (FIN → ACK) │
│ │
│ 🔴 Perigoso! 🟢 Seguro! │
└─────────────────────────────────────────────────────────────────────┘
O mémo dos flags TCP
┌──────────────────────────────────────────────────────────────────┐
│ MÉMO DOS FLAGS TCP │
│ │
│ SYN = 📞 “Quero abrir uma conexão” │
│ ACK = ✅ “Recebido!” │
│ PSH = 📦 “Aqui estão dados, processe já” │
│ FIN = 👋 “Terminei, tchau” │
│ RST = ❌ “Desliguei à força!” │
│ │
│ SYN,ACK = 📞✅ “Aceito sua conexão + recebido” │
│ PSH,ACK = 📦✅ “Aqui estão dados + recebi os seus” │
│ FIN,ACK = 👋✅ “Estou fechando + recebi suas últimas mensagens”│
└──────────────────────────────────────────────────────────────────┘
O resumo em 5 frases
Resumo
- TCP abre a conexão com SYN / SYN-ACK / ACK (3-way handshake)
- TLS protege a conexão com certificado + troca de chaves (handshake TLS)
- PSH,ACK envia os dados reais (requisições HTTP, páginas web, etc.)
- FIN,ACK fecha a conexão corretamente
- ACK acompanha quase tudo: é só um “recebido” que garante que nada se perde
TP Bônus criado em: Fevereiro de 2026