On 10/06/2015 2:51 a.m., Klavs Klavsen wrote: > Amos Jeffries wrote on 06/09/2015 03:06 PM: >> >> The HTTP message log (access.log) is only logging the HTTP(S) messages. >> The non-HTTP protools are not logged. >> >>> >>> 10.xx.131.244 - - [09/Jun/2015:08:40:15 +0200] "CONNECT >>> 64.233.184.94:443 HTTP/1.1" www.google.dk - 200 20042 >>> TCP_TUNNEL:ORIGINAL_DST peek >> >> This got peeked then spliced (not decrypted). There is no decrypted >> message(s) to be logged or even to pass through http_access. >> > I'm obviously not understanding something.. I would like squid to "fake > the certificate" - and then when the clients sends an actual request - > run that through http_access.. so I can match on urls.. > > I'd rather not filter on only domain if possible.. > > Is that not possible currently with squid? That is the "bump" action and depends on what TLS details are presented by client and server vs what you have configured to be done. You have to first configure ssl_bump in a way that lets Squid receive the clientHello message (step1 -> peek) AND the serverHello message (step2 -> peek). Then you can use those cert details to bump (step3 -> bump). The config is quite simple: ssl_bump peek all ssl_bump bump all But there are cases like the client is resuming a previous TLS session where there is no certificates involved. Squid cannot do anything, so it automatically splices (3.5.4+ at least do). Or if you have configured your Squid in a way that there are no mutually supported ciphers. It may just be your ssl_bump rules. But given that this is a google domain there is a strong chance that you are encountering one of those special case. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
