12. Proxy

12. Proxy

웹 중개자

• Web Proxy Server는 중개자다.
• Proxy는 클라이언트이면서 웹 서버이다.
• Proxy의 좋은 서비스를 제공 받을 수 있다.
• 클라이언트와 서버 사이에서 HTTP의 메시지를 정리하는 중개인 처럼 동작한다.

Public Proxy

• 대부분의 Proxy는 공용 프락시이다.
• 이용하는 사용자가 많을 수록 좋다.
  • 공통된 요청에서 이득을 취해 비용효율이 올라가기 때문

Personal Proxy

• 흔하진 않다.
• 클라이언트에서 직접 실행시키는 형태로 주로 사용된다.
  • 브라우저 확장프로그램 or 성능 개선 or 무료 ISP를 위한 광고운영 등

Proxy vs GateWay

• Proxy
  • 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결
• GateWay
  • 다른 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결
  • 프로토콜 변환기 같은 역할

• 이 둘의 차이는 생각보다 모호하다.
  • 클라이언트와 서버는 다른 버전의 HTTP를 구현하기 때문에, Proxy는 프로토콜 변환을 하기도 한다.
  • 상용 프락시 서버의 경우 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근 등을 지웒가 위해 게이트웨이 기능을 구현하기도 한다.

---

Proxy는 왜 사용하는가?

• 보안 개선, 성능 향상, 비용 절약 등 유용한 것이라면 무엇이든 한다.

컨텐츠 필터링

ex) 교육사이트는 제공, 성인 컨텐츠는 차단

문서 접근 제어자

• 수많은 웹 서버에 대한 접근을 제어 할 수 있다.

• 똑똑한 사용자들이 고의적으로 Proxy를 우회하는 것을 방지하기 위해 Proxy의 요청만 받도록 설정도 가능

  ex) 일반적인 뉴스 접근 O, 인터넷 컨텐츠 접근 O, 보안 재무 데이터 접근 X

보안 방화벽

• 보안을 강화하기 위해 프락시를 사용

웹 캐시

• 자주 사용하는 문서에 대한 로컬 사본을 관리하고 요청이 오면 빠르게 제공
• 클라이언트 3, 4는 원 서버의 문서에 접근
• 클라이언트 1, 2는 웹 캐시에서 문서를 접근

대리 프락시 ( 리버스 프락시 )

• 진짜 웹 서버의 요청을 받지만, 웹 서버와 달리 요청받은 컨텐츠의 위치를 찾아내기 위해 사용한다.
• 느린 웹서버에 대한 성능 개선을 위해 사용 가능 ( 서버 가속기라고도 부름 )
• 컨텐츠 라우팅 기능과 결합되어 주문형 복제 컨텐츠의 분산 네트워크를 만들기 위해 사용 가능

컨텐츠 라우터

• 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 특정 웹 서버로 유도하는 라우터로 동작 할 수 있다.

  • 라우터

    → 네트워크의 경로를 설정해 데이터를 전달(할당) 해주는 장치

트랜스코더

• 컨텐츠를 클라이언트에게 전달하기 전에 본문 포맷(zip, z7, pdf, jpeg, png, 등)을 자유롭게 변환하는 것.

  ex) 크기를 줄이기위해 GIF → JPG로 변환, 텍스트 파일 압축

  ex) 한국어 텍스트를 스페인어 테스트로 변환

  ex ) … 등

익명화 Proxy

• HTTP 메시지에서 신원을 확인 할 수 있는 헤더들을 제거하는 용도로 개인정보 보호, 익명성 보호에 기여한다.

• 하지만, 신원 정보를 너무 제거하면 사용자의 편의성이 줄어들 수 있고, 적절히 동작하지 않을 수도 있다.

  ex) OS정보 삭제, Cookie정보 삭제, Referer헤더 삭제, 등

---

Proxy는 어디에 있는가?

• 어떻게 사용하는지에 따라서 Proxy는 어디에든 배치 할 수 있다.

Proxy 서버 배치

• 출구(Egress) Proxy

  • 로컬 네티워크 출구에 박아 넣는 Proxy

    ex) 성인컨텐츠 차단, 회사 밖의 악의적인 해커들을 막는 방화벽, 등

![스크린샷 2023-06-27 오후 1 33 06](https://github.com/SubiYoon/SubiYoon.github.io/assets/117332903/fa2c1236-9ce8-4cac-b185-1dfa62440cb7)

• 접근(입구) Proxy

  • 고객으로 부터의 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치하기도 한다.

    ex) 다운로드 속도 개선(고속 인터넷 사용자를 위한), 캐시 Proxy 등

