On 9/09/2015 7:39 p.m., Jason Haar wrote: > On 08/09/15 20:32, Amos Jeffries wrote: >> The second one is a fake CONNECT generated internally by Squid using > Is it too late to propose that intercepted SSL transactions be logged as > something besides "CONNECT"? I know I find it confusing - and so do > others. I appreciate the logic behind it - but people are people :-) > Yeah. theres people - they need to stop looking at the *HTTP messages log* and thinking it says anything about bumping. All it says this the *side effects* of bumping which happen in the HTTP layer. Then there is the actual log processing software. And access.log is an HTTP transaction log, the detail being logged is the HTTP method being enacted by the HTTP software (Squid). TLS/SSL is a different protocol to HTTP. It should not be warped into HTTP log syntax. Trying to do so is what is confusing you. And the HTTP side effects are not clear. Try this (a log for the actual TLS / SSL-bump details): logformat tlslog %tS %6tr %>a:%>p %>la:%>lp \ %ssl::bump_mode %ssl::>sni %<A/%<a \ "%ssl::>cert_subject" "%ssl::>cert_issuer" access_log stdio:/var/log/squid/tls.log tlslog SSL_ports That is; the time things started, how long it took in ms, the client IP:port, server IP:port it was connecting to (might be Squid), the bumping mode squid was doing, SNI (if any), the server actually connected to (FQDN and IP), the cert details that server presented. I'm not sure which format code gets populated with SSL error details when cert validation fails. That should be added on the end too. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
