요약

  • 기존 HTTP CONNECT는 TCP 목적지를 지정하지만 프록시 서비스 자체의 출처와 경로는 지정하지 않는다. 새 방식은 URI 템플릿으로 서비스를 표시하고 Capsule 메시지로 바이트 흐름을 운반한다.
  • IESG는 10월 30일 초안을 Proposed Standard로 발행하도록 승인했다. 이를 지원하는 게이트웨이는 자신이 처리하는 HTTP 버전 사이에서 터널 요청을 변환해야 한다. 공개 기록에는 배포 규모나 현장 결과가 없다.

프록시는 주소를 얻었다. 게이트웨이에는 새 일이 생겼다.

HTTP CONNECT는 오래전부터 클라이언트가 프록시에 특정 호스트와 포트로 TCP 연결을 열어 달라고 요청하는 방법이었다. 프록시는 클라이언트와 목적지 사이에서 바이트를 전달한다. 하지만 요청이 가리키는 것은 터널의 도착지뿐이다. 어떤 프록시 서비스를 사용했는지 나타내는 고유한 출처나 경로는 없다.

하나의 HTTP 서버가 여러 프록시 서비스를 호스팅하면 이 구분이 중요해진다. 고유한 경로와 출처가 없으면 일반 웹 리소스나 가상 호스트처럼 서비스를 나눠 처리할 수 없다. 초안은 보안상 문제도 짚는다. 프록시 출처가 명시되지 않아 서버 포트 오인도 공격을 막는 보통의 방어가 맞지 않고, Alt-Svc나 Strict-Transport-Security 같은 출처 범위 응답 헤더의 적용 범위도 모호해진다.

10월 30일, IESG는 draft-ietf-httpbis-connect-tcp를 Proposed Standard로 발행하도록 승인했다. 제17판은 하루 앞서 나왔다. 이 초안은 HTTP로 TCP를 터널링하는 새 방식을 제시한다. 사용자가 어느 목적지에 연결할 수 있는지는 정하지 않는다. 프록시 서비스 주소는 명확해지지만, 접근 권한은 여전히 프록시 운영자가 정한다.

프록시 서비스는 target_host와 target_port 변수가 든 URI 템플릿으로 식별한다. 클라이언트는 목적지를 채워 넣은 URI를 프록시에 보낸다. HTTP/1.1에서는 GET 뒤에 connect-tcp로 Upgrade한다. HTTP/2와 HTTP/3에서는 :protocol이 connect-tcp인 Extended CONNECT를 쓴다. 프록시는 설정 정보로 Extended CONNECT 지원 여부를 알려야 한다.

TCP 흐름은 Capsule Protocol 메시지에 담긴다. DATA가 바이트를 옮기고, FINAL_DATA는 마지막 바이트와 TCP FIN에 해당하는 종료 신호를 전한다. 캡슐 경계는 TCP 세그먼트나 TLS 레코드 경계를 흉내 내지 않는다. HTTP를 통과하는 데이터 흐름을 포장하는 단위다.

출처와 경로가 생기면서 프록시 서비스도 일반 HTTP 의미 체계에 들어온다. 서버는 여러 서비스를 구분할 수 있고 출처 범위 헤더에도 명확한 기준이 생긴다. 하지만 허용 여부는 별개의 결정이다. 프록시는 여전히 목적지별 접근 규칙이 필요하다. URI 템플릿은 접근 통제 목록이 아니다.

이제 게이트웨이에 일이 남는다. 호환성을 내세우려면 HTTP/1.1 Upgrade 또는 Extended CONNECT를 처리하고, connect-tcp를 전달하며, 지원하는 HTTP 버전 사이에서 요청을 바꿔 줘야 한다. Proxy-Status도 통과시켜야 한다. 목적지 서버가 TLS 클라이언트 인증서를 요구한다면 게이트웨이가 직접 인증을 처리하거나 관련 인증서 정보를 서버에 전달해야 한다.

IETF는 이 인계 요건을 표준 문서에 적었다. 게이트웨이를 업그레이드해 주지는 않았다. 초안과 결정 기록에는 설치된 게이트웨이 수, 도입 전망, 운영 환경의 상호운용 시험 결과가 없다. 표준은 메시지 모양을 정한다. 운영팀은 경로에 걸린 모든 프록시, 게이트웨이, 인증 경계를 찾아야 한다.

출처