> > Probably non-HTTPS protocol being used. > > As bumping gets more popular we are hearing about a number of services > abusing port 443 for non-HTTPS protocols on the false assumption that > the TLS layer goes all the way to the origin server without > inspection. That has never been a true assumption, CDN frontends have > always decrypted. >
I've mentioned it before, and it's been pointed out that it probably doesn't scale, but I wrote a callout helper for this reason and for better logging. Basically: external_acl_type cert_callout concurrency=20 %DST %PORT /usr/local/squid/libexec/ext_cert_callout_acl acl is_ssl external cert_callout IS_SSL ssl_bump bump is_ssl ssl_bump splice all The helper connects to the IP:port and tries to obtain the certificate, and then caches the result (in an sqlite database). If it can't do so within a fairly short time it returns failure (but keeps trying a bit longer and caches it for next time). Alternatively if the IP used to be SSL but is now timing out it returns the previously cached value. Negative results are cached for an increasing amount of time each time it fails, on the basis that it probably isn't SSL. So it's somewhat optimistic - on a slow link or for a slow server a given IP:port might be spliced the first time when it should be bumped, but it will learn fairly quickly. And for non-SSL connections that appear to just hang in response to the request there will be an additional delay the first time. But otherwise it learns about the target without requiring admin intervention. It also returns the name of the cert so it can be logged instead of the IP (for transparent connections), although that isn't ideal as the same IP might be used for many services (google/youtube/etc) I can post it if anyone is interested, although it would require a bit of work to be completely useful. James _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
