HTTP 및 HTTPS 프록시

HTTP 프록시는 브라우저나 애플리케이션의 웹 요청을 받고 대신 목적지에 연결합니다. 일반 HTTP 트래픽을 전달하며 CONNECT 메서드를 지원하면 암호화된 HTTPS 트래픽도 전달할 수 있습니다. HTTPS 프록시는 애플리케이션과 프록시 자체 사이의 연결에도 암호화를 추가합니다.

애플리케이션이 프록시에 연결하는 방식과 그 프록시를 통해 웹사이트와 통신하는 방식은 별개의 선택입니다. 두 가지를 이해하면 올바른 접속 설정을 고를 수 있습니다. 프록시 프로토콜의 전반적인 비교는 SOCKS와 HTTP 프록시에서 다룹니다.

HTTP 프록시의 웹 요청 처리

모니터링 스크립트가 http://example.com/catalog를 요청한다고 가정해 보세요. 웹사이트에 직접 연결하는 대신 설정된 프록시에 연결합니다. HTTP/1.1에서는 프록시가 어느 서버의 어떤 페이지에 접속해야 하는지 알 수 있도록 전체 목적지 URL을 요청에 보냅니다. 프록시는 요청을 전달하고 웹사이트의 응답을 스크립트로 돌려줍니다.

이 모드에서 프록시는 HTTP 메시지를 처리합니다. GET이나 POST 같은 메서드, 요청 주소, 헤더, 제출 데이터를 읽을 수 있습니다. 목적에 맞게 설정된 소프트웨어는 접근 규칙을 적용하고 요청을 기록하거나 적합한 응답을 캐시할 수 있습니다. 캐시는 응답의 캐싱 규칙을 따르는 선택 기능입니다. HTTP 프록시 접속을 구매했다고 모든 페이지가 캐시되는 것은 아닙니다.

웹사이트는 프록시 출구 IP에서 네트워크 연결을 받습니다. HTTP라는 용어는 IP의 출처나 할당 유지 기간을 나타내지 않습니다. 같은 접속 프로토콜을 데이터센터, ISP, 주거용, 모바일 주소와 함께 고정 IP 또는 순환 풀 방식으로 제공할 수 있습니다.

HTTP 프록시로 HTTPS 웹사이트를 여는 방식

HTTPS 웹사이트는 TLS로 애플리케이션과 웹사이트 사이의 통신을 보호합니다. HTTP 프록시는 이 통신을 전달하기 위해 먼저 터널을 만듭니다. https://example.com/catalog 요청의 순서는 다음과 같습니다.

1. 애플리케이션이 프록시에 연결하여 example.com:443에 터널을 열도록 요청하며, 이때 CONNECT 메서드를 사용합니다. 요청에는 페이지 경로 없이 목적지 호스트와 포트를 명시합니다.
2. 프록시는 필요한 프록시 인증을 포함하여 접속과 요청한 목적지가 허용되는지 확인합니다. 목적지에 연결하고 터널이 준비되었음을 알립니다.
3. 애플리케이션은 터널을 통해 웹사이트와 TLS 핸드셰이크를 수행하고 웹사이트의 인증서를 검사합니다.
4. 애플리케이션은 해당 TLS 연결 안에서 웹 요청을 보냅니다. 프록시는 암호화된 바이트를 양방향으로 전달합니다.

프록시는 페이지를 전달하기 위해 읽을 필요가 없습니다. 웹사이트 TLS 연결의 양 끝은 애플리케이션과 웹사이트로 유지됩니다. CONNECT는 터널을 제공하고, TLS는 암호화와 함께 통신이 탐지되지 않은 채 변조되는 것을 방지합니다.

따라서 프록시 주소가 http://로 시작해도 HTTP 프록시로 HTTPS 웹사이트를 열 수 있습니다. 웹사이트의 HTTPS 보호는 터널 안에서 작동하며, 애플리케이션과 프록시 사이에 TLS가 있어야 하는 것은 아닙니다.

HTTPS 프록시가 추가하는 보호

HTTPS 프록시에서는 애플리케이션이 먼저 프록시와 TLS를 설정하고 프록시 인증서를 검증합니다. 이후 보호된 연결 안에서 HTTP 요청이나 터널용 CONNECT 요청을 보냅니다. 애플리케이션과 프록시 사이의 네트워크 관찰자는 그 요청을 읽을 수 없습니다.

HTTPS 목적지에서는 애플리케이션이 별도의 TLS 연결 두 개를 유지합니다. 하나는 프록시와의 연결이고 다른 하나는 터널을 통과하는 웹사이트와의 연결입니다. 프록시는 자신에게 전달된 바깥 보호를 해제하지만 안의 웹사이트 데이터는 암호화된 채로 남습니다. 프록시는 이를 복호화할 수 있는 웹사이트로 전달합니다. HTTP 목적지에는 내부 TLS 연결이 없으며 프록시까지의 연결만 보호됩니다.