![스크린샷 2023-06-27 오후 1 33 24](https://github.com/SubiYoon/SubiYoon.github.io/assets/117332903/c0e26da2-b09e-49e3-bba8-f0377c6e143c)

• 대리 Proxy

  • 네트워크에 가장 끝에있는 웹 서버들의 바로 앞에 위치하기도 한다.

  • 웹 서버로 향하는 모든 요청을 처리하고 필요시에만 웹 서버에게 자원을 요청할 수 있다.

  • 웹 서버의 보안기능 추가 or 빠른 웹 서버 캐시의 위치를 느린 웹 서버의 앞에 놓음으로써 성능 개선 가능

  • 일반적으로 웹 서버의 이름과 IP주소로 스스로를 가장하기에 모든 요청은 서버가 아닌 Proxy로 가게 된다.

    

• 네트워크 교환 Proxy

  • 캐시를 이요해 인터넷 혼잡을 완화 및 트래픽 흐름을 감시하기 위해 충분한 처리 능력을 갖춘 Proxy가 네트워크 사이의 인터넷 피어링 교환 지점에 위치할 수 있다.

    • 피어링

      → 인터넷 서비스 제공자끼리 서로 네트워크를 연결하고 트래픽을 교환하는 것을 의미

Proxy 계층

• Proxy는 계층 구조를 자식 Proxy와 부모 Proxy로 구성하여 만들 수 있다.

  • 자식 Proxy

    → 클라이언트쪽의 Proxy

  • 부모 Proxy

    → 서버쪽의 Proxy

• 최종적으로 Origin 서버에 도착할 때 까지 Proxy들을 거친다.

• 정적으로도 동적으로도 Proxy를 구성 할 수 있다.

  • 정적

    

  • 동적

    • 하나의 부모에게만 요청하지 않는다.

      

• 동적 부모 선택 예시

  • 부하균형

    → 부하를 최소한으로 하기 위해 부모의 작업량 수준을 고려하여 부모를 선택한다.

  • 지리적 인접성에 근거한 라우팅

    → 원 서버의 지역을 담당하는 부모를 선택

  • 프로토콜/타입 라우팅

    → URI에 근거하여 라우팅 할 수 있다.

    → 특별한 프로토콜로 처리될 수도 있다.

  • 유료 서비스 가입자를 위한 라우팅

    → 추가금을 지원했다면, 특정 서버나 특정 Proxy로 라우팅 될 수 있다.

Proxy가 트래픽을 처리하는 방법

• 클라이언트 수정

  

  • 다양한 회사의 브라우저를 포함한 많은 웹 클라이언트들은 수동 혹은 자동 Proxy 설정을 지원한다.
  • 클라이언트가 Proxy를 사용하도록 설정하면, 클라이언트는 요청을 오리진 서버가 아닌 Proxy로 보낸다.

• 네트워크 수정

  

  • 클라이언트 모르게, 네트워크 인프라를 가로채서 웹 트래픽을 Proxy로 가도록 조정하는 방법들이 있다.
  • 이러한 인터셉트는 일반적으로 HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 Proxy로 보내는 스위칭 장치와 라우팅 장치를 필요로 한다.
  • 이러한 Proxy를 인터셉트 프록시(intercepting proxy)라고 부른다.

• DNS이름을 수정

  

  • 웹 서버 앞에 위치하는 Proxy 서버인 대리 Proxy는 웹 서버의 이름과 IP 주소를 자신이 직접 사용하여 모든 요청을 서버 대신 대리 Proxy로 가도록 할 수 있다.
  • 이는 DNS 이름 테이블을 수동으로 편집하거나 사용할 적절한 Proxy나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정될 수 있음

• Web Server를 수정

  

  • 몇몇 웹서버는 HTTP 리다이렉션 명령(응답코드 305)을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 Proxy로 리다이렉트 하도록 설정할 수 있음
  • 리다이렉트를 받는 즉시 클라이언트는 Proxy와 트랜잭션을 시작함

---

클라이언트 Proxy 설정

• 수동 설정
  • Proxy를 사용하겠다 명시적으로 설정
• 브라우저 기본 설정
  • 브라우저를 소비자에게 전달하기 전에 Proxy를 미리 설정해 놓을 수 있다.
• 프락시 자동 설정
  • JavaScript Proxy 자동 설정(PAC) 파일에 대한 URI를 제공할 수 있다.
  • Proxy를 사용 여부와 어떤 Proxy Server를 써야하는지 판단하기 위해 JavaScript파일을 가져와 실행
  • PAC파일은 .pac확장자를 갖으며 application/x-ns-proxy-autoconfig의 MIME타입을 갖는다.
  • PAC파일은 반드시 Proxy서버를 계산해주는 FindProxyForUrl(url, host)함수를 정의해야 한다.
    • FindProxyForUrl(url, host)함수 반환값

        | 반환값 | 설명 |
        | --- | --- |
        | DIRECT | 프락시 없이 연결이 직접 이루어져야 한다. |
        | PROXY host:port | 지정한 프락시를 사용해야 한다. |
        | SOCKS host:port | 지정한 SOCKS 서버를 사용해야 한다. |

```jsx
//프락시 자동설정 파일 예시
function FindProxyForURL(url, host){
  if(url.substring(0,5) == "http:"){
    return "PROXY http-proxy.mydomain.com:8080";
  }else if(url.substring(0,4) == "ftp:"){
    return "PROXY ftp-proxy.mydomain.com:8080";
  }else {
    return "DIRECT";
  }
}
```

• WPAD Proxy 발견

  • 대부분의 브라우저는 웹 프락시 자동발견 프로토콜을 제공한다(WPAD)

    • 웹 프락시 자동발견 프로토콜

      → 브라우저에게 알맞음 PAC파일을 자동으로 찾아주는 알고리즘

  • WPAD가 구현된 클라이언트가 하게 되는 일

    1. PAC URI를 찾기 위해 WPAD를 사용
    2. 주어진 URI에서 PAC파일을 가져옴
    3. Proxy 서버를 알아내기 위해 PAC파일을 실행
    4. 알아낸 Proxy 서버를 이용해 요청을 처리

  • 올바른 PAC파일을 알아내기 위해 일련의 리소스 발견 기법을 사용하여 성공할 때까지 시도한다.

    • 현재의 WPAD명세는 다음의 기법을 순서대로 정의
      1. 동적 호스트 발견 규약(DHCP)
      2. 서비스 위치 규약(SLP)
      3. DNS 잘 알려진 호스트 명
      4. DNS SRV 레코드
      5. DNS TXT 레코드 안의 서비스 URI

---

Proxy Request의 미묘한 특징들

Proxy URI와 Sever URI의 차이점

• Sever의 경우

    GET /index.html HTTP/1.0
    USER-Agent: SuperBrowserv1.3

• Proxy의 경우

    GET http://www.domain.com/index.html HTTP/1.0
    USER-Agent: SuperBrowserv1.3

• Proxy 기반의 GateWay는 FTP 리소스 혹은 그 외의 스킴과 연결하기 위해 URI스킴을 알 필요가 있다.

• 클라이언트가 Proxy를 사용하지 않도록 설정되어 있다면 부분 URI를 보낸다.

  

• 클라이언트가 Proxy를 사용하도록 설정되어 있다면 완전한 URI를 보낸다.

  

가상 호스팅에서 일어나는 문제

• 가상 호스팅은 여러 웹사이트가 같은 물리적 웹 서버를 공유하는데, 부분 URI 요청이 오면 가상 호스팅은 웹 사이트의 호스트명을 알아야하기 때문에 문제가 발생한다.
  • 명시적인 Proxy는 완전한 URI를 갖음으로써 이것이 해결되었다.
  • 가상 호스팅되는 웹 서버는 호스트와 포트에 대한 정보가 담겨있는 Host 헤더를 요구한다.

인터셉터 Proxy의 부분 URI허용

• 인터셉터 Proxy

  → 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 하는 Proxy

• 명시적으로 Proxy를 설정하지 않는한, 클라이언트는 Proxy와 대화하고 있음을 항상 알고 있는 것은 아니다.

• 대리 Proxy나 인터셉터 Proxy의 경우 완전한 URI가 아닌 부분 URI를 보낼 것이다.

Proxy는 Proxy요청과 Server요청 모두 다룰 수 있다.

• 다목적 Proxy Server는 요청 메시지의 완전한 URI와 부분 URI를 모두 지원해야 한다.
  • 명시적인 요청에 대해서는 완전한 URI, 아닌경우 부분 URI, 웹 서버 요청의 경우 가상 Host 헤더를 사용
• URI 사용 규칙
  1. 완전한 URI가 주어졌다면, Proxy는 그것을 사용해야 한다.
  2. 부분 URI가 주어졌고 Host헤더가 있다면, Host 헤더에서 원 서버의 이름과 포트번호를 알아내야 한다.
  3. 부분 URI가 주어졌고 Host헤더가 없다면??
     1. Proxy가 대리 Proxy라면 Proxy에 실제 서버의 주소와 포트번호가 설정되어 있을 수 있다.
     2. 이전에 인터셉터 Proxy가 있었고 원 IP 주소와 포트번호를 사용하도록 해두었다면, 사용하면 된다.
     3. 모두 실패시, Proxy는 원 서버를 가르키지 못하므로 에러 메시지를 반환해야 한다.

전송 중 URI 변경

• Proxy Server는 요청 URI의 변경으로 인한 다운스트림 서버와 상호운용성 문제로 매우 신경을 써야 한다.
• 일반적으로 Proxy Server는 가능한 한 관대하도록 애써야 한다.
• 인터셉트 Proxy가 URI를 전달할 때 절대 경로를 쓰는 것을 금지한다.
  • 예외 → 빈 경로 ‘ / ‘로 교체하는 것 뿐

URI 클라이언트 자동확장과 호스트 명 분석(HOstname Resolution)

• 브라우저는 Proxy의 존재 여부에 따라 요청 URI를 다르게 분석한다.

• 주소창에 Yahoo만 적어도 www.Yahoo.com 으로 이동

• 몇몇 브라우저는 해석할 수 없는 URI를 서드파티로 넘겨 오타교정을 시도 후 사용자가 원한 URI를 제시한다.

• DNS는 사용자가 호스트 명의 앞부분만 입력하면 자동으로 도메인을 검색하도록 설정되어 있따.

  ex) oreilly.com이라는 도메인이 있을 때, ‘host7’을 입력하면 host7.oreilly.com을 찾아 본다.

