HTTP CONNECT: HTTP 프록시는 HTTPS를 어떻게 처리할까?

HTTPS 요청이 HTTP 프록시를 지나는 과정을 따라가며 CONNECT 응답과 원본 서버 응답을 구분하고 터널이 실패하는 지점을 찾습니다.

‘200 Connection Established’는 프록시가 터널을 수락했다는 뜻입니다. 웹사이트가 페이지를 반환한 것은 아닙니다. 다음으로 목적지와 TLS를 진행하고, 그 뒤에 실제 HTTPS 요청을 보냅니다.

프록시 연결에서 웹사이트 응답까지

  1. 클라이언트가 프록시 엔드포인트에 연결합니다.
  2. 프록시에 목적지 호스트와 포트로 연결해 달라고 요청합니다.
  3. 프록시가 그 요청을 수락하거나 거부합니다.
  4. 수락되면 클라이언트는 터널을 통해 목적지와 TLS를 협상합니다.
  5. 클라이언트가 TLS 안에서 HTTPS 요청을 보내고 웹사이트 응답을 받습니다.

프록시 연결 거부, 터널 거부, 인증서 오류는 이 순서의 서로 다른 지점에서 발생합니다. 설정을 바꾸기 전에 마지막으로 완료된 단계를 찾으세요.

CONNECT 요청과 응답

HTTP/1.1의 단순화한 교환은 다음과 같습니다.

CONNECT example.com:443 HTTP/1.1
Host: example.com:443

HTTP/1.1 200 Connection Established

요청 대상은 호스트와 포트이며 웹사이트의 경로나 쿼리는 포함하지 않습니다. CONNECT 응답이 성공하면 연결은 터널 바이트를 전달합니다. HTTPS 목적지라면 클라이언트의 다음 교환은 TLS 핸드셰이크입니다.

영어 이유 구문을 문자열로 맞추기보다 숫자 상태 코드를 읽으세요. 프록시마다 같은 상태에 다른 문구를 쓸 수 있습니다.

curl로 관찰하기

로컬 포트 8080의 HTTP 프록시라면:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

수신 주소를 자신의 엔드포인트로 바꾸세요. 후보가 필요하면 HTTP 프록시 목록을 살펴보고 선택한 항목을 시험합니다. 우회 목록이 비어 있으므로 이 호출에서는 프록시가 선택됩니다. 시간순으로 프록시 연결, CONNECT 응답, 목적지 인증서 검증, 웹사이트 응답을 찾으세요. 정확한 로그 문구는 curl 빌드에 따라 다릅니다.

프록시가 터널을 수락한 뒤에도 목적지는 404, 429, 500을 반환할 수 있습니다. HTTP 응답을 반환하기 전 TLS 단계에서 실패할 수도 있습니다.

어디에서 멈췄을까?

관찰 결과다음으로 조사할 항목
프록시 연결이 거부됨프록시 주소, 수신 포트, 프로세스, 네트워크 접근.
프록시가 407을 반환함프록시 계정과 인증 방식.
프록시가 목적지나 포트를 거부함접근 정책과 허용된 CONNECT 목적지.
터널이 열린 뒤 TLS 검증이 실패함목적지 이름, 신뢰 저장소, 시계, 관리형 TLS 가로채기 여부.
TLS가 성공하고 웹사이트가 오류를 반환함웹사이트의 응답.

비교할 때는 한쪽을 고정하세요. 같은 프록시로 다른 목적지를 시도하거나, 허용된 직접 경로로 같은 목적지를 비교합니다.

터널에도 여전히 운영자가 있다

프록시는 CONNECT 목적지를 알고 트래픽의 시점과 양을 처리합니다. 일반적인 종단 간 TLS는 해당 TLS 세션을 종료하지 않는 프록시로부터 웹사이트의 애플리케이션 내용을 보호합니다. 클라이언트가 신뢰하는 관리형 가로채기 프록시는 신뢰 관계가 다릅니다.

관련 글