Hi Amos,
Here is the topology:
client (curl from host running docker) --> squid_child (docker, using ssl-bump with intercept) --> squid_parent (VM with internet connection, https_port without ssl-bump) --> origin server.
local - 72.19.0.2:443 is the container running squid child
remote - remote=172.19.0.1:44522 is the host machine where containers are running, I am using a curl to do initial tests. Eventually, request would come from other containers or external hosts on the docker daemon host.
With http traffic this works fine; wherein the request is forwarded to Parent and then to origin server. However, with https header forgery kicks in and tls is terminated.
- Kedar
On Mon, Jun 18, 2018 at 9:44 AM Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 18/06/18 02:08, Kedar K wrote:
> Hello,
>
> I am hitting this issue when running squid in a docker with ssl parent
> cache_peer.
>
Can you describe that a bit clearer please? An end-client, two proxies
and origin server makes four HTTP agents involved with this traffic.
Which of those proxies (and/or server) is inside the container?
And how are you getting the traffic from the client to the first proxy?
> Host header forgery detected on local=11 72.19.0.2:443
> remote=172.19.0.1:44522
> FD 15 flags=33 (local IP does not match any domain IP)
>
> The host ip of the docker would not resolve to a domain. How to
> work-around this problem?
The agent being client for the proxy reporting this message apparently
thinks there is a origin server running at "72.19.0.2:443" hosting some
domain name. They are trying to contact that origin server.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
- Kedar Kekan
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
