>> Please clarify "things" and "did not work".
2023/05/30 10:38:04.703 kid5| 78,8| dns_internal.cc(1126) idnsCallbackAllCallersWithNewAnswer: last 1 records
2023/05/30 10:38:04.703 kid5| 1,5| CodeContext.cc(60) Entering: master203
2023/05/30 10:38:04.703 kid5| 78,6| dns_internal.cc(1104) idnsCallbackOneWithAnswer: last 1 records for 0x556b994c6f68
2023/05/30 10:38:04.704 kid5| 14,3| ipcache.cc(477) ipcacheParse: 1 answers for monitoring.us-west-2.amazonaws.com
2023/05/30 10:38:04.704 kid5| 14,7| ipcache.cc(985) have: no 52.94.176.210 in [no cached IPs]
2023/05/30 10:38:04.704 kid5| 14,7| ipcache.cc(985) have: no 52.94.176.210 in [no cached IPs]
2023/05/30 10:38:04.704 kid5| 14,3| ipcache.cc(532) addGood: monitoring.us-west-2.amazonaws.com #1 52.94.176.210
2023/05/30 10:38:04.704 kid5| 14,7| ipcache.cc(250) forwardIp: 52.94.176.210
2023/05/30 10:38:04.704 kid5| 14,3| ipcache.cc(576) ipcacheHandleReply: done with monitoring.us-west-2.amazonaws.com: 52.94.176.210 #1/1-0
2023/05/30 10:38:04.704 kid5| 14,7| ipcache.cc(231) finalCallback: 0x556b994c6f88 lookup_wait=1
2023/05/30 10:38:04.704 kid5| 78,7| HttpRequest.cc(595) recordLookup: 0x556b994c6570 lookup_wait=1
2023/05/30 10:38:04.704 kid5| 14,7| ipcache.cc(985) have: no 52.94.184.173:443 in 52.94.176.210 #1/1-0
2023/05/30 10:38:04.704 kid5| 85,3| client_side_request.cc(538) hostHeaderIpVerify: FAIL: validate IP 52.94.184.173:443 possible from Host:
2023/05/30 10:38:04.704 kid5| SECURITY ALERT: Host header forgery detected on conn616 local=52.94.184.173:443 remote=10.32.79.33:58260 FD 28 flags=17 (local IP does not match any domain IP)
current master transaction: master203
2023/05/30 10:38:04.704 kid5| SECURITY ALERT: on URL: monitoring.us-west-2.amazonaws.com:443
current master transaction: master203
2023/05/30 10:38:04.704 kid5| 20,3| store.cc(769) storeCreatePureEntry: storeCreateEntry: 'monitoring.us-west-2.amazonaws.com:443'
2023/05/30 10:38:04.704 kid5| 20,5| store.cc(349) StoreEntry: StoreEntry constructed, this=0x556b994f0200
2023/05/30 10:38:04.704 kid5| 19,9| stmem.cc(376) mem_hdr: 0x556b994ef648 hi: 0
2023/05/30 10:38:04.704 kid5| 20,3| MemObject.cc(100) MemObject: MemObject constructed, this=0x556b994ef620
2023/05/30 10:38:04.704 kid5| 55,7| HttpHeader.cc(155) HttpHeader: init-ing hdr: 0x556b994ef788 owner: 3
2023/05/30 10:38:04.704 kid5| 55,9| HttpHeader.cc(829) getList: 0x556b994ef788 joining for id Connection[12]
2023/05/30 10:38:04.704 kid5| 55,9| HttpHeader.cc(829) getList: 0x556b994ef788 joining for id Proxy-Connection[50]
2023/05/30 10:38:04.704 kid5| 55,9| HttpHeader.cc(1009) has: 0x556b994ef788 lookup for Expires[27]
2023/05/30 10:38:04.704 kid5| 88,3| MemObject.cc(83) setUris: 0x556b994ef620 storeId: monitoring.us-west-2.amazonaws.com:443
2023/05/30 10:38:04.704 kid5| 20,3| store.cc(443) lock: storeCreateEntry locked key [null_store_key] e:=V/0x556b994f0200*1
2023/05/30 10:38:04.704 kid5| 20,3| store.cc(569) setPrivateKey: 01 e:=V/0x556b994f0200*1
2023/05/30 10:38:04.704 kid5| 20,3| store.cc(421) hashInsert: StoreEntry::hashInsert: Inserting Entry e:=XIV/0x556b994f0200*1 key '0C000000000000003400000005000000'
2023/05/30 10:38:04.704 kid5| 4,4| errorpage.cc(717) errorAppendEntry: storing ERR_CONFLICT_HOST in e:=XIV/0x556b994f0200*1
2023/05/30 10:38:04.704 kid5| 55,7| HttpHeader.cc(155) HttpHeader: init-ing hdr: 0x556b994ef8b8 owner: 3
2023/05/30 10:38:04.704 kid5| 55,9| HttpHeader.cc(829) getList: 0x556b994ef8b8 joining for id Connection[12]
2023/05/30 10:38:04.704 kid5| 55,9| HttpHeader.cc(829) getList: 0x556b994ef8b8 joining for id Proxy-Connection[50]
2023/05/30 10:38:04.704 kid5| 55,9| HttpHeader.cc(1009) has: 0x556b994ef8b8 lookup for Expires[27]
2023/05/30 10:38:04.704 kid5| 55,9| HttpHeader.cc(829) getList: 0x556b994c6588 joining for id Accept-Language[3]
2023/05/30 10:38:04.704 kid5| 4,2| errorpage.cc(1386) buildBody: No existing error page language negotiated for ERR_CONFLICT_HOST. Using default error file.
On 16/05/2023 6:52 pm, sachin gupta wrote:
> Hi
> We recently shifted to squid 5.9 and started seeing errors in
> Transparent mode SECURITY ALERT: Host header forgery detected on
> conn3615903 local=44.242.184.237:443 <http://44.242.184.237:443>
> remote=10.109.176.240:8990 <http://10.109.176.240:8990> FD 28029
> flags=17 (local IP does not match any domain IP)
This is not a error, it is a alert to what is going on. The client
10.109.176.240 is trying to connect to 44.242.184.237 requesting a
domain which DNS says is **not** hosted there.
What happens next depends on what Squid is able to do given the
transaction type.
Some are rejected as unable to continue, some are allowed to complete
under restricted handling.
> Previously we were using
> https://github.com/NethServer/dev/issues/5348. In addition we are
> using client_dst_passthru off. When building 5.9, the patch was not
> applied cleanly and we wanted to check if things worked without this
> patch. They did not work.
Please clarify "things" and "did not work".
> I did check the forum responses
> https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery. and
> https://docs.diladele.com/faq/squid/host_header_forgery.html. We
> already support explicit proxy but that is not always an option. We
> can create another patch to circumvent issues like ***. But I wanted
> to know if there is a plan to make this check optional or there is
> some way we can workaround this problem without changing the code.
> Without this support, how can intercept mode work for any website
> which is behind a loadbalancer with multiple IPs.
More recent version of Squid allow some more CONNECT traffic cases be
handled instead of rejected.
There are also some ideas on further improvements, but those are a long
way off.
Cheers
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
