HTTP Proxy
읽기에 앞서
본 문서는 HTTP Proxy에 대한 기본적인 지식이 이미 있다는 가정 하에 작성되었습니다. 독자 분께서는 Forward Proxy가 무엇인지, 어떤 곳에 쓰이는지 그리고 Tunneling이란 무엇인지 이미 알고 계시는 편이 읽기 수월하실 겁니다.
단순화를 위해 Forward Proxy, Reverse Proxy 그리고 Interceptive Proxy 등은 다루지 않습니다.
HTTP Proxy의 종류
아무래도 편의상 HTTP Proxy라 뭉둥그려 말하는 경우가 많지만, HTTP Proxy에는 크게 두 가지 구분이 존재합니다.
- HTTP Proxy
- HTTPS Proxy
TLS(SSL) Layer가 추가된 HTTP Proxy가 HTTPS Proxy입니다. 그리고 HTTPS Proxy도 곧 HTTP Proxy라고 이해하셔도 큰 무리는 없습니다.
다만 HTTP Protocol 그리고 TLS에 관해 생각해보면, HTTPS Proxy의 구현에 대해 의문을 품을 수 있습니다.
HTTPS Proxy
HTTPS Proxy는 엄연한 중간자이며, TLS Protocol은 중간자 공격을 예방하기 위한 기술입니다. TLS Handshake 과정에서 인증서를 검증하기 때문에 HTTPS Proxy는 TLS Handshake 과정을 마칠 수 없습니다.
그렇지만 사실 HTTP Proxy Protocol은 근본적으로 이러한 문제를 쉽게 해결할 수 있도록 고안되었습니다.
이름이 HTTP Proxy다 보니 많은 경우 착각하는 사실인데, HTTP Proxy는 HTTP Message만 전달해주는 Proxy가 아닙니다.
HTTP Proxy Protocol(HTTP Protoccol)에는 CONNECT Method가 있습니다. CONNECT Method는 목적지 서버와 프록시 서버가 TCP Tunnel을 수립하게끔 요청합니다. 일단 성공적으로 수립되면, 프록시 서버는 이후 수신하는 모든 Segment들을 중계합니다. 즉, OSI 4계층, Transport Layer에서 작동하는 TLS Protocol도 프록시 서버가 중계해 주기에 사용이 가능합니다.
하지만 그렇다면 HTTPS Proxy가 HTTP Proxy의 완전한 상위호환으로 보입니다. HTTP Proxy는 왜 존재하는 걸까요?
HTTP Proxy
CONNECT Method는 무척이나 강력한 기능이지만, 그만큼 안전을 위해 주의를 기울여야 할 기능입니다. 때문에 RFC 문서에서도 스팸 등에 활용될 것을 우려해 목표 포트에 제한을 두는 것을 제안하고 있습니다.
HTTP와 HTTPS는 주로 80, 443 포트에서 작동합니다. 이 둘만 화이트리스트에 넣어 제한하면 이외의 용도로는 사용하기 어려워집니다.
경우에 따라선 따로 설정을 해 두었거나, 애초에 CONNECT를 지원하지 않는 프록시 서버 등이 있습니다. 이러한 경우를 보통 HTTP Proxy, HTTPS를 지원하지 않는 프록시라고 합니다. 이들은 TCP Tunneling을 지원하지 않으며 TLS 없는 순수한 HTTP Message를 목표 서버에 전달하는 역할만을 맡습니다.
Proxy Chaining
Proxy Chain이란 Proxy들이 연쇄적으로 이어진 것을 말합니다. 위의 내용을 이해하셨다면, CONNECT 이후 TCP Tunnel이 수립되는 것을 이용해 Proxy Chain을 구성할 수 있다, 즉. HTTPS Proxy가 아닌 HTTP Proxy로는 Proxy Chain을 구성할 수 없다는 것을 이해하셨을 겁니다.
CONNECT를 사용할 수 있는 HTTPS Proxy는 해당 프록시 서버 너머로 TCP Tunnel 수립 이후 CONNECT 요청을 보낼 수 있지만, 사용하지 않는 경우 그 너머로 CONNECT 요청을 보낼 방법이 없으니까요.