Proxy없는 URI 분석(URI Resolution)

명시적인 Proxy를 사용할 때의 URI분석

• 브라우저는 명시적인 Proxy가 있는 경우 부분 호스트 명을 자동확장하지 않는다.
  • 브라우저는 스킴과 경로를 추가하지만 호스트명은 입력한 대로 남겨둠
• 이러한 이유로 몇몇 Proxy는 자동확장 or 지역 도메인 접미사 추가와 같은 것을 최대한 흉내내려고 시도한다.

인터셉트 Proxy를 이용한 URI분석

• 클라이언트 입장에서 Proxy는 존재하지 않는 것이기에 동작은 Proxy가 아닌 Server의 경우와 차이가 없다.
• 인터셉트 Proxy를 사용하고 있는 브라우저는 죽은 서버의 IP 주소를 탐지 할 수 없다.

• 진행 단계

  (1)

  → URI위에 창에 oreilly라고 타이핑

  (2a)

  → 브라우저는 oreilly를 DNS를 통해 찾아본다.

  (2b)

  → DNS 서버는 실패하고 그 호스트는 알 수 없다고 응답한다.

  (3a)

  → www.oreilly.com로 자동확장 된다.

  (3b)

  → 브라우저는 DNS에서 www.oreilly.com을 찾아본다.

  (3c)

  → 검색이 완료되어 해당 IP를 클라이언트에게 반환한다.

  (4a)(4b)

  → 클라이언트는 성공할 때까지 모든 IP주소에 대해 접속을 시도하지만, 어떤 IP는 죽은 것일 수도 있다.

  → 이때, 인터셉트 Proxy를 사용하는 브라우저는 Proxy Server에 의해 종료된다.

  (5a)

  → 클라이언트는 서버와 통신했다고 생각하지만, WebServer는 살아있지도 않았을 것이다.

  (5b)

  → Proxy가 최종적으로 원 서버와 상호작용할 준비가 되었을 때 그 IP주소가 다운되었음을 알게 될 것이다.

