RFC 3093: HTTP 허용은 패킷 승인이 아니었다

요약

RFC 3093의 방화벽 향상 프로토콜(FEP)은 완전한 IP 데이터그램을 HTTP 본문에 담아 내부 호스트가 이를 해독해 자신의 프로토콜 스택에 주입하도록 요청했습니다.
HTTP 연결의 통과는 외부 운반체가 통과했다는 사실만을 증명할 뿐, 방화벽 정책이 내부 주소·포트·애플리케이션·사용자·재주입 또는 결과를 승인했다는 것을 증명하지 않았습니다.

열린 통로는 웹을 위한 것이었지, 웹이 실어 나를 수 있는 모든 것을 위한 것이 아니었다

이 문서는 누구나 인식할 수 있는 아키텍처적 충돌에서 출발합니다. 종단 간 투명성은 네트워크가 이해하지 않아도 호스트에서 새 애플리케이션이 등장할 수 있게 했습니다. 기업 방화벽은 경로에 통제 지점을 추가했습니다. 새 애플리케이션이 기술적으로 타당하더라도 그 트래픽이 해당 지점의 규칙과 맞지 않으면 실패할 수 있었습니다.

RFC 3093은 의도적으로 과도한 문자 그대로의 해석으로 답했습니다. HTTP가 대개 방화벽을 통과한다면, 임의의 트래픽도 HTTP로 꾸밀 수 있다는 것입니다. 외부 애플리케이션의 TCP/IP 데이터그램은 FEP 소프트웨어로 들어가 HTTP 메시지가 되고, 평범한 HTTP 경로를 통해 통과하며, 내부의 협력 소프트웨어에 도달해 해독된 뒤, 마치 "방화벽이 존재하지 않았던 것처럼" 보호된 호스트의 IP 스택으로 되돌아갑니다. 운영자에게 새 애플리케이션을 승인하라는 요구는 없었습니다.

이 경로는 증거의 경계를 특히 선명하게 만듭니다. 방화벽은 외부 세션을 관찰하고 허용했습니다. 내부 패킷은 자신만의 발신지, 수신지, 전송 계층 필드와 애플리케이션 의미를 그대로 유지했습니다. 운반체에 대한 승인이 자동으로 화물까지 확장되지는 않았습니다.

내부 협력자가 통제 지점을 바꾸었다

이 메모는 내부 호스트의 협력이 필요하므로 방화벽의 보안 모델을 유지한다고 주장했습니다. 그 전제는 방화벽이 외부 위협은 다루면서 내부 위협은 무시한다는 것이었습니다. 그것은 이 문서의 논변이지 일반적인 보증이 아닙니다. 임의의 트래픽을 탈캡슐화할 수 있는 내부 프로세스는 바로 그 자체로 새로운 정책 판단 구성 요소입니다.

방화벽 운영자는 허용되는 외부 연결을 통제했습니다. 내부 호스트 운영자는 FEP가 실행되는지, 재구성된 데이터그램이 로컬 스택에 들어가는지를 통제했습니다. 사용자나 애플리케이션은 수요를 만들어냈습니다. 터널 구현은 필드를 어떻게 인코딩하고 재구성할지 결정했습니다. 이 어느 것도 조직이 그 결합된 동작을 승인했다는 사실을 증명하지 않습니다.

이 분리는 오해를 낳는 사고 서사도 막아 줍니다. HTTP 수용을 보여주는 로그는 내부에 실린 흐름의 로그가 아닙니다. 터널 종단점이 메시지를 수신했다는 기록은 패킷을 주입했다는 증거가 아닙니다. 주입은 로컬 소켓이 그것을 수용했다는 증거도, 애플리케이션이 처리했다는 증거도, 외부 효과가 발생했다는 증거도 아닙니다.

사람이 읽을 수 있는 복제본은 패킷의 권위가 아니었다

RFC 3093은 IP-over-MIME 아이디어를 사용해 완전한 IP 데이터그램을 HTTP 본문에 담았습니다. 또한 TCP 필드와 선택적으로 IP 필드를 새로운 사람이 읽을 수 있는 HTTP 헤더에 복사했습니다. 포트 번호는 10진수 문자열이 되었고, 긴급성은 대소문자에 영향을 주었으며, 홉 제한은 산문 문장이 되었고, 겉보기 주소는 도메인 이름이 될 수 있었습니다.

메모 자체가 인정했듯이, 완전한 데이터그램이 이미 본문에 있었기 때문에 이 복제본들은 엄격히 사람의 가독성을 위한 것이었습니다. 그래서 이것은 권위로 격상되어서는 안 되는, 데이터베이스 내보내기처럼 보이는 증거의 훌륭한 사례가 됩니다. 사람이 읽을 수 있는TCP_Dport문자열은 실제 수신지를 인증하지 않았습니다. 두 표현이 서로 어긋날 수 있었습니다. 어떤 기록이 재구성을 지배하는지는 오직 명시적인 구문 분석, 검증, 정책만이 결정할 수 있었습니다.

이 설계는 양방향에서 GET 요청 또는 GET 응답을 사용해 수용 가능한 HTTP처럼 보였습니다. 이는 통상적 의미에서 웹 자원을 요청하는 애플리케이션이 아니었습니다. HTTP 구문은 중개자가 인식할 수 있기 때문에 선택된 보이는 외피였을 뿐입니다. 방화벽이 익숙한 표면 형태만 검사할수록, 프로토콜 인식과 의도 인식은 서로 다른 과제라는 사실을 이 제안은 더 선명하게 보여주었습니다.

농담이 실제 정책 실패 양상을 기록했다

발행일과 기발한 필드, 그리고 실질적 보안 고려사항이 없다는 주장은 RFC 3093을 안전한 배치 가이드가 아니라 Informational 성격의 도발 문서로 위치시킵니다. 이 기사는 기록을 활용하기 위해 저자의 의도를 굳이 발명할 필요가 없습니다. 페이지 위의 메커니즘만으로 충분합니다. 종단점이 터널링에 동의할 준비가 되어 있다면, 성긴 허용 규칙은 일반적인 운반 수단이 될 수 있다는 것입니다.

인접한 작업들은 계층을 분리해 두었습니다. RFC 2775는 줄어드는 인터넷 투명성을 기술했고, RFC 2979는 방화벽 동작과 구성 가능한 정책을 논의했습니다. RFC 2663과 RFC 3027은 NAT의 복잡성을 문서화했고, RFC 3234는 나중에 미들박스의 더 넓은 부류를 명명했습니다. SOCKS5는 명시적 게이트웨이를 통한 협상과 선택적 인증 방식을 사용했습니다. 어느 것도 FEP가 실제 운영 환경에서 실행되었음을 증명하지 않습니다.

따라서 지속되는 교훈은 "방화벽은 무용하다"거나 "터널링이 승리한다"는 주장보다 좁습니다. 규칙은 HTTP 연결을 확실하게 허용하면서도 그 안에 실린 의미에 대해서는 침묵할 수 있습니다. 정책 집행을 주장하려면 운영자는 실제 결정 지점들을 식별해야 합니다. 인증된 터널 종단점, 허용 가능한 내부 프로토콜, 수신지, 재주입 권한, 애플리케이션 수용, 관찰 가능한 결과가 그것입니다. 외부 계층의 초록불 하나가 이 사슬 전체를 대신할 수는 없습니다.

방화벽이 허용한 것은 HTTP, 승인하지 않은 것은 내부 패킷: RFC 3093

왜 중요한가

요약