[squid-users] this config is ok? is ok the order?

[Amos Jeffries]

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