이 비교는 인증서 검사를 활성화한 일반 프록시 전달을 설명하며 HTTPS 검사나 별도의 VPN은 포함하지 않습니다. 프록시 연결을 암호화해도 HTTP 웹사이트가 HTTPS로 바뀌지는 않습니다.

프록시와 웹사이트가 볼 수 있는 정보

HTTPS 목적지에서는 전달 프록시가 TLS 연결 안의 페이지 경로, 쿼리 매개변수, 쿠키, 양식 데이터, 반환 콘텐츠를 읽을 수 없습니다. 다만 연결한 클라이언트 IP, CONNECT에서 요청한 목적지 호스트와 포트, 트래픽의 시간과 양은 알 수 있습니다. 프록시까지의 TLS는 그 구간의 관찰자로부터 CONNECT를 숨기지만, 요청을 처리해야 하는 프록시 자체에는 숨기지 않습니다.

프록시 인증 정보는 웹사이트 로그인과 별도로 전송됩니다. Basic 프록시 인증은 사용자 이름과 비밀번호를 Base64로 인코딩하며, 비밀 키 없이 디코딩할 수 있습니다. 평문 HTTP 프록시 연결에서는 네트워크 관찰자로부터 이를 보호하지 못합니다. 웹사이트의 HTTPS 연결은 터널 안에서 시작하므로 앞서 전송한 프록시 로그인을 보호하지 않습니다. 프록시까지 TLS를 사용하면 전송 중의 로그인을 보호할 수 있습니다.

반대편에서 웹사이트는 출구 IP의 트래픽을 받고 자신에게 전달된 요청을 읽습니다. 애플리케이션이 보낸 계정, 세션 쿠키, 기타 정보를 식별할 수 있습니다. HTTPS 프록시를 선택해도 이런 식별자가 사라지거나 웹사이트가 출구 IP를 자동으로 더 잘 받아들이지는 않습니다.

HTTPS 검사는 일부 관리 네트워크와 디버깅 도구에서 사용하는 별도의 구성입니다. 애플리케이션이 검사 프록시가 통제하는 인증 기관을 신뢰하면, 프록시는 양쪽에 별도의 TLS 연결을 유지하면서 트래픽을 읽을 수 있습니다. 일반 CONNECT 전달에는 이런 인증서를 설치할 필요가 없습니다. HTTPS 프록시 자체의 서버 인증서를 신뢰하는 것과 웹사이트를 대신할 권한을 주는 것은 별개입니다.

접속 설정을 읽는 방법

프록시 설정에는 주소, 포트, 접속 프로토콜과 필요한 인증이 들어갑니다. 프록시 URL의 프로토콜은 프록시에 적용되고, 목적지 URL의 프로토콜은 웹사이트에 적용됩니다.

다음 curl 명령은 서로 다른 프록시 연결 두 가지로 같은 HTTPS 웹사이트를 요청합니다. 프록시 호스트명과 포트는 선택한 접속 방식에 제공된 값으로 바꾸세요.

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

첫 명령은 HTTP로 프록시에 연결한 뒤 웹사이트까지 CONNECT와 TLS를 설정합니다. 두 번째 명령은 먼저 HTTPS 프록시까지 TLS를 설정하고 그 안으로 웹사이트의 별도 TLS 연결을 전달합니다. 두 경우 모두 프록시 서비스에서 요구하는 인증 정보도 제공하세요.

단순히 http://를 https://로 바꾼다고 HTTP 전용 포트가 TLS 엔드포인트로 바뀌지는 않습니다. 서비스가 HTTPS 접속용 호스트명을 제공한다면 그 호스트명을 사용하세요. IP로 바꾸면 인증서 이름 불일치가 발생할 수 있습니다.

애플리케이션의 항목 이름도 주의해서 읽어야 합니다. “HTTPS proxy”라는 입력란은 평문 HTTP로 프록시에 연결하면서 HTTPS 웹사이트용 프록시를 선택하는 항목일 수 있습니다. curl의 HTTPS_PROXY 변수도 HTTPS 목적지용 프록시를 선택하므로 값이 http://로 시작해도 올바를 수 있습니다. 항목 이름은 어떤 요청에 설정이 적용되는지를, 프록시 스킴은 연결 방식을 알려 줍니다.

DNS와 프록시를 통과하는 트래픽

HTTP 클라이언트가 목적지 호스트명을 전달하면 보통 프록시가 IP를 조회하여 연결합니다. 클라이언트는 프록시 자체의 호스트명으로 접속해야 한다면 별도로 조회합니다. 브라우저도 예측이나 다른 기능을 위해 DNS 질의를 할 수 있습니다. 서로 다른 조회이므로 웹 프록시 설정만으로 모든 DNS 요청이 프록시를 통과하지는 않습니다.

