[squid-users] https squid reverse proxy to an http web site
Hi Everyone, I have a bit of an issue that I am trying to resolve with Squid, but I cannot quite get the hang of things. I was wondering if someone could help me out or point me in the right direction. I have a simple piece of hardware that uses a web interface. This hardware only uses http though, and I would like to make it a bit more secure. The issue is that all of its internal pages are hard-coded http. Right now, https and http are working perfectly through Squid on another side we have, but on this one, whenever I click an http link, the connection reverts back to an insecure one on port 80. Since there is no https service on the hardware, I don't think I can just rewrite the URL, although it would be great if I could. Is there any way that I can use squid to fix this? So far, most examples and docs I can see either have an https service listening on the other side of squid, or they rewrite the urls. Thanks for your help in advance! Anna
Re: [squid-users] https squid reverse proxy to an http web site (solved)
Hey everyone,
I figured out what was going on and have everything working smoothly.
for future references, here's what I did:
1.) configure squid. Here's the relevant chunk of the config:
---
https_port 443 cert=/usr/misc/certs/squid.cert
key=/usr/misc/certs/squid.pem defaultsite=testbench112.cnbc.cmu.edu
http_port 80 defaultsite=testbench112.cnbc.cmu.edu
cache_peer sourceserver112.cnbc.cmu.edu parent 80 0 no-query login=PASS
originserver name=server1
acl our_sites dstdomain localhost 127.0.0.1 sourceserver.cnbc.cmu.edu
testbench112.cnbc.cmu.edu
http_access allow our_sites
cache_peer_access server1 allow our_sites
url_rewrite_program /usr/local/bin/rewritehttps
url_rewrite_children 10
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access deny all
---
2.) Rewrite the URLs presented to Squid with a rewrite script as seen
above in /usr/local/bin/rewritehttps:
---
#!/usr/bin/perl
#
# URL rewriter for squid to convert HTTP requests to HTTPS.
$| = 1;
while () {
s/^http:/301:https:/;
print;
}
---
Unless this looks horribly wrong to someone's keen eye, I'm going to
roll with it. Everything seems to be working as planned, and nothing has
caught fire yet :) I'd assume that this would also be useful for going
the opposite way, just change the script's https and http around and
change the cache peer to 443 instead of 80.
Have a great day,
--Anna
On 5/24/11 3:14 PM, Anna K. Hegedus wrote:
Hi Everyone,
I have a bit of an issue that I am trying to resolve with Squid, but I
cannot quite get the hang of things. I was wondering if someone could
help me out or point me in the right direction.
I have a simple piece of hardware that uses a web interface. This
hardware only uses http though, and I would like to make it a bit more
secure. The issue is that all of its internal pages are hard-coded
http. Right now, https and http are working perfectly through Squid on
another side we have, but on this one, whenever I click an http link,
the connection reverts back to an insecure one on port 80. Since there
is no https service on the hardware, I don't think I can just rewrite
the URL, although it would be great if I could.
Is there any way that I can use squid to fix this? So far, most
examples and docs I can see either have an https service listening on
the other side of squid, or they rewrite the urls.
Thanks for your help in advance!
Anna
Re: [squid-users] https squid reverse proxy to an http web site (solved)
On 25/05/11 11:07, Anna K. Hegedus wrote:
Hey everyone,
I figured out what was going on and have everything working smoothly.
for future references, here's what I did:
1.) configure squid. Here's the relevant chunk of the config:
---
https_port 443 cert=/usr/misc/certs/squid.cert
key=/usr/misc/certs/squid.pem defaultsite=testbench112.cnbc.cmu.edu
http_port 80 defaultsite=testbench112.cnbc.cmu.edu
If you want it to be secure I would advise removing defaultsite (used to
cope with legacy broken software, rejecting such brokenness is one
security layer).
Replacing it with accel vhost instead.
cache_peer sourceserver112.cnbc.cmu.edu parent 80 0 no-query login=PASS
originserver name=server1
acl our_sites dstdomain localhost 127.0.0.1 sourceserver.cnbc.cmu.edu
testbench112.cnbc.cmu.edu
NP: defaultsite= option on the http_port lines forces the domain to
always be testbench112.cnbc.cmu.edu. Which prevents alternative
domains matching and disables these domain-based attack protections.
http_access allow our_sites
cache_peer_access server1 allow our_sites
url_rewrite_program /usr/local/bin/rewritehttps
url_rewrite_children 10
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access deny all
---
2.) Rewrite the URLs presented to Squid with a rewrite script as seen
above in /usr/local/bin/rewritehttps:
---
#!/usr/bin/perl
#
# URL rewriter for squid to convert HTTP requests to HTTPS.
$| = 1;
while () {
s/^http:/301:https:/;
print;
}
---
Unless this looks horribly wrong to someone's keen eye, I'm going to
roll with it. Everything seems to be working as planned, and nothing has
caught fire yet :) I'd assume that this would also be useful for going
the opposite way, just change the script's https and http around and
change the cache peer to 443 instead of 80.
That is pretty much how it has to be done for 3.1 and older. 3.2 offer
deny_info redirects to replace the re-writer.
FYI:
The Squid URL re-write interface will do a lot of extra work
duplicating the request whenever it is told that the URL has changed.
*** Even if the URL has not actually been altered! ***
Send an empty () line back to Squid unless you are actually wanting
to change the request.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.7 and 3.1.12.1
