On Mon, 17 May 2010 08:07:23 -0700 (PDT), Quin Guin <quinguin@xxxxxxxxx> wrote: > Amos, > > Thank you for your reply and see reply below: > > Thanks, > > Guin > NP: your email client needs to be fixed too it seems. It's attributing your reply to me. > > ----- Original Message ---- > From: Amos Jeffries <squid3@xxxxxxxxxxxxx> > To: squid-users@xxxxxxxxxxxxxxx > Sent: Sat, May 15, 2010 2:14:14 AM > Subject: Re: http CONNECT method with fwd proxy to content > server on same subnet > > Quin Guin wrote: >> Hi, >> >> I have a new need for deploying squid in my environment and I have >> been trying to set it up but it is not working as expected. Please >> see me requirements below and I have tried this with both 2.7-stable9 >> and 3.1.3 on CentOS4.6 64bit. >> >> I have a remote server sending a HTTP CONNECT to my server but my >> server can't handle an HTTP CONNECT. So I wanted to use squid to > > Something is badly broken there. CONNECT is not a generic HTTP request > method. It is specifically for browser-to-proxy and proxy-to-proxy > communication. > You should never receive it at a web server or web app interface. > > > I agree this is not a good design but I didn't have a say in it but I did > get stuck with getting it to work. The request are coming from > browser-to-proxy over 8080 and my idea is to proxy(squid)-to-proxy(ours) > that doesn't handle CONNECT method. Yes I know this is far from ideal but > I am just trying to have SQUID as a forward proxy receive the request then > send it as a regular https request still encrypted with out the CONNECT > method to our "proxy". > >> handle the CONNECT method and then send the https requests to my >> local server to handle the request. I know that a transparent proxy >> doesn't know how to handle the SSL requests because is not operating > > Yes, nor does it legally handle CONNECT method. Since interception mode > should only be handling valid web server interface methods. > > I agree with that.. > >> as a normal proxy. So I have been using squid as a fwd proxy but it >> keeps sending the http CONNECT method to my end server which is >> causing issues. So I am asking for ideas on what I need to do to look >> at do this. I have tried various iptables rules and cache_peers but >> nothing is seeming to work I am using pretty much the default config >> except for my local network IPs and ACL to allow the traffic. >> >> I would appreciate any ideas.. > > Do you have access or control to configure the remote server properly? > > No I do not but I really wish I did..because then I would not be doing > this. Okay. Being able to swing RFC 2616 section 9.3 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html about in the right direction should be of some assistance with that in the long term. > > What is your current squid.conf configuration for http_port, http_access > and cache_peer rules? > > Here is the config: > > acl manager proto cache_object > acl localhost src 127.0.0.1/32 > acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 > acl localnet src 172.16.0.0/12 # RFC1918 possible internal network > acl SOL src xxx.xxx.xxx.xxx/24 # novarra > > > http_access allow manager localhost > http_access deny manager > http_access deny !Safe_ports > http_access deny CONNECT !SSL_ports > http_access allow localnet > http_access allow CONNECT SOL > http_access allow CONNECT localnet > http_access allow SOL > http_access deny all The rules "allow CONNECT SOL" and "allow CONNECT localnet" are duplicates of "allow localnet" and "allow SOL". The CONNECT ones can be removed from there again. > icp_access allow localnet > icp_access deny all > > http_port 8080 > htcp_port 0 > icp_port 0 > > never_direct allow all Ah, never_direct seems to be your problem. What you need is this I think: never_direct deny SOL never_direct allow all > cache_peer 172.18.0.39 parent 8775 0 no-query default > cache_peer_access 172.18.0.39 allow CONNECT Um, 172.18.0.39 being a web server? it will need "originserver" option and drop the CONNECT access permission. You DON'T want the CONNECT to be relayed on as-is. Amos