• 브라우저에서 제공하는 것과 동등한 수준의 장애 허용(fault tolerance)을 제공하기 위해, Proxy는 Host 헤더에 있는 호스트명을 재분석하든, IP 주소에 대한 역방향 DNS 룩업을 해서든 다른 IP주소를 시도해야한다.

• 브라우저가 명시적인 Proxy를 사용하도록 설정되어 있는 경우 장애허용은 더욱 중요하다.

---

메시지 추적

• 오늘날 웹 요청 시 상당수의 Proxy를 지나게 되는데 그 흐름을 추적하고 문제점을 찾아 낼 수 있어야 한다.

Via 헤더

• 메시지가 지나는 각 중간 노드(Proxy or GateWay)의 정보를 나열한다.
• 메시지가 또 다른 노드를 지날 때마다, 중간 노드는 Via 목록의 끝에 반드시 추가되어야 한다.

Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

Via 문법

• , (쉼표)로 구분진다.

Via               = "Via" ":" (waypoint) ["," (waypoint)...]
waypoint          = (received-protocol received-by [ comment ])
received-protocol = [ protocol-name "/" ] protocol-version
received-by       = ( host [ ":" port ] ) | pseudonym

Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com
# received-protocol = "HTTP/"(생략됨)1.1
# received-by       = proxy-62.irenes-isp.net
# received-protocol = "HTTP/"(생략됨)1.0
# received-by       = cache.joes-hardware.com

