Re: [squid-users] Web client not capable of SSL

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Mon, 03 May 2010 02:17:15 +1200

D.Veenker wrote:
>
> It is just a specific server / host. I know exactly which URL needs to
> be rewritten to https.
>
> - You think IPTABLES/TPROXY is a solution to make it transparent?

To make it intercepting yes.

> - Which config do I have to use for the client certificates?

cache_peer to port 443 of the host with "ssl" option.

> sslproxy_client_key or sslproxy_client_certificate?
> - What is the difference?

Not certain. They may need setting. Or they may not. I'm still trying to
get straight which if the three SSL modes they apply to.

> - Do I have to use them in combination with other config settings?
> - What about using ICAP for rewriting the URL? Or would you personally
> use the internal rewiter?
>

None of that needed with a cache_peer explicit link to the host.

Amos

> Thanks, Dj
>
>
> Amos Jeffries wrote:
>> D.Veenker wrote:
>>>
>>> Is it maybe possible to intercept the http:// request over port 80
>>> with IPTABLES and redirect it to Squid?
>>>
>>> Then let an ICAP add-on (or the internal rewriter) rewrite the URL to
>>> https://. Then let Squid do all the SSL with client certificates with
>>> the actual https-server.
>>> Last, Squid forwards the server-reply to the client (maybe also by
>>> using some IPTABLE tricks) to the client in regular un-encrypted http.
>>
>> Pretty complex.
>>
>> For the general case you hit the very hard problem of; how do you
>> know any given server will accept HTTPS for any given request?
>>
>>
>> If you have a specific server or set of servers you need it for use
>> cache_peer to setup an SSL link to each and just pass the relevant
>> requests down it.
>>
>>
>> Amos
>

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.3
Received on Sun May 02 2010 - 14:17:27 MDT

This archive was generated by hypermail 2.2.0 : Sun May 02 2010 - 12:00:03 MDT