Re: [squid-users] transproxy message for https

> > Is there a mechanism by which I can intercept port 443 and alert the
> > user that a proxy is required, eg if they try to go to
> > https://www.apple.com then they get redirected to a website with
> > instructions on how to configure their device (iphones in this case)
> > to the proxy.
>
> Yes, there is such a mechanism (search for SslBump) but it requires
> impersonating the secure server that the user was trying to connect to,
> so it is not very usable unless your users trust your self-signed SSL
> certificate as they trust certificates from well-known Root CAs. SslBump
> also has many negative side effects, even when users trust your certificate.
>

What about using SslBump with MimicSslServerCert (
http://wiki.squid-cache.org/Features/MimicSslServerCert ) ?
I've interest in implement an transparent bridge proxy server
(Tproxy4) with https filtering. It's possible to deploy 3.3.x series
without CA Cert installation in users browsers?

2013/2/28 Alex Rousskov <rousskov_at_measurement-factory.com>:
> On 02/27/2013 10:15 PM, James Harper wrote:
>
>> Is there a mechanism by which I can intercept port 443 and alert the
>> user that a proxy is required, eg if they try to go to
>> https://www.apple.com then they get redirected to a website with
>> instructions on how to configure their device (iphones in this case)
>> to the proxy.
>
> Yes, there is such a mechanism (search for SslBump) but it requires
> impersonating the secure server that the user was trying to connect to,
> so it is not very usable unless your users trust your self-signed SSL
> certificate as they trust certificates from well-known Root CAs. SslBump
> also has many negative side effects, even when users trust your certificate.
>
>
>> Currently users get a wall of nothing then a timeout error without
>> having a clue what is going wrong.
>
> You can also try forcefully terminating their port 443 connections
> instead of dropping packets. That will not give them a nice error
> message, but may prevent timeouts. They would still be "clueless", but
> they will not waste as much time.
>
>
> HTH,
>
> Alex.
>
Received on Thu Feb 28 2013 - 12:20:03 MST