설정은 애플리케이션이 실제로 프록시에 보내는 트래픽에 적용됩니다. 다른 프로그램은 직접 연결을 계속할 수 있고, 예외 목록에 지정된 사이트는 프록시를 우회할 수 있습니다. 예를 들어 API 스크립트를 프록시로 보낸다고 관련 없는 브라우저의 경로가 바뀌지는 않습니다. 실제 작업을 수행할 애플리케이션과 설정에서 출구 주소를 확인하세요.

웹사이트까지의 HTTP/2와 프록시까지의 HTTP/2

HTTP/2는 별도 스트림을 사용해 여러 통신이 연결 하나를 공유하게 합니다. 프록시에서는 어느 연결이 이를 지원하는지가 중요합니다. 애플리케이션은 HTTP/1.1 CONNECT로 만든 터널 안에서 웹사이트와 HTTP/2를 협상할 수 있습니다. 프록시는 암호화된 바이트를 전달하므로 웹사이트의 HTTP/2 메시지를 이해할 필요가 없습니다.

애플리케이션과 프록시 사이의 HTTP/2는 별도 기능입니다. 각 CONNECT 터널이 자체 HTTP/2 스트림을 사용하므로 여러 터널이 프록시 연결 하나를 공유할 수 있습니다. 예를 들어 서로 다른 웹사이트 두 곳의 터널이 이 연결을 사용하면서 목적지 연결과 웹사이트 TLS 세션은 각각 유지할 수 있습니다. 클라이언트와 프록시 사이의 추가 연결 필요성을 줄이지만 프록시가 암호화된 웹 요청을 읽을 수 있게 하지는 않습니다.

양쪽 모두 선택한 모드를 지원해야 합니다. HTTPS만으로 HTTP/2를 뜻하지는 않으며 HTTPS 프록시도 HTTP/1.1을 사용할 수 있습니다. 성능은 클라이언트, 네트워크 경로, 서버 부하, 연결 재사용에도 달려 있습니다. HTTP/2라는 표시가 모든 작업의 속도 향상을 보장하지는 않습니다.

일반 CONNECT 터널은 애플리케이션과 프록시가 허용하면 다른 TCP 기반 프로토콜도 전달할 수 있지만 목적지 포트가 제한될 수 있습니다. UDP는 전달하지 않습니다. HTTP/3는 UDP 위의 QUIC를 사용하므로 같은 방식으로 이 TCP 터널을 통과할 수 없습니다. HTTP 기반 UDP 전달에는 CONNECT-UDP 같은 추가 메커니즘과 호환 구현이 필요합니다. HTTPS나 HTTP/2 지원만으로 이 기능의 지원이 확인되지는 않습니다.

HTTP 및 HTTPS 프록시가 유용한 상황

브라우징과 웹사이트 테스트에서는 CONNECT가 있는 HTTP 프록시가 HTTP 및 HTTPS 목적지에 하나의 접속 방식을 제공합니다. 팀은 이를 통해 프록시 네트워크에서 사이트를 확인하고, 페이지 렌더링, 쿠키, 웹사이트 로그인은 브라우저가 담당하게 할 수 있습니다.

크롤러, API 클라이언트, 예약 모니터에서는 목적지 URL을 바꾸지 않고 HTTP 클라이언트가 선택한 출구 IP로 요청을 보낼 수 있습니다. 요청 준비와 응답 처리는 여전히 애플리케이션이 담당합니다. HTTPS 터널 안에서 프록시는 각 페이지나 API 호출을 파싱하지 않고 통신을 전달합니다.

TLS로 보호되는 HTTPS 프록시는 프록시 로그인과 목적지 요청을 포함하여 프록시까지의 연결도 보호해야 할 때 유용합니다. 그 연결이 직접 통제하지 않는 네트워크를 통과할 때 중요합니다. 클라이언트는 프록시 자체까지의 TLS를 지원해야 합니다. HTTPS 웹사이트를 열 수 있다는 것만으로는 충분하지 않습니다.

연결 오류의 해석

실패는 프록시 도달, 터널 개설, 웹사이트 통신 중 발생할 수 있습니다. 오류 코드만 보는 것보다 발생 단계가 더 많은 정보를 줍니다.

터널과 TLS 핸드셰이크가 완료되었다면 연결 경로가 작동함을 보여 줍니다. 웹사이트가 특정 계정, 출구 IP, 요청을 허용한다는 보장은 아닙니다. 따라서 프록시가 정상이어도 로그인 추가 확인, CAPTCHA, 요청 한도는 웹사이트나 애플리케이션 수준에서 살펴봐야 할 수 있습니다.