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
