Squid Proxy

회사에서 사용하는 Squid Proxy.
ACL을 통해 Forward Proxy 기능을 지원한다.

클라이언트-> Squid -> 외부(인터넷)

이런 식으로 구성되어 있다.

HTTP와 HTTPS

Forward Proxy는 요청받은 프로토콜이 HTTP냐, HTTPS냐에 따라 동작 방식이 다르다.

HTTP

GPT가 잘 정리해줘서 설명을 대체한다.

핵심은 클라이언트가 Squid로 전달하는 요청값 HTTP 헤더 시작이

GET http://example.com HTTP/1.1

의 형태를 띈다는 것이다.
그걸 받은 프록시는, 전달받은 값을 기준으로 웹서버에게 본인이 직접 HTTP를 요청하고
응답받은 값을 클라이언트에게 전달해주는 식이다.

와이어샤크에서 확인해보자.

지금 환경은 이런 IP 구성이다.

클라이언트(192.168.0.8) -> Squid(192.168.0.15) -> 외부(인터넷)

먼저, 클라이언트 - 프록시 간 프록시 연결을 맺는 부분이다.

그리고, 프록시가 웹서버에게 HTTP 통신하는 부분이다.

마지막으로, 웹서버에게 전달받은 HTTP 응답을 프록시가 클라이언트에게 전달하는 부분이다.
(처음에 맺은 프록시 연결을 통해서)

HTTPS

HTTPS 통신에서 프록시는 단순히 전달자 역할만 수행한다.
(HTTP에선 직접 HTTP 요청을 웹서버로 날렸지만)

SSL 핸드셰이크에 관여하지 않는다.
클라이언트 <-> 프록시, 프록시 <-> 웹서버 간 2개의 TCP 세션을 만들어놓고
클라이언트와 웹서버가 통신하는 걸 그대로 전달해줄 뿐이다.

그리고 이런 터널 구성을 위해 클라이언트는 처음에 프록시에게 다음 형태의 요청을 전달한다.

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

와이어샤크에서 확인해보자.

처음에 클라이언트(192.168.0.8)가 프록시(192.168.0.15)에게 터널링을 요청하는 부분이다.

프록시는 요청받은 www.naver.com을 DNS 룩업하고 443 포트로 TCP 세션을 맺는다.
세션이 맺어지면 클라이언트에게 웹서버와 연결되었음을 알린다. (HTTP/1.1 200 Connection established)

이제 클라이언트는 웹서버에게 직접 HTTPS 연결했을 때처럼, SSL 핸드셰이크 통신을 수행한다.
대상이 www.naver.com:443가 아닌 192.168.0.15:3128일 뿐이다.

아래 표시한 부분을 보면 클라이언트가 프록시에게 Client Hello를 전달하고 있고, 그걸 프록시는 www.naver.com(23.208.20.147)에게 그대로 전달하고 있다.

이후 과정도 동일하다.
SSL 핸드셰이크가 완료되면 암호화된 통신도 동일하게 프록시를 통해 전달된다.