Proxy ( Forward proxy, Reverse proxy )와 Client-Proxy MitM(Man-in-the-middle)
Proxy = 대신/대리
네트워크에서 proxy는 client나 server를 대신하여/대리하여 요청을 전달한다.
물리적인 위치는 사용자의 컴퓨터일 수도 있고
사용자의 컴퓨터 - 목적지 중간의 한 지점일 수 있다.
왜 대신하는가?
캐싱
자주 요청되는 리소스 or 자주 변하지 않는 리소스의 경우
proxy 서버에 리소스를 저장할 수 있다.
- (본 목적지까지 전달했던) network hop을 줄일 수 있다.
- 리소스가 캐싱된 스토리지에 따라 더 빠른 응답 시간를 얻을 수 있다.
보안
내부망과 인터넷이 소통하는 지점인 게이트웨이로서 작동.
로그
물리적인 서버, 또는 로컬 컴퓨터에 쌓인 기록을 바탕으로
보안 정책을 구성할 수 있음.
우회
보안과 공통적인 면이 있다.
자신의 실제 IP가 아닌 프록시가 대신 요청을 수행하고
응답을 대신 받아서 본인에게로 전송해준다.
목적 리소스가 있는 컴퓨터에서는 프록시가 요청을 수행한 것으로 인식하고
프록시에게 응답을 돌려준다.
Forward proxy 대 Reverse proxy
Forward proxy(= gateway, proxy)
1. 클라이언트, 클라이언트 풀에서 나가는 요청에 대한 제어 수행.
클라이언트는 요청의 출발지 주소를 프록시 주소로 대신 사용함으로서
클라이언트의 원 정보를 숨길 수 있으며 우회 기능을 사용할 수 있음.
ex) Tor의 여러 프록시 서버 노드를 경유하는 proxy chaining
요청에 대한 들어오는 응답에 대한 제어 또한 수행하며
클라이언트 풀의 각각의 클라이언트에게 응답을 돌려준다.
2. HTTP 터널링을 통한 암호화
프록시 서버가 클라이언트 대신 인터넷을 연결한다.
TLS를 지원하는 웹 서버에 proxy 서버를 사용하여 연결한다.
(http1.1부터 connect method로 TLS tunnel을 사용할 수 있음)
connect method가 평문 형태의 http proxy를
ssl 암호화된 요청을 tcp/ip 터널로 전환한다.
- client가 http proxy 서버에게 tcp connection을 목적지까지 forward하기를 요청한다.
- http proxy 서버는 client 대신 목적지와 연결을 수립한다.
- 연결이 수립되면 client의 TCP byte stream을 proxy하여 전달한다.
- client, proxy와의 첫 연결 요청만 HTTP를 사용하고
그 후 부터는 수립된 TCP Connection을 프록시하기만 한다.
그 후 부터는 수립된 TCP Connection을 프록시하기만 한다.
이 경우, 클라이언트가 조회할 수 있는 인증서는 (암호화 통신을 위한)
proxy가 아니라 목적지 서버의 것이 맞다.
proxy 서버가 별도로 서버의 인증서를 본인의 인증서로 교체해서 연결을 수립하는 것이 아님.
3. ( client-proxy sever ) - Internet - ( server area )의 구조.
Reverse proxy
서버로 들어오는 요청에 대한 제어 수행.
서버에 대한 정보를 숨길 수 있음.
1. 비즈니스 서비스 측면에서의 로드 밸런싱
부하를 여러 수평 확장된 여러 웹 서버로 분산하거나,
용도에 맞는 MSA 서비스로 분산할 수 있음.
만약 로그인/인증이 필요한 서비스를 요청하는 패킷이 도달했는데
종단간 인증을 위한 데이터가 비어있다면(세션 키나 JWT 같은)
로그인 서버로 라우팅 할 수 있음.
2. 보안
1의 종단간 인증도 보안의 한 측면에 속한다.
기업에서는 외부망과 내부망을 분리하여
대외 서비스 영역인 공인망 대역(=DMZ)에서 인터넷과 통신해야함.
Reverse proxy가 게이트웨이 역할을 함.
또한, reverse proxy가 client에 인증서를 제공하여
클라이언트로 하여금 SSL 핸드셰이크를 통해 HTTPS 프로토콜로 데이터를 암호화 하게 할 수 있다.
키 유도가 완료되고 Master Secret 교환이 끝나면
데이터 전송이 시작된다.
( client area) - Internet - ( reverse proxy - 내부망 server)의 구조.
Client-Proxy 간 MitM(Man-in-the-middle)
어떤 조직들은 가짜 인증서를 생성함으로서 full MitM을 실현한다.
proxy서버에서 자체적으로 평문을 검사하고 평문에서 조직의 보안 정책에 맞는 로직을 수행한다.
ex) 안티바이러스 스캐닝
이를 위해서는 client 브라우저가 가짜 인증서를 진짜로 인식해야하며
대신 client 컴퓨터에 specia-organization-controlled 루트 ca가 저장돼야함.
(Windows/Active directory에서는 GPO, Group policy objects가 그 역할을 대신함)
모든 방화벽/프록시 제품을 공급하는 벤더에서 이 MitM 정책을 옵션으로만 제공하고 있는데
아래와 같은 단점들이 그 이유다.
- 벤더의 라이센싱 비용
- 암/복호화, 내용 검사 등의 추가적인 작업에 CPU 자원 소모 ( 내용물 검사를 하지 않으면 의미없음 )
- BYOD환경에서는 자동으로 root CA를 사용자 기기에 push하는 것이
작동하지 않음. (Bring your own device 정책) // 최하단 링크 참고
- MitM에서는 인증서 기반 클라이언트 인증 체계를 사용할 수 없음.
- 그리고 무엇보다 사용자들이 MitM을 꺼린다고 한다.
댓글
댓글 쓰기