[
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073026#comment-14073026
]
Nikolai Gorchilov commented on TS-2954:
---------------------------------------
My usual scenario is TPROXY in ISP NOC where (many) clients use different DNS
servers then the cache do. In this same NOC Akamai, Google Peering and Google
Cache are available.
As a result both proxy.config.http.use_client_target_addr modes create
different critical issues:
* proxy.config.http.use_client_target_addr = 0 makes more than 20% of requests
toward Akamai and Google properties to fail due to different dst IP used by
client and cache. For obvious reasons local Akamai and Google nodes are
excluded from traffic interception and redirection via the cache. When the
client resolves an external CDN node, request gets diverted to the cache. Cache
does independent DNS resolution and very often tries to forward the request to
local node with spoofed src IP of the user. Due to exclusion from interception
rules, the response from local node doesn't return to the cache, but goes
directly to the client.
* proxy.config.http.use_client_target_addr = 1 makes the cache vulnerable to
poisoning - already experienced it in real life due to some malware - all major
websites like Google, Facebook and Youtube were affected.
So neither option really works for me. I need a Squid-like mode (say
proxy.config.http.use_client_target_addr = 2 or new option), which requires the
client target address is used for sanity checks only, and not for routing.
> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> -------------------------------------------------------------------
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, DNS, Security, TProxy
> Reporter: Nikolai Gorchilov
> Priority: Critical
>
> Current implementation of proxy.config.http.use_client_target_addr opens a
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake
> IP for popular website like www.google.com or www.facebook.com in hosts file
> on PC behind the proxy. Once an infected PC requests the webpage in question,
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a
> mechanism known as [Host Header Forgery
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the
> client, proxy makes independent DNS query in parallel in order to determine
> if client supplied IP belongs to requested domain name. In case of
> discrepancy between DNS and client IP, the transaction shall be flagged as
> non-cacheable to avoid possible cache poisoning, while still serving the
> origin response to the client.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
