On 02/06/17 01:10, erdosain9 wrote:
"If I assume that its doing what you want there are still two major issues that can be seen."................. i think it was... "1) Mixing interception and authentication (ssl-bump is a type of interception, at least on the https:// traffic). Intercepted messages cannot be authenticated - though there are some workarounds in place for ssl-bump to authenticate the CONNECT tunnel and label all the bumped traffic with that username." how it's that?, maybe i wrong (probably) but, for example a connection to youtube, it is ssl, and i see (in access.log, who do that (its authenticate). So? im wrong no? why?
That is the hack workaround doing its thing. Squid is authenticating the CONNECT message, then simply reporting that authenticated username for all the bumped https:// log entries. In its current form/code it sort-of works most of the time, but can break (start rejecting everything) if there is ever even a slightest wobble in the credentials validity while the bump of that tunnel is ongoing.
2)........ we have a dns server (192.168.1.222) that just have our internal dns names and then points to 8.8.8.8... that (192.168.1.222) dns server would it not be useful either?
The core issue is the speed at which that service rotates its response IP lists, which is directly related to each request going to entirely different server in their farm. Simply having a single (and maybe more sane regarding TTLs) resolver as a networks focal point for the traffic before it reaches out to the Google service seems to bring sanity back to the performance.
Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
