> > Not the way you want to do it. > > You can happily do steps 1->2, but as soon as the browser starts the HTTPS > connection you loose all control over what happens inside the encrypted > tunnel. > > You cannot configure browsers with WPAD/PAC to connect to the proxy over SSL > since none of the common browsers have any kind of SSL-proxy connection > features. > > You cannot fake being https://example.com since the browser and HTTPS > security is created expressly to detect and alert the user to such > man-in-middle attacks. I know that's impossible to fake a domain name like I described... Sorry, I have just presented the main idea. In fact, it will need a domain name modification, such as the captive portal "talweg" does http://google.fr -> https://u-google--my.talweg/ and it uses wildcard ssl. But the inconvenience of talweg, that is required the installation of its certificat and it does not permit accounting. Ok, so... I guess squid do not do that. Thanks for answering. G. > > You cannot use the SSLBump feature of 3.1 without causing large visitor > annoyance as the alerts on every site they visit (even unencrypted ones!) > shows web attacks taking place. > > Basically, with the captive portal approach you are forced to accept any > kind of internal inputs. The visitor machine is always correct, you have > zero control over their machine. All you can do is map insecure internal > connections to secure _external_ protocols on the Internet side of the > portal. In some cases respond with an informative message saying please do X > instead of Y and hope the visitor reads it. > > Unless you are in a very high-security environment this should not be an > issue. If you are in a high security environment WTF are you doing running a > captive portal instead of a blanket security firewall? > > Amos > -- > Please be using > Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14 > Current Beta Squid 3.1.0.7 >