• protocol-name

  • HTTP 인 경우 생략 가능

• host 명

  • 숨기고자 한다면 가명으로 대체할 수 있다.

• 가명을 그룹핑 할 수 있다.

  • 같은 프로토콜, 같은 조직 통제하에 있고, 가명으로 교체되어 있는 경우에만

      Via: 1.0 foo, 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

  • 하나의 프록시 인 것처럼 대체할 수도 있다.

      Via 1.0 foo, 1.1 concealed-stuff

  • 이는 네트워크 내부 설계 등이 노출됨으로써 보안이 깨지는 것을 방지한다.

  • 웬만하면 모든 프록시는 via 헤더(경유지 목록)를 유지하고자 노력해야 한다.

• pseudonym

  • 벤더나 버전 정보, 이벤트 진단 정보 등을 사용하는 노드 코멘트

Via의 요청과 응답 경로

• 응답의 Via 헤더는 언제나 요청의 응답 Via 헤더의 반대다.

Via와 GateWay

• HTTP/FTP 로 변환되는걸 알 수 있다.
• Proxy로 HTTP 요청을 GateWay로 동작하는 Proxy는 FTP 프로토콜을 이용해 객체를 받아온다.

Server Header

• Server 응답 헤더는 필드의 원 서버에 의해 사용되는 소프트웨어를 알려준다.

Server: Apache/1.3.14 (Unix) PHP/4.0.4
Server: Netscape-Enterprise/4.1
Server: Microsoft-IIS/5.0

• 응답 메시지가 Proxy를 통과할 때 Proxy는 Server 헤더를 수정해서는 안된다.
• Server 헤더는 원 서버를 위해 존재한다. 대신에 Proxy는 Via항목을 추가해야한다.

TRACE Method

• HTTP/1.1의 TRACE Method는 어떤 Proxy를 지나가고 어떻게 각 Proxy가 요청 메시지를 수정하는지 관찰/추적할 수 있게 해준다.
• 불행히도…. 잘 구현되어 있지는 않다….;;

• Max-Forwards

  • 일반적으로 TRACE Method는 중간에 Proxy가 몇개가 있든 신경쓰지 않고 목적지까지 처리한다.

  • 해당 헤더를 사용하면 다음 요청으로 부터 몇번째 요청까지 체크할 건지 명시해 줄 수 있다.

    

---

Proxy 인증

• Proxy는 접근 제어 장치로 제공 될 수 있다.

• 제한된 컨텐츠에 대한 요청이 Proxy Server에 도착했을 때, 407 상태 코드와 Proxy-Authenticate 헤더를 함께 반환한다.

  • 407 Proxy Authorization Required

    → 클라이언트는 로컬 데이터베이스를 확인해서든 사용자에게 물어봐서든 요구되는 자격을 수집한다.

  • Proxy-Authorization

    → 어떻게 자격을 제출할 수 있는지 설명해 주는 Header

• 자격을 획득하면 클라이언트는 요구되는 자격을 Proxy-Authorization 헤더에 담아서 요청을 다시 보낸다.

• 자격이 유효하다면 Proxy는 원 요청을 연쇄를 따라 통과시킨다. 유효하지 않다면 407 응답을 보낸다.

---

Proxy 상호운용성

• 지원하지 않는 헤더는 그대로 냅둔다. (멍청한 Proxy처럼…)
• 같은 이름의 헤더는 상대적인 순서도 반드시 유지해야 한다.
• 만약 Proxy가 어떤 Method와 친숙하지 않다면 가능한 한 그 메시지를 다음 홉으로 전달하려 시도해야한다.
  • HTTP/1.1은 메서드를 확장하는 것을 허용하고 있기 때문에 주의해야한다.

OPTIONS

• 어떤 기능을 지원하는지 알아 볼 수 있다.
• Allow Header에 사용 가능한 Method 리스트가 나온다.
• Proxy는 Allow 헤더를 수정해서는 안된다.