On 14/12/2012 1:23 p.m., David Touzeau wrote:
>
> Dear
>
> I'm using Squid 3.2.4 in reverse mode with multiple SSL web servers
>
> I need to force squid to not use the default certificate for specific
> target Web servers and i did not know how to do...
> I'm turning around this issue...
>
> Example:
> http_port 80 accel vhost
> https_port 443 accel cert=/etc/squid3/ssl/cacert.pem
> key=/etc/squid3/ssl/privkey.pem vhost
>
>
> For this cache_peer i need to squid just forward SSL requests (CONNECT
> method) to the remote server and not re-encrypt the SSL in order to
> let the remote web server establishing the SSL tunnel.
Reverse-proxy do not receive CONNECT requests. Squid does not as yet
generate CONNECT requests to peers at all. But, ...
>
> cache_peer 10.32.0.10 parent 443 0 no-query originserver ssl
> sslflags=DONT_VERIFY_PEER name=ssldef
>
> Is it possible to do that ?
You can set the certificate using the sslcert= option. But, ...
> Or when settings accel 443 port, all SSL web sites are mandatory
> re-encrypted ?
You already configured that. The "ssl" option on cache_peer encrypts
everything over that peer link.
BUT .... the connection type and the URL scheme are not locked together
as strongly as you think. What you have here is a reverse-proxy which
terminates the SSL from the client, initiates new SSL connections to
this peer, and sends requests over that peer connection. Since they
arrived as SSL they are delivered to the peer as https:// URL requests.
So, if you get that each hop client->squid, squid->peer, peer->server
has separate SSL encryption being performed.
Your port-80 traffic MAY also be encrypted and sent securely over the
peer link as http:// URL requests. Links to peers from Squid may be over
TCP or SSL.
You can avoid teh CPU overheads of encryption on that port-80 traffic to
the peer by configuring two peer links for encrypted and non-encrypted
connection to it and a "acl HTTPS proto HTTPS" along with
cache_peer_access to determine which peer connection type each type of
request uses.
Amos
Received on Fri Dec 14 2012 - 09:19:08 MST
This archive was generated by hypermail 2.2.0 : Fri Dec 14 2012 - 12:00:04 MST