Chapter 6. Proxies
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Via Request and Response Path
Both request and response messages pass through proxies, so both request and response messages have Via headers.
- 요청과 응답 메시지는 모두 프록시를 통과하므로 Via 헤더를 가집니다.
Because requests and responses usually travel over the same TCP connection, response messages travel backward across the same path as the requests. If a request message goes through proxies A, B, and C, the corresponding response message travels through proxies C, B, then A. So, the Via header for responses is almost always the reverse of the Via header for responses (Figure 6-21).
-
일반적으로 요청과 응답은 동일한 TCP 연결 위에서 이루어지기 때문에 응답 메시지는 요청과 동일한 경로를 거꾸로 지나갑니다.
-
만약 요청 메시지가 프록시 A, B, C를 통과한다면 대응하는 응답 메시지는 프록시 C, B, A를 통해 전송됩니다.
-
따라서 응답에 대한 Via 헤더는 거의 대부분이 Via 헤더의 역순입니다. (Figure 6-21)
Via and Gateways
Some proxies provide gateway functionality to servers that speak non-HTTP protocols. The Via header records these protocol conversions, so HTTP applications can be aware of protocol capabilities and conversions along the proxy chain. Figure 6-22 shows an HTTP client requesting an FTP URI through an HTTP/FTP gateway.
-
일부 프록시는 non-HTTP 프로토콜을 사용하는 서버에게 게이트웨이 기능을 제공합니다.
-
Via 헤더는 프로토콜 변환을 기록하여 HTTP 응용 프로그램이 프록시 체인을 따라 프로토콜의 능력과 변화 과정을 알 수 있게 합니다.
-
Figure 6-22는 HTTP/FTP 게이트웨이를 통해 FTP URI를 요청하는 HTTP 클라이언트를 보여줍니다.
The client sends an HTTP request for ftp://http-guide.com/pub/welcome.txt to the gateway proxy.irenes-isp.net. The proxy, acting as a protocol gateway, retrieves the desired object from the FTP server, using the FTP protocol. The proxy then sends the object back to the client in an HTTP response, with this Via header field:
Via: FTP/1.0 proxy.irenes-isp.net (Traffic-Server/5.0.1-17882 [cMs f ])
-
클라이언트는 ftp://http-guide.com/pub/welcom.txt에 대한 HTTP 요청을 게이트웨이 proxy.irenes-isp.net에 전송합니다.
-
프로토콜 게이트웨이 역할을 하는 프록시는 FTP 프로토콜을 사용하여 FTP 서버로부터 목표 객체를 전달받습니다.
-
이후 프록시는 클라이언트에게 다음과 같은 Via 헤더 필드를 포함하는 HTTP 응답으로 객체를 전송합니다.
Via: FTP/1.0 proxy.irenes-isp.net (Traffic-Server/5.0.1-17882 [cMs f ])
Notice the received protocol is FTP. The optional comment contains the brand and version number of the proxy server and some vendor diagnostic information. You can read all about gateways in Chapter 8.
-
수신 프로토콜이 FTP라는 점에 유의합니다.
-
선택사항인 코멘트는 프록시 서버의 브랜드와 버전 번호 및 vendor 진단 정보를 포함합니다.
-
게이트웨이에 대한 모든 것은 Chapter 8에서 확인할 수 있습니다.
The Server and Via Headers
The Server response header field describes the software used by the origin server. Here are a few examples:
Server: Apache/1.3.14 (Unix) PHP/4.0.4 Server: Netscape-Enterprise/4.1 Server: Microsoft-IIS/5.0
-
Server 응답 헤더 필드는 origin 서버에 의해 사용되는 소프트웨어를 명시합니다.
-
아래는 몇 가지 예시입니다.
Server: Apache/1.3.14 (Unix) PHP/4.0.4 Server: Netscape-Enterprise/4.1 Server: Microsoft-IIS/5.0
If a response message is being forwarded through a proxy, make sure the proxy does not modify the Server header. The Server header is meant for the origin server. Instead, the proxy should add a Via entry.
-
응답 메시지가 프록시를 통해 포워딩 되었을 때 프록시가 Server 헤더를 수정하지 않음을 보장해야 합니다.
-
Server 헤더는 origin 서버에 대한 것입니다.
-
대신 프록시는 Via 엔트리를 추가해야 합니다.
Privacy and Security Implication of Via
There are some cases when we want don’t want exact hostnames in the Via string. In general, unless this behavior is explicitly enabled, when a proxy server is part of a network firewall it should not forward the names and ports of hosts behind the firewall, because knowledge of network architecture behind a firewall might be of use to a malicious party.*
-
Via 문자열에 정확한 호스트 이름을 원하지 않는 경우가 있습니다.
-
일반적으로는 이 동작을 명시적으로 사용하지 않는 한 프록시 서버가 네트워크 방화벽의 일부로 동작할 때 방화벽 내부의 호스트 이름과 포트 번호를 포워딩하지 않아야 합니다. 방화벽 내부의 네트워크 구조 정보가 악의적인 사람들에 의해 사용될 가능성이 있기 때문입니다.
If Via node-name forwarding is not enabled, proxies that are part of a security perimeter should replace the hostname with an appropriate pseudonym for that host. Generally, though, proxies should try to retain a Via waypoint entry for each proxy server, even if the real name is obscured.
-
만약 Via node-name 포워딩이 불가능하다면 보안 경계의 일부로 사용되는 프록시는 호스트의 이름을 호스트의 적절한 가명으로 대체해야 합니다.
-
그러나 프록시는 보통 실제 이름이 감추어지더라도 각각의 프록시 서버에 대한 Via 경유지 목록을 유지하려고 노력해야 합니다.
For organizations that have very strong privacy requirements for obscuring the design and topology of internal network architectures, a proxy may combine an ordered sequence of Via waypoint entries (with identical received-protocol values) into a single, joined entry.
For example:
Via: 1.0 foo, 1.1 devirus.company.com, 1.1 access-logger.company.comcould be collapsed to:
Via: 1.0 foo, 1.1 concealed-stuff
-
내부 네트워크 구조의 설계와 토폴로지를 숨기기 위해 매우 엄격한 정보 보호 요건을 가진 조직의 경우, 프록시는 Via 경유지 목록의 순차적인 시퀀스를 하나의 합쳐진 항목으로 결합합니다.
-
예를 들어
Via: 1.0 foo, 1.1 devirus.company.com, 1.1 access-logger.company.com은Via: 1.0 foo, 1.1 concealed-stuff로 줄일 수 있습니다.
Don’t combine multiple entries unless they all are under the same organizational control and the hosts already have been replaced by pseudonyms. Also, don’t combine entries that have different received-protocol values.
-
모든 항목이 동일한 조직의 제어 하에 있지 않고 호스트가 이미 가명으로 대체되지 않았다면 여러 개의 항목을 결합하지 않아야 합니다.
-
또한 서로 다른 수신 프로토콜 값을 가진 항목을 결합해서도 안 됩니다.
🧡 요약 정리 🧡
Via Header
- Path : Request의 Via 헤더와 Response의 Via 헤더는 일반적으로 역순
- Gateway Proxy : Via 헤더에 수신 프로토콜를 명시해야 한다
- Via 문자열에 호스트 이름을 기재하는 것을 원하지 않는 경우 가명으로 대체
- 엄격한 보안이 필요한 조직에서는 Via 경유지 목록을 하나의 합쳐진 항목으로 결합 (단 모든 항목이 동일한 조직의 제어 하에 있지 않고 호스트가 가명으로 대체되지 않았다면 결합 금지)
💛 감상 💛
- 오늘로 Via 헤더에 대한 파트를 마쳤습니다. 이제 프록시 파트도 점점 끝을 향해 달려가고 있습니다! 시험이 임박해서 어제 그저께 포스팅을 못 올렸는데... 그래도 최대한 성실하게 업로드해보도록 하겠습니다.
