On 13/03/2014 7:09 p.m., PSA4444 wrote:
> I'm running squid as a reverse proxy with many web servers behind it, using
> host headers to determine which site the user is trying to access.
>
> One of these web servers runs IIS, with multiple websites on different
> ports: 443, 444, 445, etc.
>
> I would like squid to be able to connect to this server on a different port
> based on which address the user tries to access.
>
> https://help.mydomain.com:443 -> 10.0.1.4:443
> https://app.mydomain.com:443 -> 10.0.1.4:444
>
One the requests are received Squid is perfectly able to route them to
different cache_peer. That is done somewhat like you tried already.
This configuration depends more on getting the requests at all though.
Since HTTPS certificate validation hinges very much on matching the
domain certified with the domain fetched when the server cert is
delivered to the client before any of the HTTPS requests are sent to
tell the server what domain is being fetched.
This big problem can be avoided in two ways:
1) using a wildcard certificate for *.mydomain.com that can validate
both sub-dmains on your listening https_port.
2) SNI (Server Name Indication) extension feature of SSL/TLS. Where the
client tells the server which domain is being accessed so the server can
send out a certificate for that domain.
Squid does not yet support method #2 IIRC. Any contributions towards
that are welcome.
> I have tried the following to achieve this:
>
> cache_peer help.mydomain.com parent 443 0 no-query originserver ssl
> sslversion=3 connect-timeout=8 connect-fail-limit=2
> sslflags=DONT_VERIFY_PEER front-end-https=on name=help login=PASSTHRU
>
> cache_peer app.mydomain.com parent 444 0 no-query originserver ssl
> sslversion=3 connect-timeout=8 connect-fail-limit=2
> sslflags=DONT_VERIFY_PEER front-end-https=on name=app login=PASSTHRU
>
> unfortunately, accessing both these sites connects to the site running on
> port 443 on the IIS server :(
>
> How can I achieve what I'm trying to?
>
For the cache_peer side you are on the right track but there are a few
issues that need to be fixed:
1) use cache_peer_access to determine for each request which peer server
it is going to:
acl help dstdomain help.mydomain.com
cache_peer_access help.mydomain.com allow help
cache_peer_access help.mydomain.com deny all
... etc
2) remove sslflags=DONT_VERIFY_PEER.
It is okay for initial testing that the SSL/TLS connections will work.
But before this goes into production you should setup Squid with the CA
appropriate to verify the peers certififcates.
Verifying peers prevents hijacking of the HTTPS connections between
your proxy and the master servers.
3) you may need the forceddomain= option on app.mydomain.com to deliver
the port change.
Amos
Received on Thu Mar 13 2014 - 09:20:23 MDT
This archive was generated by hypermail 2.2.0 : Thu Mar 13 2014 - 12:00:04 MDT