Resumo

  • O FEP carregava um datagrama IP inteiro no corpo HTTP; um host colaborador dentro do firewall o decodificava e injetava na própria pilha de protocolos.
  • A passagem da conexão HTTP provava somente a admissão do transportador, não permissão para endereços, portas, aplicação, usuário, reinjeção ou resultado interno.

A regra reconhecia o lado de fora

O texto partiu do conflito entre inovação nas pontas e controle no caminho. Uma nova aplicação podia funcionar nos hosts, mas não atravessar o firewall corporativo porque suas portas ou seu protocolo não pertenciam às regras existentes. A RFC 3093 levou uma resposta à caricatura: se HTTP costuma passar, qualquer datagrama pode vestir a aparência de HTTP.

O caminho era explícito. O host externo entregava o datagrama ao FEP. O software o transformava em mensagem HTTP e o enviava pelo acesso comum. No interior, outro FEP extraía os bytes, reconstruía um datagrama e o inseria na pilha IP protegida, como se o firewall nunca tivesse existido.

Entretanto, o firewall observava a sessão externa. O pacote interno mantinha origem, destino, transporte e finalidade próprios. A decisão aplicada ao veículo não se transferia automaticamente à carga.

O colaborador interno virou autoridade

A RFC dizia preservar o modelo de segurança porque precisava de um host cooperante no interior. Partia da ideia de que firewalls cuidavam de ameaças externas e ignoravam as internas. Essa era a premissa do documento, não uma garantia. Um processo capaz de desencapsular tráfego arbitrário e gravá-lo na pilha de rede era um novo ponto privilegiado.

O operador do firewall controlava a conexão externa. O operador do host habilitava o FEP e a reinjeção. O usuário escolhia a aplicação. A implementação interpretava os bytes. Nenhum desses fatos, isolado, provava que a organização havia autorizado o comportamento combinado.

Assim, um log de HTTP aceito não descrevia o fluxo escondido. A recepção no túnel não provava a injeção; a injeção não provava aceitação por socket; e a socket não provava processamento ou efeito externo.

Os cabeçalhos legíveis eram cópias

O datagrama completo ficava no corpo HTTP. O FEP também copiava campos TCP e, opcionalmente, IP para novos cabeçalhos legíveis: portas decimais, maiúsculas para urgência, vida restante em frase e endereços aparentes como nomes de domínio.

O próprio RFC dizia que essas cópias existiam estritamente para leitura, pois o datagrama já estava no corpo. Um TCP_Dport visível não autenticava o destino real. As representações podiam divergir, e o programa precisava definir qual delas governava a reconstrução, validar limites e aplicar política antes da injeção.

Usar pedidos GET ou respostas GET em ambas as direções também explorava uma forma reconhecida. O pacote não virava uma solicitação Web comum. HTTP era a superfície que o intermediário sabia identificar. Reconhecer sintaxe e reconhecer intenção eram trabalhos distintos.

A provocação conservou um problema real

A data, os campos absurdos e a seção que nega considerações reais de segurança colocam o documento como provocação Informational, não manual operacional. Não é necessário afirmar a intenção dos autores. O mecanismo publicado já mostra que uma permissão ampla pode virar transporte geral quando uma ponta aceita encapsular.

As RFCs 2775 e 2979 tratavam de transparência e comportamento de firewalls. As RFCs 2663, 3027 e 3234 registraram efeitos de NATs e middleboxes. SOCKS5 negociava com gateway explícito e oferecia métodos de autenticação. São contextos vizinhos, não evidência de implementação do FEP.

A conclusão é precisa: uma regra pode permitir HTTP corretamente e permanecer muda sobre o conteúdo interno. Provar controle requer identificar e autenticar o ponto do túnel, limitar protocolos e destinos, registrar reinjeção e observar a aplicação. O sucesso de uma camada não substitui os recibos das outras.

Fontes

  1. https://www.rfc-editor.org/info/rfc3093
  2. https://www.rfc-editor.org/rfc/rfc3093.html
  3. https://www.rfc-editor.org/rfc/rfc3093.txt
  4. https://datatracker.ietf.org/doc/rfc3093/
  5. https://www.rfc-editor.org/errata/rfc3093
  6. https://www.rfc-editor.org/rfc/rfc2775.html
  7. https://www.rfc-editor.org/rfc/rfc2979.html
  8. https://www.rfc-editor.org/rfc/rfc3234.html
  9. https://www.rfc-editor.org/rfc/rfc2663.html
  10. https://www.rfc-editor.org/rfc/rfc3027.html
  11. https://www.rfc-editor.org/rfc/rfc1928.html
  12. https://www.rfc-editor.org/rfc/rfc2616.html
  13. https://www.rfc-editor.org/rfc/rfc793.html
  14. https://www.rfc-editor.org/rfc/rfc791.html
  15. https://www.rfc-editor.org/rfc/rfc2119.html