Resumo
- O propósito histórico central do handshake em três vias é impedir que um SYN antigo e duplicado pareça uma nova tentativa de conexão.
- Cada ponta escolhe seu número inicial. O respondente reúne seu SYN com o ACK do número recebido; a terceira mensagem prova que o iniciador viu a resposta desta rodada.
- Quiet time, TIME-WAIT, ISNs secretos e SYN cookies tratam, respectivamente, memória perdida, pacotes antigos, adivinhação e custo de conexões incompletas. Não autenticam identidade.
Um segmento da conversa anterior
A Internet atrasa, duplica e reordena pacotes. Depois de uma conexão fechar, o mesmo par de endereços e portas pode ser reutilizado enquanto um SYN antigo ainda circula. O receptor vê um cabeçalho plausível, mas não encontra nele uma idade confiável.
O RFC 761, de janeiro de 1980, colocou o problema nos espaços de sequência. Cada TCP escolhe um número inicial de envio e aprende o do par. Antes de ordenar bytes, é preciso decidir a qual encarnação aqueles números pertencem.
Quatro afirmações em três mensagens
A anuncia X; B confirma X; B anuncia Y; A confirma Y. O TCP funde as duas falas de B: SYN X, SYN Y, ACK X+1, ACK Y+1.
SYN consome uma posição da sequência, por isso o ACK aponta para X+1. ACK puro não consome; caso contrário, confirmações exigiriam confirmações infinitas. O RFC 793 padronizou em 1981 a troca e seus estados.
Não há um cartório global de conexões. Duas escolhas locais tornam-se estado comum porque cada ponta recebe o número alheio e a confirmação do próprio.
A terceira mensagem comprova o presente
Quando B envia SYN-ACK, ainda não sabe se A mantém hoje o SYN original. Aquele pacote pode ser uma cópia de uma conexão esquecida. O ACK final cita o Y atual de B e demonstra que o estado presente em A viu o desafio.
RFC 761 chamou isso de troca entre memória e mensagens. Em vez de guardar todo o histórico de números para cada par, o receptor pede mais uma verificação.
O alcance é limitado: prova observação de números, não pessoa, empresa, autorização da aplicação ou ausência de adversário no caminho.
Números antigos também precisam expirar
O handshake lida com o SYN inicial; dados antigos podem chegar depois. As primeiras especificações adotaram dois minutos para a maximum segment lifetime. Se um crash apagasse a memória das sequências, o host deveria ficar silencioso por um MSL. Se preservasse a memória, poderia continuar além dos números recentes.
TIME-WAIT mantém a identidade da conexão por dois MSL após o fechamento. Duplicatas se esgotam e o ACK final pode ser repetido. Esperar é conservar o contexto que impede um pacote velho de adquirir sentido novo.
O texto atual, RFC 9293, preserva a lógica, mas considera o silêncio de reboot normalmente dispensável. Portas e ISNs aleatórios, menor vida efetiva e reboots demorados reduziram o risco. Em altas velocidades, timestamps e PAWS evitam confusão quando 32 bits giram depressa.
Quando TIME-WAIT perdeu a proteção
RFC 1337 descreveu o assassinato de TIME-WAIT. Um segmento antigo provoca ACK; o par sem estado responde RST; aceitar o reset encerra a espera cedo demais. Se o mesmo quádruplo reabrir logo, dados e ACKs antigos podem entrar na nova janela.
O documento mostrou bytes errados aceitos, dessincronização e falha de conexão. Handshake, verificação de janela e TIME-WAIT protegem momentos diferentes. Remover uma camada porque outra existe reabre a ambiguidade.
Número fresco não é identidade autenticada
ISNs previsíveis permitiram ACKs falsificados por atacantes fora do caminho. RFC 6528 soma um contador de tempo a uma função secreta dos dois endereços e portas. Os quádruplos ganham deslocamentos sem relação externa evidente, preservando progressão.
Isso dificulta o palpite cego, mas quem observa o caminho vê a troca. Identidade e autorização precisam de prova criptográfica separada.
Guardar o estado dentro do desafio
Servidores costumam reservar memória assim que recebem SYN, antes de o cliente confirmar qualquer coisa. Muitos SYNs falsos enchem a fila. RFC 4987 registra como SYN floods se tornaram públicos em 1996 e descreve mitigações.
Uma SYN cookie codifica quádruplo, ISN do cliente, tempo, alguns parâmetros e segredo no número do SYN-ACK. Sem guardar o bloco completo, o servidor espera o ACK final; quando ele chega, valida e reconstrói estado.
O custo é adiado até a evidência voltar. Bits limitados restringem opções, e implementações fazem escolhas diferentes.
A história dos três passos é, portanto, uma divisão de funções. A rede entrega, pontas escolhem, ACKs sincronizam, tempo envelhece, segredo dificulta palpite e cookie posterga memória. Nenhuma dessas funções certifica quem o par é no mundo.
Fontes e limites da evidência
- https://www.rfc-editor.org/rfc/rfc761.html
- https://www.rfc-editor.org/rfc/rfc793.html
- https://www.rfc-editor.org/rfc/rfc1337.html
- https://www.rfc-editor.org/rfc/rfc4987.html
- https://www.rfc-editor.org/rfc/rfc6528.html
- https://www.rfc-editor.org/rfc/rfc9293.html
Os RFCs sustentam especificações e análises delimitadas, não uma data universal de implantação. A leitura de prova recíproca transformando decisões locais em estado partilhado é uma inferência arquitetônica.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
