Resumo

  • A RFC 3329 permitiu que um agente SIP e seu próximo salto trocassem mecanismos disponíveis, ativassem o mecanismo comum de maior preferência e, só então, devolvessem a lista estática completa do servidor em Security-Verify.
  • Essa devolução torna visível uma lista removida, reordenada ou alterada, mas não protege retroativamente a oferta inicial nem garante criptografia ou força moderna: o limite depende do mecanismo permitido mais fraco.

O ataque barato era tirar uma linha antes do acordo

Um intermediário no caminho não precisava se passar pelo servidor para influenciar uma negociação SIP. Bastava apagar uma opção forte da resposta ainda desprotegida e deixar uma alternativa inferior. Se cliente e servidor também conhecessem essa alternativa, ambos poderiam seguir em frente sem perceber que a lista havia mudado. A rede continuaria funcionando; justamente por isso, a redução poderia passar por uma diferença banal de capacidade.

O problema era temporal. Para escolher um mecanismo seguro, os pares precisavam conversar sobre mecanismos antes de ativar um deles. Só depois da escolha haveria alguma proteção capaz de cobrir aquela conversa. Pedir uma oferta inicial já protegida por um canal ainda inexistente não resolvia a sequência: apenas escondia o ponto em que a decisão era vulnerável.

A RFC 3329 distribuiu a tarefa em etapas. O agente de usuário enviava Security-Client ao próximo elemento SIP. O servidor respondia com Security-Server, sua lista estática de opções e os dados necessários para iniciar a opção escolhida. O cliente selecionava o mecanismo conhecido de maior preferência entre os comuns, ativava essa proteção e fazia nova requisição com Security-Verify, repetindo o que recebera do servidor.

Então o servidor fazia a comparação. Não bastava reconhecer os mesmos nomes em qualquer ordem: mecanismo, sequência e parâmetros precisavam corresponder à lista que ele próprio mantinha. Se a resposta original dizia quatro opções e a versão recebida pelo cliente mostrava três, o Security-Verify voltava curto. O servidor detectava a diferença e não aceitava aquele acordo como íntegro.

Isso não transformava a primeira resposta em uma mensagem protegida retroativamente. A primeira remoção ainda era possível. O que mudou foi o custo para ocultá-la do servidor: agora o atacante teria de falsificar também a devolução feita depois da ativação, sob a proteção escolhida. A falha deixou de ser uma edição silenciosa sem rastro e passou a exigir uma quebra da integridade da associação em uso.

Uma política estática impede que o servidor confirme a lista adulterada

Se a lista do servidor dependesse do Security-Client, o intermediário poderia reduzir a proposta do cliente primeiro. O servidor então responderia apenas com o que restou, e o cliente devolveria exatamente essa lista. A comparação seria correta em relação à resposta, mas não à política que existiria sem interferência.

Por isso, a lista de Security-Server tinha de ser estática e independente do conteúdo oferecido pelo cliente. Um nó podia manter configurações distintas por interface; isso não a tornava dinâmica em relação à negociação. Cada lista relevante já precisava existir antes daquela requisição, para funcionar como referência externa ao que o cliente viu.

Os mecanismos tinham valores q distintos. O cliente escolhia a alternativa conhecida de maior preferência do servidor, mas só entre as que também compreendia. Alterar Security-Client ainda poderia impedir que o servidor enviasse os parâmetros de início necessários ou fazer cada lado esperar uma escolha diferente. O resultado seria uma interrupção que merecia investigação, mas não provava ataque: uma configuração obsoleta ou uma incompatibilidade podia produzir o mesmo sintoma.

O desenho evitava manter uma tabela SIP de desafio por cliente. Quando a nova requisição protegida chegava, o servidor comparava o recibo com a lista estática pertinente. Isso não fazia de TLS, IKE ou Digest mecanismos sem estado. Uma conexão TLS pode terminar, uma associação IKE expira, e Digest pode exigir novo desafio. A economia de estado dizia respeito à conferência da lista, não ao ciclo de vida de toda a proteção.

421 e 494 marcavam situações diferentes

Na iniciativa do cliente, a primeira requisição sem proteção trazia Security-Client, além de Require e Proxy-Require com sec-agree. A resposta era 494 Security Agreement Required e incluía a lista do servidor mesmo quando não havia mecanismo comum. Assim, a incompatibilidade não ficava escondida atrás de um erro genérico.

O servidor também podia impor o acordo por política local. Se o cliente não tivesse indicado suporte à extensão, o servidor podia responder 421 Extension Required. Se o cliente já tivesse declarado suporte, mas ainda não tivesse concluído a negociação, usava 494. Esses códigos não eram veredictos forenses. Um 421 podia apontar para um cliente antigo; um 494 podia ser a etapa normal do acordo, uma divergência de listas ou uma tentativa de recuperação. Nenhum deles identificava sozinho quem alterou a mensagem.

O procedimento tinha alcance restrito ao agente de usuário e ao próximo salto, em geral um proxy de saída. No modo iniciado pelo servidor, mais de uma entrada Via significava que ele não era o primeiro salto e não devia aplicar aquela sequência. Portanto, a RFC não criou segurança de ponta a ponta para o diálogo SIP, nem protegeu automaticamente o corpo da mensagem ou cada proxy seguinte.

O modo de iniciar a proteção variava. TLS seguia as regras de localização de servidores SIP; Digest incorporava a lista à verificação; ipsec-ike tentava estabelecer IKE; e IPsec configurado manualmente dependia de chaves e políticas distribuídas fora do protocolo. A RFC 3310 acrescentava AKA ao entorno do Digest, sem substituir a lógica de devolver e comparar o que o servidor havia oferecido.

A opção mais fraca definia o piso

A condição de segurança da RFC era pouco confortável, mas explícita: o mecanismo mais fraco que ainda pudesse ser proposto precisava fornecer ao menos integridade e proteção contra repetição para Security-Verify. Se esse mecanismo pudesse ser quebrado, não deveria continuar na lista. A negociação reduzia uma forma trivial de downgrade; não elevava, por si só, a qualidade de uma opção fraca.

Concordância tampouco significava confidencialidade. Digest podia validar dados sem cifrar o conteúdo SIP. TLS cobria um salto, não todo o caminho até o destinatário final. IPsec dependia da associação e da política efetivamente instaladas. O recibo mostrava que a lista conferida correspondia à referência do servidor naquele ponto; não provava que todas as opções foram ativadas, que cada algoritmo seguia os padrões de hoje ou que o diálogo estava protegido de ponta a ponta.

O tempo alterou a leitura. A RFC 3329 saiu em janeiro de 2003. A RFC 8996 posteriormente atualizou o documento e proibiu negociar TLS 1.0 e 1.1. A RFC 8446 define TLS 1.3, enquanto a RFC 7616 revisa HTTP Digest. O registro de um nome na IANA continua sendo apenas coordenação de vocabulário, não evidência de uso ou adoção.

As erratas também pedem cuidado ao ler exemplos. Dois exemplos mostram Security-Verify em ACK, embora a tabela normativa de uso marque esse método como inaplicável; a correção aguarda revisão documental. Uma errata verificada alterou a gramática do SPI de ipsec-3gpp, de exatamente dez algarismos para um a dez. Exemplos e regra normativa não são intercambiáveis.

A contribuição histórica da RFC 3329 foi mais estreita do que “negociação segura”: quando a escolha precisa vir antes da proteção, guardar a oferta, devolvê-la por um canal já protegido e compará-la com uma referência independente torna a adulteração detectável. O recibo confirma continuidade da lista, não a sabedoria da política que aceita a opção mais fraca.

Fontes